Semantic models expose distributed app flaws scanners miss

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Aptori's blog post: Semantic models expose how distributed applications fail when identities, objects, and workflows are validated separately instead of as one system.

Why it matters: Practitioners need this lens because modern application risk often sits in cross-service trust, not in isolated code defects, and that is where traditional testing loses coverage.

Context

Modern application security breaks down when security decisions are split across gateways, identity providers, services, and downstream data stores. A request can look valid at each hop and still produce an unauthorised outcome once the full workflow is considered.

A semantic model is a structured representation of how an application behaves, not just how its code is written. It is the right abstraction when business logic, access control, and identity propagation interact across services, and that is now typical in distributed applications.

Key questions

Q: How do semantic models help detect business logic flaws?

A: Semantic models help by representing the application as relationships between identities, objects, services, and workflows rather than as isolated code paths. That lets teams see when a sequence of apparently valid actions creates an unsafe result, such as unauthorised object access or a workflow bypass. The value is in exposing system behaviour that code scanners and single-request tests cannot infer.

Q: How should teams keep authorization consistent across microservices?

A: Teams should centralize authorization decisions in a single policy model and enforce those decisions uniformly across every service. That approach reduces policy drift, makes reviews auditable, and prevents teams from implementing incompatible access rules in different codebases. The goal is consistent runtime evaluation, not duplicated logic in each service.

Q: Why do downstream services create privilege escalation risk?

A: Downstream services create privilege escalation risk when they inherit caller trust, credentials or roles and then use them to reach data or actions beyond the original request. Common failure modes include confused deputy behaviour, overbroad service-to-service tokens, and trusted headers or claims that are accepted without revalidation. propagated trust should be constrained by least privilege and explicit audience checks.

Q: How can API abuse hide inside otherwise valid requests?

A: API abuse can hide inside valid requests when an attacker uses legitimate authentication, correct syntax and permitted fields to trigger unintended actions at scale. Defences focus on schema validation, rate limiting, behavioural detection, parameter allow-lists and separate monitoring for alternate endpoints that expose the same function through different paths. Normal-looking traffic can still exfiltrate data or automate abuse.

Technical breakdown

Interaction graphs and multi-step workflow abuse

A semantic model can represent an application as a graph of entities and relationships, including identities, APIs, objects, and service calls. That matters because many failures only appear across a sequence of steps, such as when one service creates state that another service later trusts without revalidating. Traditional scanners work one request at a time, so they miss abuse paths that depend on ordering, object reuse, or workflow state changes.

Practical implication: Model application flows as paths, not isolated transactions, so you can detect broken workflow assumptions before they become exploitable.

Authorization graphs and object ownership checks

Authorization is not just a yes or no decision. In distributed systems it is a network of rules about who can access which object, through which role, scope, attribute, or trust relationship. When different services enforce different parts of that rule set, the result is an inconsistent authorization graph. That inconsistency is what enables broken object level authorization, indirect object reference abuse, and privilege overreach even when each service appears individually correct.

Practical implication: Test whether object ownership and permission checks remain consistent across all services that can act on the same resource.

Identity propagation across service boundaries

Identity propagation describes how user or machine identity context travels through APIs, tokens, headers, queues, and service-to-service calls. The failure mode is usually not broken authentication at the front door, but lost or diluted identity later in the chain, where downstream services act on trust from an upstream component instead of the original caller. That is how privilege escalation paths emerge in modern architectures.

Practical implication: Verify that downstream services still see the original actor, not just a trusted caller or shared service credential.

Threat narrative

Attacker objective: The objective is to trigger an unauthorised state transition or data access by exploiting inconsistent trust between services.

