AI agent security architecture is shifting toward runtime trust

At a glance

What this is: This is a set of Curity articles on AI agent security architectures, with the key finding that enterprise identity and API controls must support runtime trust and cross-trust-domain access.

Why it matters: It matters because IAM, NHI, and platform teams now have to govern agent-driven access paths that do not fit legacy browser-centred OAuth and static authorisation models.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Curity’s analysis of browserless OAuth and AI agent security architecture

Context

AI agent security is becoming an identity problem, not just an application design problem. Browserless OAuth, dynamic trust, and federated access across trust domains all point to the same issue: agents need to obtain and use credentials in ways that legacy browser-centred flows were never designed to govern.

For IAM and NHI teams, the challenge is not whether agents can call APIs. The challenge is whether authorisation, consent, and trust establishment can happen at runtime without creating standing access, opaque delegation, or unreviewable privilege paths. Curity’s articles frame that shift around enterprise architecture rather than isolated product features.

Key questions

Q: How should security teams govern AI agents that need to call APIs across trust domains?

A: Security teams should govern cross-domain agents as delegated identities with explicit boundaries. That means defining trusted issuers, restricting token audience, narrowing scopes, and requiring clear evidence of who or what authorized the exchange. If the receiving domain cannot validate provenance and intent, the access path is too weak for production use.

Q: Why do browser-based OAuth assumptions break down for AI agents?

A: Browser-based OAuth assumes a visible user interaction model with redirects, consent, and session state. AI agents often operate inside services or workflows where those interactions do not exist. As a result, teams must replace browser dependence with machine-oriented identity flows that still preserve auditability, scope control, and revocation.

Q: What breaks when runtime trust is not defined for agent identity?

A: Without runtime trust criteria, agents tend to inherit access that is too broad or too opaque to govern. Security teams lose the ability to judge whether the agent was allowed to act in the current context, which creates weak accountability and difficult revocation. The control failure is not just access excess, but unverifiable trust transfer.

Q: How do IAM teams decide whether an AI agent should be treated like an NHI?

A: If the agent receives credentials, requests tokens, or calls APIs without human approval at each action, it should be treated as an NHI for governance purposes. That brings lifecycle, scope, logging, and revocation into the identity programme. The decision is based on execution behaviour, not on whether the system is branded as AI.

Technical breakdown

Browserless OAuth and the collapse of browser assumptions

Browserless OAuth removes the browser from interaction flows that were originally built around human consent, redirects, and visible session state. In agentic environments, that matters because the identity event may need to happen inside a service, workflow, or tool call rather than through a user-facing browser. The technical shift is not cosmetic. It changes where tokens are issued, how consent is represented, and what evidence exists for audit and revocation. If the flow still assumes a browser, teams often end up simulating human interaction instead of designing for machine runtime behaviour.

Practical implication: model OAuth flows for machine execution paths first, then decide where human consent actually belongs.

Dynamic trust for AI agents at runtime

Dynamic trust means an agent establishes trust when it needs access, based on current context, rather than inheriting a fixed trust state from provisioning time. That can involve claims, scopes, and federated assertions that are evaluated per request or per task. The key architectural issue is that the agent’s access path is now conditional on runtime state, not just static registration. That reduces some standing exposure, but it also increases the importance of policy accuracy, issuer trust, and token audience controls.

Practical implication: treat runtime trust as a policy enforcement problem, not a one-time onboarding decision.

Cross-trust-domain API access and federated authorisation

When AI agents cross trust domains, they move from one identity boundary to another without the natural safeguards that human sessions or internal service calls sometimes assume. Federation becomes the bridge, but federation only works when claims, scopes, and authorization rules remain meaningful outside the origin domain. That makes API security, token exchange, and audience restriction central to agent governance. The failure mode is not simply unauthorized access. It is weakly defined trust transfer between domains that makes later decision-making impossible to reason about.

Practical implication: constrain audience, scope, and token exchange rules before agents are allowed to cross domain boundaries.

NHI Mgmt Group analysis

Browserless OAuth is a symptom of a broader identity design reset. OAuth was shaped around browser-mediated human interaction, but AI agents and automated workflows need access paths that do not rely on user redirects or visible session transitions. That makes browserless flows necessary, but also exposes how much of enterprise authorization still assumes a human is present at the point of consent. The practical conclusion is that identity architecture must distinguish human approval from machine execution instead of blending the two.

Dynamic trust changes the meaning of least privilege for agents. Least privilege for a human or traditional service often starts from a known role and a stable provisioning state. An AI agent operating at runtime can request, combine, and release access based on task context, so privilege is no longer fully knowable at enrollment time. Runtime privilege assumption: that assumption was designed for stable identities and predictable request patterns. That assumption fails when the actor decides what to do next during execution. Practitioners must rethink how privilege is expressed when intent is discovered mid-session.

