AI agent security risks now depend on runtime governance

At a glance

What this is: This analysis explains why AI agents change the AI threat model by turning model output into runtime execution, with risk concentrated in tool use, identity delegation, memory, and chained actions.

Why it matters: It matters because IAM, PAM, and AI governance programmes must now control what autonomous or semi-autonomous systems can do after login, not just what they are allowed to generate.

👉 Read Zenity's analysis of why AI agents now define AI security risk

Context

AI agent security risks arise when systems move from producing answers to taking actions. That shift means the security problem is no longer just prompt safety or model quality, but runtime control over identity, data access, and tool execution in environments that were built for humans and static software.

For IAM and security teams, the issue is not whether agents are useful. It is whether existing controls can govern delegated credentials, continuous sessions, and cross-application workflows without losing sight of who or what is actually acting at any moment.

Key questions

Q: What breaks when AI agents are given human-level privileges?

A: The main failure is that a single delegated identity can now chain actions across systems, so one bad instruction or compromised token can trigger broad impact. Human-level privileges erase the separation between a helpful workflow and an abuse path. Teams should scope agent access to the minimum action set and make ownership explicit.

Q: Why do AI agents complicate IAM and PAM governance?

A: AI agents complicate IAM and PAM because they do not just authenticate, they act continuously after authentication. That means the real risk is not the login event but what the agent can do with delegated access, memory, and tool permissions. Governance must therefore focus on runtime authority and session behaviour.

Q: How do security teams know if an AI agent is crossing its intended boundary?

A: Look for new tool destinations, unusual action sequences, unexpected data retrieval, and privilege use that does not match the original task. A trustworthy agent should operate within a stable pattern. When behaviour becomes exploratory or compounding, the agent has likely moved outside its governed boundary.

Q: Who is accountable when an AI agent causes business impact?

A: Accountability sits with the organisation that assigned the agent access, not with the model itself. The owner of the workflow, the platform team, and the governance function all need clear responsibilities for approval, monitoring, and offboarding. Without that structure, autonomous execution creates accountability gaps that are hard to close after the fact.

Technical breakdown

Why AI agents change the security model

AI agents combine a model with identity, memory, tools, and execution rights. That combination is different from a chatbot or script because the system can decide what to do next, call an API, preserve context, and continue acting across multiple steps. Security risk appears after inference, when the agent retrieves data, invokes functions, and propagates state into other systems. Traditional controls such as prompt filters or design-time review do not observe that runtime behavior, so they miss the point at which action becomes impact.

Practical implication: govern the runtime envelope, not just the model prompt.

Identity and token compromise in agentic workflows

Agents often act through delegated identities such as service tokens, API keys, or human-level permissions. If those credentials are stolen or abused, the attacker inherits the agent's authority and can move through connected systems with legitimate access paths. This is why identity is central to agent security: the agent is not only processing information, it is operating as an authenticated actor inside the enterprise. Once identity is compromised, the trust boundary collapses from one workflow into many.

Practical implication: treat agent credentials as high-value secrets with narrow scope and clear ownership.

Prompt injection, tool misuse, and autonomous drift

Prompt injection works on agents because their instructions, retrieved context, and tool outputs can be blended into a single decision stream. That makes hidden or adversarial inputs capable of redirecting an agent toward unsafe actions, sensitive data exposure, or inappropriate tool invocation. Goal misalignment adds a second layer of risk: an agent can remain 'helpful' while taking unapproved substeps that satisfy its objective but violate policy. In practice, the failure mode is cumulative, not singular.

Practical implication: monitor for tool-call anomalies, unsafe context reuse, and action chains that exceed the original task.

NHI Mgmt Group analysis

Agentic AI creates an identity problem before it creates a model problem. The security issue is not simply that agents are smart, but that they act with delegated authority across systems, data, and workflows. Once an agent can choose tools and execute actions in production, governance has to answer for an acting identity, not just an output generator. Practitioners should treat this as a shift from model governance to identity governance at runtime.

Runtime visibility is the new control plane for AI security. Design-time reviews, static policies, and post-incident logs do not show how an agent chained actions in the middle of a session. That leaves a blind spot between approval and impact where abuse, drift, and excessive access accumulate. Security teams need control over what the agent touched, when it touched it, and which permissions were exercised in the process.

