AI kill chains expose why identity must govern autonomous agents

At a glance

What this is: Silverfort uses NVIDIA’s AI Kill Chain to argue that AI security now depends on governing the identities and authority of agents, not just protecting models.

Why it matters: That matters because IAM, PAM, and NHI programmes will need to control who an agent acts as, what it can access, and how its delegated authority is audited.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Silverfort’s analysis of the AI Kill Chain and agent identity risk

Context

AI agent identity risk is emerging because these systems do not just process data, they act under delegated authority. When an agent can query systems, send messages, or trigger workflows, the central question is no longer only model safety. It becomes which identity is acting, what it can reach, and how far that authority extends across the enterprise.

Silverfort’s source article uses NVIDIA’s AI Kill Chain as a way to explain that shift, but the more important governance point is broader: existing IAM assumptions were built for human users and service accounts with relatively stable behaviour. Autonomous and semi-autonomous agents can make identity boundaries harder to see, harder to review, and easier to abuse if their authority is left implicit.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Security teams should govern AI agents as delegated identities with owners, scopes, and review points. The key is to control what the agent can reach, who is accountable for it, and how actions are attributed. Without those controls, the agent can behave like an invisible extension of privileged access rather than a bounded actor.

Q: Why do AI agents create more identity risk than ordinary automation?

A: AI agents create more identity risk because they can decide which tools to use and when to use them within a delegated task. That makes their behaviour less predictable than scripted automation. The result is a larger governance gap around authorisation, attribution, and scope drift.

Q: What breaks when an AI agent is treated like a normal service account?

A: What breaks is the assumption that behaviour is stable enough for static review. An AI agent can change action paths at runtime, so a normal service-account model may miss scope creep, hidden delegation, or policy-compliant misuse. The control gap is not the credential alone, but the runtime decisions made through it.

Q: Who is accountable when an AI agent causes unauthorised actions?

A: Accountability should rest with the business owner of the agent, the team that approved its delegated access, and the controls that failed to constrain or monitor it. If the organisation cannot identify those parties clearly, it has not yet established a workable governance model for AI identity.

Technical breakdown

How the AI kill chain changes when the actor is an agent identity

NVIDIA’s framework is useful because it turns AI attacks into a sequence security teams can model: reconnaissance, exploitation, and command and control. In agent environments, each stage maps to identity rather than only infrastructure. Reconnaissance means discovering agent privileges and reachable data. Exploitation means influencing the agent to take a legitimate action for illegitimate intent. Command and control becomes delegated control through the agent’s trusted identity. That is why the actor matters as much as the model. If the identity is not governed, the attack path remains valid even when the model itself is behaving as designed.

Practical implication: Map AI agent authority as an identity problem, not only a model risk problem.

Why delegated authority is the real trust boundary for autonomous systems

An AI agent becomes operationally meaningful when it is assigned credentials, scopes, and an owner. Those elements create the trust boundary. If an agent can approve actions, call APIs, or move through workflows without fresh human review, then its delegated authority becomes the attack surface. This is where traditional tooling often underestimates risk, because nothing necessarily looks anomalous from a policy perspective. The system is simply using permissions that were already granted. The security question is therefore not whether the agent is intelligent. It is whether the authority it inherits is bounded, attributable, and continuously governed.

Practical implication: Treat delegated authority as the primary control point for AI agent governance.

What identity telemetry needs to prove for AI-powered workflows

Identity telemetry has to answer three questions consistently: who initiated the action, on whose behalf it happened, and whether the resulting behaviour stayed inside the intended scope. For human users, those questions are usually separable. For agents, they can collapse into one runtime chain of delegated decisions. That is why continuous authentication, behavioural baselines, and traceable attribution matter more here than a simple access grant. Without those signals, an agent can appear compliant while still being steered into undesirable actions inside its allowed permissions.

Practical implication: Instrument AI workflows so attribution and scope are visible at runtime, not only at provisioning.

Threat narrative

Attacker objective: The attacker wants to hijack delegated authority so the agent performs harmful actions while appearing to operate within approved access.

1. Entry happens when an attacker discovers an agent identity with useful permissions, such as access to databases, messaging tools, or workflow systems.
2. Escalation occurs when the attacker manipulates the agent’s logic so that a legitimate permission is used for illegitimate intent, expanding the effect of existing access.
3. Impact follows when the trusted identity is used to trigger approved actions invisibly, allowing data access, workflow abuse, or transactional fraud inside normal policy boundaries.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agent identity is becoming the control plane for AI security. The article is right to move the discussion from model protection to the identity that a model acts through. Once an AI system can call tools, make decisions, and execute actions on behalf of a user, its identity is no longer a bookkeeping detail. It is the trust boundary that determines whether the system can be governed at all. The practitioner conclusion is straightforward: AI security and identity governance are now the same conversation.

