Topic starter
18/08/2026 2:39 pm
TL;DR: AI agents need runtime authorisation more than static API keys, Ory argues, because their behaviour changes after provisioning. Runtime policy has to sit above token validity so task, audience, and revocation still constrain each action.
Editorial analysis by NHI Mgmt Group, based on content published by Ory: “OAuth for AI Agents: How Authorization Actually Works”.
Key questions
Q: Why do OAuth scopes and service accounts increase AI agent risk?
A: They turn a single agent connection into delegated access across multiple systems, often without clear visibility into why each permission exists or who still owns it.
Q: How do security teams know if agent authorization is actually working?
A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach.
Q: What breaks when AI agents rely on long-lived API keys?
A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs.
Practitioner guidance
- Replace static keys for agent workflows Inventory every AI agent path that still uses a long-lived API key, then move those flows to delegated, revocable tokens with explicit scopes and expiry.
- Bind agent tokens to task and audience Add agent_id, task_id, and audience claims so resource servers can distinguish one agent action from another and reject token reuse across services.
- Layer runtime authorization over OAuth Use a policy engine to decide whether a specific agent action is allowed at the moment of execution, not just whether the token is valid.
Bottom line: AI agents expose the weakness of long-lived static keys because their behaviour changes at runtime, not at provisioning time.
Glossary terms: Agent Identity, Delegated Access Token, Audience Binding, Runtime Authorisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
18/08/2026 3:23 pm
Agent identity is not just machine identity with a new label: the article’s core distinction is that AI agents generate new intent rather than replaying a fixed script. That breaks the assumption behind many machine identity controls, which expect predictable, preconfigured behaviour. Practitioners should treat agent identity as a separate governance problem with its own delegation model, audit chain, and runtime constraints.
A few things that frame the scale:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: When should organisations add a policy engine on top of OAuth?
A: Add a policy engine whenever the agent must decide between multiple valid actions at runtime, especially when the outcome depends on context, resource sensitivity, or conversation history. OAuth can validate the token, but only a policy layer can decide whether the specific action is acceptable now.
👉 Read our full editorial: OAuth for AI agents exposes the limits of static API keys