AI agent identity shifts from delegated access to agentic trust

At a glance

What this is: This is an analysis of how AI agent identity differs from standard delegated application access, with emphasis on runtime reasoning, tool chaining, and the limits of legacy token-based trust.

Why it matters: It matters because IAM, NHI, and lifecycle controls built for stable app permissions and human approval flows do not fully describe how agents choose actions, tools, and execution order at runtime.

👉 Read Andromeda Security's analysis of AI agent identity and delegated authorization

Context

AI agent identity becomes a governance problem when the actor can choose actions and tools at runtime rather than following a fixed script. That breaks the assumptions behind conventional delegated authorization, where policy is checked once and the resulting token is expected to describe the whole session.

For identity teams, the issue is not just whether an agent can authenticate, but whether the enterprise can govern its permissions, trust path, and lifecycle as behaviour changes during execution. That puts NHI governance, workload identity, and agentic access control into the same operating discussion.

Key questions

Q: How should security teams govern AI agents that choose actions at runtime?

A: Security teams should govern runtime-selecting AI agents as named principals with explicit ownership, bounded tool access, and separate review paths from human users and ordinary applications. The key is to model the full execution chain, not just the first authenticated request. If the agent can change tools or sequence mid-session, static entitlement review is incomplete.

Q: Why do AI agents complicate delegated access models in IAM?

A: AI agents complicate delegated access because they do not always follow a fixed request path. A token issued for one purpose may be used in a longer, dynamic workflow that includes tool discovery, recursive calls, or delegated sub-actions. IAM teams need to understand the runtime behaviour, not just the initial authorization event.

Q: What do security teams get wrong about agent credentials?

A: The common mistake is treating agent credentials like ordinary application secrets and assuming possession equals control. In practice, embedded API keys and long-lived tokens make it hard to prove which agent used them, when they were used, or whether the usage still matches the original approval. That weakens both accountability and containment.

Q: When should organisations separate human, service account, and agent governance?

A: Organisations should separate them as soon as the same workflow includes both delegated user actions and persistent non-human access. Human approval patterns, workload identity controls, and agent runtime governance solve different problems. Treating them as one control set usually hides ownership gaps and makes reviews less meaningful.

Technical breakdown

Delegated authorization in OAuth-based app-to-app access

In the pre-agent model, one application acts on behalf of a user through a central identity provider that authenticates the user, validates the app, and checks enterprise policy before issuing a token. The resource server then trusts the signed token rather than the app directly. This works because the access path is predictable, the actor is bounded, and the token maps cleanly to a known user and approved application. The model assumes the request shape is known when the token is minted, which is why it fits structured app integrations but not runtime-driven agents.

Practical implication: treat OAuth delegation as a bounded pattern, and do not assume it can describe arbitrary agent behaviour.

Why AI agent runtime reasoning changes authorisation

An AI agent is not just an automated script. It receives a goal, reasons over steps at runtime, and decides which systems or other agents to consult in sequence. That makes the control flow probabilistic rather than hard-coded, and the permission question shifts from one approved action to a chain of possible actions. In identity terms, the hard problem is not only who or what the agent is, but how its decisions alter the scope of access mid-session. That is why static entitlement models understate the operational risk.

Practical implication: review agent permissions as an execution path problem, not a single access grant.

MCP, A2A, and the legacy API key shortcut

The article highlights four access patterns: MCP for tool connections, A2A for agent-to-agent discovery, an enterprise principal model for named agent identities, and hard-coded API keys in environment variables as the legacy shortcut. MCP and A2A expand the number of decision points because the agent can discover and invoke tools dynamically. Hard-coded secrets bypass that complexity but create durable exposure if the secret is reused or leaked. The security issue is not just transport, but how identity, trust, and execution authority are established across chained calls.

Practical implication: inventory which agent connections still depend on embedded secrets and replace those paths first.

NHI Mgmt Group analysis

Delegated authorization was designed for predictable requests, not runtime-selected agent behaviour. The OAuth-based model works because the user, app, and policy decision are all known at the moment the token is minted. That assumption fails when the actor can choose tools and call sequences dynamically after authorisation. The implication is that identity programmes must stop treating agent access as a normal app integration problem.