Least privilege was designed for stable actors with known intent at provisioning time. That assumption fails when an AI agent can select actions dynamically and adapt its behaviour mid-session. The implication is not just that controls are missing. The premise itself changes, because authority is no longer a static forecast of future use. Practitioners must rethink how privilege is defined when runtime behaviour is part of the actor, not just the workload.

Identity blast radius is the right concept for agentic environments. The article shows that a single trusted agent can concentrate access across databases, workflows, and approvals. That makes compromise or manipulation more consequential than in a normal application stack, because the agent can operate invisibly inside its granted scope. The practitioner conclusion is that visibility into each agent’s reachable tools and delegated permissions becomes a baseline control, not an advanced one.

Continuous authentication and behavioural baselines matter more for agents than for static workloads. Traditional access controls answer who got in, but agent security also has to answer whether the actor’s behaviour still matches the intended role. That is especially important when the same identity can query, decide, and act in one chain. The practitioner conclusion is to govern the runtime behaviour of the identity, not only the credential it carries.

The trust chain replaces the old request-response security model. The source article’s core insight is that accountability now depends on knowing which actor initiated a task, which delegated identity executed it, and which boundaries were crossed. That is a governance pattern, not a product feature. The practitioner conclusion is to align agent governance with identity lifecycle, ownership, and auditability from the start.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Another finding from our Ultimate Guide to NHIs shows that 71% of NHIs are not rotated within recommended time frames, which leaves standing access exposed for longer than many programmes realise.
• The governance gap is not abstract, so use 52 NHI Breaches Analysis to examine how unmanaged machine identities turn into repeatable attack paths.

What this signals

Agent governance will increasingly be measured by runtime visibility, not by the presence of a policy. If teams cannot tell which identity acted, what it touched, and whether that action stayed inside intended scope, then the programme is still operating at provisioning-time thinking. The next maturity step is to connect delegated authority to observable behaviour across the full workflow.

Identity blast radius is the concept most teams are underestimating. The more tools and data sources an agent can reach, the more damaging a single compromise or logic manipulation becomes. That means privilege review has to move from abstract entitlement lists to concrete reachable actions, with attention to what an agent can do without fresh review.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, agentic environments inherit a pre-existing over-privilege problem and amplify it with runtime decision-making. The practical response is to align ownership, access boundaries, and auditability before agent adoption spreads faster than governance can catch up.

For practitioners

• Inventory every AI agent identity Record each agent’s owner, purpose, credentials, and tool reach so you can distinguish a governed actor from an unmanaged automation path.
• Constrain delegated authority by use case Assign the narrowest workable scopes for databases, messaging, approvals, and workflow tools, then review whether the agent still needs each privilege after deployment.
• Log who acted on whose behalf Capture initiation context, delegated identity, and downstream actions in a form that supports investigation, certification, and incident review.
• Review AI workflows as lifecycle objects Apply ownership, recertification, and offboarding discipline to agent identities so abandoned or overextended access does not persist beyond the business need.

Key takeaways

• AI agents are not just workloads, they are governed actors whose identities define the real security boundary.
• Traditional IAM assumptions break down when delegated authority can be used dynamically inside a single runtime session.
• Teams that cannot attribute actions to a specific agent identity will struggle to contain, review, or explain AI-driven abuse.

Key terms

• Agent Identity: An agent identity is the credentialed representation an AI system uses when it acts in an enterprise environment. It carries ownership, permissions, and audit context, which means the organisation governs the actor, not just the model. For autonomous systems, that identity can change risk materially because action is runtime-driven.
• Delegated Authority: Delegated authority is permission given to one actor to act on behalf of another within defined limits. In AI environments, it matters because the agent may initiate actions dynamically without a human at the keyboard. Governance must therefore cover scope, attribution, and revocation as part of the identity lifecycle.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised or manipulated identity can cause based on the access it holds. For agents, the term is especially important because one identity may span tools, workflows, and data sources. Reducing blast radius means narrowing reachable actions, not just tightening a policy statement.

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.

This post draws on content published by Silverfort: NVIDIA’s AI Kill Chain and what it means for AI agent identity governance. Read the original.