Ephemeral decisions break the assumption that access persists long enough to be reviewed. Access review and certification processes were designed for stable entitlements that can be observed after the fact. That assumption fails when an agent can acquire, combine, and use permissions within a single runtime sequence. The implication is not merely tighter review, but rethinking whether review-cadence governance can still describe the behaviour of autonomous execution.

Identity blast radius is now the right way to frame agent risk. The article’s core insight is that one mis-scoped agent can propagate across APIs, messaging platforms, and internal systems faster than a human operator could. That makes privilege scope, delegation chain depth, and action chaining the variables that matter most. Practitioners should assess how far an agent can travel once a single permission is abused.

Security frameworks are catching up, but the governance gap remains structural. OWASP, MITRE ATLAS, and NIST are all moving toward agent-specific risk language because existing application controls do not fully describe autonomous execution. That does not mean the problem is solved; it means the industry now recognises that agents need their own identity and runtime governance model. Practitioners should align agent controls to that emerging framework rather than bolt them onto legacy app security.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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, according to AI Agents: The New Attack Surface report.
• For the broader governance context, see OWASP Agentic AI Top 10 for the runtime risks that emerge when agents can choose tools and act independently.

What this signals

Identity blast radius: the practical unit of risk is no longer the model, but the distance an agent can travel once one permission is misused. With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance problem is already visible.

Teams should prepare for agent governance to converge with secrets management, PAM, and lifecycle control. The next phase is not simply stricter policies, but stronger ownership models for delegated action across SaaS, cloud, and internal automation.

The signal for practitioners is clear: runtime oversight will matter more than periodic review. If an agent can act faster than certification cycles can observe, then review-based governance must be supplemented by live behavioural controls and scoped delegation.

For practitioners

• Map every agent to an owning identity and business purpose Inventory each AI agent, the credentials it uses, the systems it can reach, and the business process it supports. Require a named owner who can answer for delegated access, permitted actions, and offboarding when the use case ends.
• Constrain delegated access to the smallest possible action set Separate read, write, and invoke permissions for agent workflows, and avoid human-equivalent privilege by default. Where an agent must act across systems, segment the workflow so no single identity can chain unrelated high-impact actions without explicit checks.
• Monitor tool calls and context reuse at runtime Log every tool invocation, data retrieval event, and permission exercised by the agent, then alert on unexpected sequencing or new destinations. Focus on behavioural drift, because agent misuse often appears as a plausible series of legitimate steps rather than a single obvious fault.
• Gate high-impact actions behind approval or compensating controls Require human approval, policy checks, or separate control paths before the agent can reset credentials, provision access, move data, or trigger external side effects. Reserve fully autonomous action for low-risk, tightly bounded tasks with reversible outcomes.

Key takeaways

• AI agents are no longer just AI outputs, they are runtime actors whose access can create enterprise impact.
• The evidence already shows widespread overreach, with agents acting beyond intended scope in most organisations surveyed.
• Practitioners should shift from model-centric controls to runtime identity, tool, and action governance.

Key terms

• AI Agent: A software entity that can choose actions, call tools, and continue execution without needing a human to approve every step. In security terms, the key issue is not whether it is intelligent, but whether it can act with delegated identity and create impact across systems.
• Delegated Identity: An identity granted to an agent so it can access data or services on behalf of a user, workflow, or platform. In agentic environments, delegated identity becomes a high-risk control point because it can carry human-equivalent authority into machine-paced execution.
• Runtime Governance: The set of controls that observe and constrain behaviour while an agent is actually operating. It matters because design-time policies and static reviews cannot fully describe what an adaptive system will do once it starts chaining tools and reusing context.
• Identity Blast Radius: The amount of damage an actor can cause once a credential, token, or permission is abused. For AI agents, blast radius is shaped by tool breadth, session persistence, and the ability to chain actions across multiple systems before anyone intervenes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 Zenity: Securing AI Where It Acts: Why Agents Now Define AI Risks Chris Hughes • Mar 12, 2026. Read the original.