Securing AI agent identities requires narrow delegation and runtime control

At a glance

What this is: This practical guide argues that every AI agent needs a first-class identity, scoped delegation, and runtime oversight to prevent hidden privilege expansion and misattribution.

Why it matters: It matters because IAM, PAM, and NHI teams must govern agents as discrete actors, not as anonymous automation, or they will lose attribution, revocation control, and blast-radius containment.

👉 Read Identra.ai's guide to securing AI agent identities

Context

AI agent identity is a governance problem before it is a tooling problem. When an agent acts under a borrowed human account or a shared service account, attribution breaks, revocation becomes unsafe, and privilege quietly expands beyond the task the agent was meant to perform.

The operational question is not whether agents can call tools, but whether each deployment has a distinct identity, a named owner, and a narrow delegation path. That is the difference between a controllable workload and an unmanaged non-human identity fleet.

This guide treats agent identity as part of the wider IAM and NHI model, with runtime controls, lifecycle management, and auditability applied at the deployment, session, and downstream token levels.

Key questions

Q: How should security teams govern AI coding tools that create non-human identities?

A: Teams should treat every AI coding tool that can authenticate or call systems as a non-human identity with an owner, a scope, and a lifecycle. That means inventorying its credentials, limiting its permissions, monitoring its runtime actions, and revoking access when the task ends. Security policy should cover the agent, not just the code it helps produce.

Q: Why do shared service accounts create risk for AI agents?

A: Shared service accounts hide which agent made a request, so they collapse accountability and make incident response slower. They also turn credential exposure into a single compromise path for multiple workloads. For agentic systems, every identity should be attributable to a specific workload or delegated task.

Q: What breaks when AI tools are exposed through loosely governed MCP servers?

A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.

Q: How do organizations prove AI agent controls are actually working?

A: Organizations prove control effectiveness by showing which agents accessed which data, what actions they executed, and whether those actions stayed within approved task boundaries. Useful evidence includes logs, policy decisions, anomaly alerts, and review records. Without that chain, governance is mostly declarative.

Technical breakdown

Why borrowed accounts fail for AI agents

A borrowed account collapses the distinction between human intent and agent action. If an agent runs under a developer or shared service account, logs cannot distinguish who did what, revocation cannot be selective, and accumulated entitlements become agent reach by default. That is especially dangerous because agents do not just hold access, they spend it dynamically across tools and APIs. The real technical issue is not convenience, but delegated authority that is too broad to attribute, too persistent to contain, and too noisy to govern after the fact.

Practical implication: stop treating shared human or service credentials as a viable execution model for agents.

How scoped tokens and MCP authorization narrow delegation

The guide ties agent governance to OAuth token exchange and MCP authorization because each hop in the chain should carry less authority, not more. A deployment-scoped identity, one audience per token, and no token passthrough at MCP servers prevent a downstream tool from inheriting unrelated privileges. This matters because MCP requests are structured, but structure alone does not constrain power unless the token minted for the request is audience-bound and purpose-bound. The architecture only works when delegation is explicit and downscoped at every exchange.

Practical implication: enforce per-hop scoping and reject any design that allows token passthrough across agent tool boundaries.

Why runtime baselining must sit beside deterministic controls

Allowlists, egress policy, sandboxing, and approval gates block known-bad actions before execution, but they do not tell you when a permitted agent has been hijacked inside its allowed envelope. That is why behavioural baselining per agent identity matters. Once each agent has a real identity, you can compare actual tool use, destination patterns, volume, and trigger context against normal behaviour. The technical insight is simple: prevention limits blast radius, while baselining finds misuse that looks superficially valid because it stays within granted permissions.

Practical implication: pair deterministic authorization with per-identity behavioural detection rather than relying on one control layer alone.

Threat narrative

Attacker objective: The attacker objective is to abuse a trusted agent identity to perform actions and access data at a scale that appears legitimate to logs and controls.

1. Entry occurs when an AI agent is deployed under a borrowed human account or a shared service account, giving it broad standing access before any task-specific controls exist.
2. Escalation occurs when the agent inherits accumulated entitlements, then uses structured tool calls and downstream APIs to exercise more authority than the original task required.
3. Impact occurs when a hijacked agent spends the access it holds, producing unauthorised reads, writes, external actions, or cascading downstream abuse that is difficult to attribute or revoke cleanly.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Borrowed identity is the original design failure in AI agent governance. The guide is right to treat shared human accounts and generic service accounts as anti-patterns, because both erase the boundary between operator and executor. That boundary is the basis for attribution, selective revocation, and purpose-bound access in IAM and NHI programmes. Practitioners should stop asking whether an agent can be made convenient to deploy and start asking whether it can be named, owned, and retired without collateral damage.