Cross-domain agent access creates a trust-transfer problem, not just an API problem. Once an agent crosses trust boundaries, the question is no longer only whether the API accepts a token. The question is whether the receiving domain can evaluate provenance, scope, and accountability without inheriting blind trust from the origin system. That makes federation, claims mapping, and token audience control part of identity governance rather than pure integration plumbing. The practitioner conclusion is that cross-domain access must be governed as a delegated identity event.

Agent security is converging with NHI governance, even when the workflow looks autonomous. These architectures are often discussed as AI capability design, but the operational controls are the same family of problems that identity teams already manage for service accounts, tokens, and workload access. The difference is that agents can decide when to request and chain access dynamically, which raises the bar on lifecycle, evidence, and scope control. The practitioner conclusion is that agent governance belongs in the identity programme, not off to the side in application engineering.

Named concept: runtime trust boundary. The real governance unit is not the application, the browser, or the model, but the point where an agent proves enough context to cross into a new trust domain. That boundary has to be explicit because it is where authorization, auditing, and revocation either remain intelligible or collapse into opaque delegation. The practitioner conclusion is to design controls around the boundary, not around the model alone.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• That same research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• For the broader governance pattern, see The State of Non-Human Identity Security and OWASP NHI Top 10 for how runtime trust and delegated access reshape identity controls.

What this signals

Runtime trust boundary: the category is moving toward identity decisions that happen at the moment of access, not at onboarding. That means IAM teams should expect more policy evaluation at request time, more token exchange logic, and more pressure on audit trails that can prove why an agent crossed a boundary.

The practical signal for identity programmes is that browser-based consent is no longer a safe default for machine access. Teams that already struggle with third-party OAuth visibility should assume the same blind spots will appear in agent-to-API flows unless claims, audiences, and issuers are explicitly constrained.

As the architecture matures, practitioners should track it against NIST AI Risk Management Framework principles for governance and OWASP Agentic AI Top 10 for runtime misuse patterns. The next control frontier is not simply access granting, but whether the identity programme can explain the trust transfer after the fact.

For practitioners

• Redesign OAuth for machine execution paths Map every agent-facing authorization flow and separate browser-dependent human consent from non-browser machine access. Use explicit grants, short-lived tokens, and auditable exchanges where an agent must call APIs directly.
• Define runtime trust criteria before agents cross domains Specify which claims, scopes, issuers, and audiences must be present before an agent can request access in another trust boundary. If those conditions are not measurable, the trust transfer is too loose for production use.
• Limit delegated scope to the current task boundary Avoid broad standing permissions for agents that can decide when and what to call next. Bind access to a task, workflow segment, or explicit policy checkpoint so privilege does not outlive the action that needs it.
• Bring agent access into identity governance reviews Include AI agent identities, token issuance rules, and cross-domain authorisation paths in the same review cadence used for service accounts and other NHI credentials. Review who can approve trust transfer and how revocation is evidenced.

Key takeaways

• AI agent security is becoming an identity governance problem because runtime trust, browserless OAuth, and federated access all reshape how access is granted and proven.
• The core exposure is not only excessive privilege, but trust transfer that cannot be explained, audited, or revoked cleanly across domains.
• IAM and NHI teams should govern agent access as delegated identity behaviour, with explicit boundaries, scoped tokens, and reviewable trust criteria.

Key terms

• Browserless OAuth: An OAuth flow designed to work without a human using a browser to approve or complete the exchange. In agentic environments, it shifts the identity event into a service or workflow path, which means consent, evidence, and token handling must be explicit and machine-readable.
• Runtime Trust: The trust state established at the moment an identity requests access, rather than being assumed from onboarding or registration. For AI agents and other NHIs, runtime trust determines whether current context, claims, and authorization evidence are sufficient to cross a boundary.
• Trust Boundary: The point where one identity domain hands access to another domain under an explicit set of rules. In agentic and federated environments, the trust boundary is where provenance, audience, and scope become critical because the receiving system cannot safely rely on origin assumptions.
• Delegated Identity: An identity used to act on behalf of another subject, whether that subject is a human, workload, or AI agent. Governance must track who can delegate, what the delegate may do, and how revocation is proven when the delegated access is no longer needed.

What's in the full article

Curity's full articles cover the operational detail this post intentionally leaves for the source:

• Browserless OAuth flow patterns and the identity steps needed when no user-facing browser is available
• Dynamic trust examples showing how AI agents can establish access at runtime across trust domains
• API authorisation design for agent calls, including scopes, claims, and federated identity handling
• MCP authorization lifecycle details for safely accessing sensitive data through agent-driven requests

👉 Curity’s full articles cover dynamic trust, API access across trust domains, and MCP authorization lifecycle details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.