1. Entry begins with a legitimate request that traverses multiple services, each of which may accept the previous component's decision without independently checking the caller's authority.
2. Credential or identity context is then diluted when tokens, headers, or service-to-service credentials are reused, dropped, or trusted too broadly across the workflow.
3. Escalation occurs when a downstream service performs an action based on upstream trust rather than the original identity and object relationship.
4. Impact is unauthorised access, workflow bypass, or business logic abuse that conventional code-level tooling never sees as a single exploit chain.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Business logic security has become a systems problem, not a code problem. Modern applications fail less often because one function is broken and more often because separately reasonable services produce an unsafe outcome when chained together. That shifts the security question from code correctness to interaction correctness, which is why semantic modelling is now central to application governance. Practitioners should treat cross-service behaviour as the primary unit of risk.

Identity propagation is the control gap that most AppSec tools still underweight. In distributed applications, identity is frequently transformed as it crosses gateways, queues, and internal APIs, and that transformation can erase the very context needed for authorisation. When services trust upstream decisions without reasserting the original actor, identity provider and SSO security becomes inseparable from application security. Practitioners should review where the original identity is lost, not just where authentication starts.

Semantic Runtime Validation points to a named concept we should now treat explicitly: application interaction topology. The important security object is not a single endpoint but the set of relationships that make an operation possible, including service trust, object ownership, and workflow state. Once that topology is visible, validation can target the actual path of abuse instead of isolated symptoms. Practitioners should map controls to interaction paths, not just to code modules.

Business logic abuse is increasingly the highest-value attack surface in modern APIs. Attackers do not need a memory corruption bug when they can exploit object reference handling, workflow sequencing, or alternate service paths to reach the same outcome. That is especially true when API security and application security are managed separately. Practitioners should align API tests, runtime validation, and authorisation review around the same system model.

Read next: Rate Limiting and API Abuse Guide

What this signals

Application attack paths are now the unit of governance. Security programmes that only measure endpoint findings or code defects will keep missing the failures that emerge between services. The practical shift is toward modelling how identity, object ownership, and workflow state change as requests move through the system.

Identity continuity should become a design requirement for modern APIs. If a downstream service cannot reliably see who initiated an action, the application is already relying on trust that may not survive normal routing, queuing, or delegation. Security teams should treat identity loss in transit as a control failure, not an integration detail.

For practitioners

• Map service-to-service trust paths Document which services can invoke which other services, which identities are carried forward, and where downstream checks are skipped or inherited from upstream calls.
• Test workflow state transitions Build abuse cases around multi-step operations, especially where one request creates state that a later request consumes without fresh authorisation or ownership checks. See the Business Logic Vulnerabilities Guide.
• Validate identity continuity end to end Confirm that tokens, headers, and service credentials preserve the original actor context through asynchronous processing, queues, and internal APIs.
• Prioritise object-level abuse paths Focus testing on object identifiers, alternate APIs, and ownership changes that can produce broken object level authorisation even when endpoint checks look sound.

Key takeaways

• Semantic analysis matters because distributed applications fail at the seams between services, not just inside code.
• The recurring risk is inconsistent trust between identity, object ownership, and workflow state across the request path.
• Practitioners need controls that validate behaviour end to end, because isolated scans cannot prove the system's real security outcome.

Related NHI Mgmt Group resources: Rate Limiting and API Abuse Guide · Business Logic Vulnerabilities Guide · Workforce Identity Security Guide · IAM and Identity Provider Buyer's Guide

Key terms

• Semantic Model: A governed layer that defines business meaning for data, such as what counts as a customer, order, or approved source. When semantic models are wrong or inconsistent, AI can produce outputs that are technically valid but operationally misleading.
• Business Logic Flaw: A business logic flaw is a weakness in how an application handles intended behaviour, such as permissions, workflow order, or transaction state. These flaws often bypass signature-based checks because the problem is not a malformed input, but a legitimate action used in the wrong sequence or context.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Identity propagation: The preservation of origin and acting principal information as a request moves through multiple services. In MCP chains, this is what allows downstream systems to make a trustworthy authorization decision instead of relying on a stripped-down token with no task context.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives security and identity practitioners a shared framework for governing machine and human access across modern systems.