Identity does not stay stable enough for static least privilege to remain sufficient once the actor is agentic. Least privilege was designed for predictable execution paths and human-paced review loops. That assumption fails when an agent decides its own step order, tool sequence, and execution timing within a session. The implication is that access governance has to account for runtime authority shaping, not just provisioning-time entitlement choice.

Runtime detection only works after identity has been made granular enough to observe. Behavioural baselining per agent identity is valuable because it gives defenders a way to distinguish permitted use from permitted misuse. But the deeper point is that detection cannot rescue anonymous automation. If all agents share one identity, the telemetry becomes unusable and the control plane loses the ability to separate normal workload variation from abuse. Practitioners should treat identity granularity as a detection prerequisite, not a downstream enhancement.

Downscoping at every hop is the governance pattern that makes delegated AI survivable. OAuth token exchange, audience restriction, and no token passthrough at MCP servers all point to the same control principle: authority must narrow as execution moves outward. That principle aligns with OWASP Non-Human Identity Top 10 and the OWASP Agentic AI Top 10 because the risk is not only credential exposure, but the way a trusted identity can be repurposed across tools. Practitioners should design delegation chains as a sequence of constrained identities, not as a single identity stretched across systems.

Agent lifecycle must be treated as workforce governance, not asset inventory. The guide's joiner-mover-leaver model is the right mental model because agents change purpose, environment, and ownership just like employees do. The issue is not simply offboarding, but preventing orphaned access from becoming the default state of the fleet. Practitioners should make every deployment reviewable, releasable, and re-owned on a defined cadence.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why orphaned machine access persists long after ownership changes.
• The next step is to align agent lifecycle controls with 52 NHI Breaches Analysis, so teams can connect delegation, offboarding, and incident patterns to real failure modes.

What this signals

Borrowed accounts will become the most visible governance anti-pattern in agent programmes. As AI agents move from pilots into production workflows, the control problem shifts from whether they can act to whether they can be named, owned, and revoked without disrupting a human operator. Teams that still rely on shared accounts will find that audit quality degrades faster than agent volume increases.

Ephemeral delegation debt: short-lived tokens do not solve governance if the underlying identity model remains coarse. The more a programme depends on token lifetime alone, the more it will miss the fact that standing privilege, shared identities, and environment bleed still define the true blast radius.

Agent governance will increasingly sit at the intersection of directory design, runtime telemetry, and lifecycle discipline. That means IAM and PAM teams should prepare for agent inventories, agent-specific review cadence, and incident playbooks that can separate a live agent session from the account that spawned it.

For practitioners

• Assign every agent deployment a distinct directory identity Record one named human owner, one narrow purpose statement, and one retirement path for each deployed agent. Do not allow a developer account or shared service account to stand in for the agent itself.
• Downscope authority at each delegation hop Require one audience per token, enforce RFC 8693-style token exchange profiles, and block token passthrough at MCP servers so downstream tools never inherit unrelated privilege.
• Separate environments by identity, not by policy alone Give development and production different agent identities, keep dev agents on synthetic or masked data, and treat any cross-environment grant as a finding until it is explicitly approved.
• Combine deterministic controls with behavioural baselines Use allowlists, egress policy, sandboxing, and approval gates in front of runtime activity, then baseline tool use, data volume, trigger sources, and destinations per agent identity.
• Build a real agent offboarding path Revoke issued tokens, rotate any static credentials, terminate downstream sessions, and remove or quarantine the identity when purpose ends or ownership changes.

Key takeaways

• AI agents should be governed as distinct identities, not as anonymous automation or borrowed accounts.
• Static privilege and shared credentials create attribution gaps, revocation problems, and hidden blast-radius growth.
• The practical control stack is narrow delegation, per-identity runtime detection, and lifecycle-managed offboarding.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Behavioural Baselining: Behavioural baselining is the process of learning how an identity normally behaves so deviations can be detected as risk signals. The baseline usually includes device, location, timing, and action patterns, and it becomes more valuable when used after authentication rather than as a replacement for it.
• Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.

What's in the full article

Identra.ai's full guide covers the operational detail this post intentionally leaves for the source:

• A step-by-step identity pattern for deployment-level agents, including owner fields, purpose scoping, and retirement handling.
• Practical guidance on token exchange, audience restriction, and MCP authorization boundaries for delegated execution.
• A rollout model for inventorying agents, setting review cadence, and managing shadow-agent discovery across the fleet.
• Control examples for approval gates, sandboxing, egress restrictions, and behavioural baselines in live agent environments.

👉 Identra.ai's full guide covers delegation, lifecycle governance, and runtime control patterns in more operational detail.

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.