Notifications
Clear all
Topic starter
06/07/2026 9:46 am
TL;DR: AI agents need runtime trust, federated authorization, browserless OAuth, and cross-domain API access patterns to work safely in enterprise environments, according to Curity’s security architecture articles. The governance gap is no longer just API policy design, but whether identity controls can handle dynamic agent behaviour without assuming a browser or a human in the loop.
NHIMG editorial — based on content published by Curity on AI agent security architectures, browserless OAuth, dynamic trust, and cross-domain API access
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Redesign OAuth for machine execution paths Map every agent-facing authorization flow and separate browser-dependent human consent from non-browser machine access.
- 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.
- Limit delegated scope to the current task boundary Avoid broad standing permissions for agents that can decide when and what to call next.
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
👉 Read Curity’s analysis of browserless OAuth and AI agent security architecture →
AI agent identity at runtime: what changes for IAM teams?
Explore further
06/07/2026 10:03 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent security architecture is shifting toward runtime trust