Runtime reasoning turns access scope into a moving target. A human or scripted service usually enters a session with a bounded purpose, but an AI agent can alter the path as it works through sub-goals. That means the effective privilege boundary is not fully knowable at provisioning time. For practitioners, this is a direct challenge to entitlement models that assume intent is stable before execution begins.

Hard-coded API keys create the weakest possible trust model for agents. When an agent uses environment-stored credentials to bypass auth flows, the enterprise loses the ability to distinguish between legitimate execution and secret reuse. This is not just poor hygiene; it is a fragile substitute for an identity model. The practitioner conclusion is that agent trust cannot be built on credentials that outlive the action they were meant to authorise.

Agent identity governance now sits between NHI lifecycle and autonomous trust design. The article sits in the transition zone where workload identities, service-account patterns, and agentic decision-making overlap. That means identity teams have to evaluate whether existing NHI controls are being stretched beyond the conditions they were built for. The field should treat agent identity as a distinct governance problem, not a renamed service account.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap is why identity teams should pair runtime controls with a broader view of agent access patterns, not just a single tool integration story; see OWASP Agentic Applications Top 10.

What this signals

Agent identity will be judged by observable behaviour, not by how convincingly it mirrors application access. The real programme question is whether a control plane can still explain who authorised what, when tool choice changes mid-session. For teams building out governance, the useful next step is to align agent reviews with broader identity lifecycle thinking and the OWASP Agentic AI Top 10.

With 52% of organisations able to track and audit AI agent data access, the majority are already operating with partial visibility into a class of identities that can move faster than their review process. That should push practitioners to treat agent onboarding, offboarding, and access review as first-class governance work, not an edge case.

For practitioners

• Map each agent to a named identity and owner Record the agent principal, the business owner, the systems it can call, and the approval path that created it. If a team cannot name the owner or explain the entitlement boundary, the agent is already outside normal governance.
• Replace embedded secrets with managed workload identity Find agents that still rely on API keys in environment variables or config files, then move them to managed credential paths with explicit rotation and audit controls. Prioritise the connections that expose the broadest downstream access.
• Review where approval assumptions break at runtime Identify agent workflows that can change tool choice, call order, or delegation sequence after the initial grant. Those are the places where static approval no longer describes actual behaviour, and where policy needs a different control pattern.
• Separate copilot flows from autonomous service flows Do not govern a human-in-the-loop assistant the same way you govern an always-on agent that runs outside a user session. Build distinct control baselines for delegated access, persistent service accounts, and agent-to-agent chaining so reviews match the actor type.

Key takeaways

• AI agents create an identity problem because they can decide how to act after access has been granted, which breaks assumptions built for static application workflows.
• The strongest evidence in the article is that agents increasingly rely on runtime reasoning, MCP-style tool access, A2A chaining, and in some cases hard-coded secrets, all of which widen governance risk.
• Identity teams should separate delegated copilot flows, persistent service identities, and runtime agent governance so that ownership, review, and containment match the actor type.

Key terms

• Delegated Authorization: A pattern where one application is allowed to act on behalf of a user after a central authority checks identity, app legitimacy, and policy. In agentic settings, the key limitation is that the grant often reflects the start of execution, not every later decision the software may make.
• Workload Identity: An identity assigned to software rather than a person, used by services, jobs, and agents that operate independently of a human login session. For agents, workload identity only becomes trustworthy when ownership, scope, and lifecycle are clear enough to survive runtime decision-making.
• Runtime Reasoning: The ability of an AI system to choose steps, tools, or sequence at execution time instead of following a fixed script. In identity governance, runtime reasoning matters because it makes the real access path harder to predict, review, and certify before the action completes.
• On-Behalf-Of Flow: An access pattern where a service or agent uses a user context to reach downstream resources without holding a standalone user password. It is common in delegated scenarios, but it becomes weaker when the software can independently alter its path or expand its tool use at runtime.

What's in the full article

Andromeda Security's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step walkthrough of OAuth 2.0 delegated authorization in app-to-app enterprise flows.
• The full breakdown of MCP, A2A, enterprise principal, and legacy API key access patterns for agents.
• The article's own explanation of why runtime reasoning changes trust decisions at the identity layer.

👉 The full Andromeda Security article expands the control-flow examples and access pattern comparisons.

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 building or maturing identity security practice, it is worth exploring.