By NHI Mgmt Group Editorial TeamBased on Zenity: “Identity Isn’t Enough: Why AI Agent Security Requires Runtime Context” (April 3, 2026)

TL;DR: AI agent security cannot stop at identity and authorization because both can approve the same request while runtime behavior diverges sharply, including broader data access and unfamiliar external routing, according to Zenity. The decisive control is context at execution time, not access checks at provisioning time.


At a glance

What this is: This analysis says AI agent security depends on runtime context, because identity and authorization can both approve the same request while the actual behavior changes materially.

Why it matters: IAM, NHI, and agentic AI programmes need controls that assess what an agent did in context, not only what it was allowed to do at provisioning time.


Context

AI agent security is not solved by knowing which identity authenticated. For autonomous or semi-autonomous agents, the governance problem is whether the runtime action sequence still matches the task, data scope, and expected behaviour.

Zenity's example shows why this matters: the same prompt and access chain can yield a narrow, expected execution in one run and a much broader, externally routed action in another. The core issue is not access alone, but whether the activity is appropriate in the moment it occurs.

That makes runtime context the control boundary for AI agents, especially where they operate across tools, APIs, MCP-connected services, and delegated sub-agents.


Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Why does runtime context matter more than access checks for AI agents?

A: Runtime context matters because AI agents can change behaviour after access is granted. The risk is not only who is authenticated, but whether the agent's observed activity still fits its declared purpose, data scope, and operating environment at the moment it executes.

Q: How can security teams tell whether AI agent access is drifting out of scope?

A: Look for agents touching systems, data sets, or tools that are outside the intended task boundary, especially when those actions are not part of the approved workflow. Behavioural baselines, entitlement logs, and cross-system correlation are the key signals. If the agent can act meaningfully outside its original purpose, scope drift is already happening.

Q: Should organisations use both network and identity controls for AI agents?

A: Yes, but only as layered enforcement, not as a complete answer. Identity controls restrict what the agent may access, while network controls restrict where traffic may go. Neither one can determine whether a permitted action is actually safe, so runtime behavioural enforcement still has to fill the gap.


Technical breakdown

Why identity and authorization are not enough for AI agents

Identity and authorization are necessary but incomplete controls for AI agents. Identity answers who showed up and authorization answers what was permitted, but neither tells you whether the agent's runtime behaviour still matches its declared purpose. That gap matters because agents can execute the same approved prompt in materially different ways, including different data scopes, tool routes, and delegation chains. The security decision therefore has to incorporate purpose, environment, data touched, and behaviour at the moment of action, not just access at provisioning time.

Practical implication: treat identity as an input to AI agent governance, not the final control decision.

What layered identities change in agent security

AI agents rarely operate under a single stable identity surface. Static credentials may exist at build time, while runtime tokens, inherited permissions from tools, and delegated A2A interactions all shape what the agent can do in session. That creates multiple places where risk can expand without a change in the original user request. An access review or entitlement check over one layer can miss the actual execution path if the agent inherits privileges from MCP servers, APIs, plugins, or sub-agents during the workflow.

Practical implication: map the full identity surface, including inherited and delegated access, before assuming the agent's authorisation picture is complete.

Why runtime context becomes the control plane for autonomy

As agents become more autonomous, the difference between allowed and appropriate becomes the governing question. A simple RAG workflow with human checkpoints is easier to bound than a multi-step agentic workflow that can delegate, expand scope, and move data across trust boundaries without synchronous review. In that environment, runtime context becomes the only practical way to distinguish approved behaviour from risky drift. The control challenge is not just whether the agent had a valid token, but whether the observed behaviour still fits the declared task and operating environment.

Practical implication: evaluate AI agent control designs around behaviour at execution time, especially for multi-step and delegated workflows.


Threat narrative

Attacker objective: The objective is to move an AI agent beyond its declared purpose so that it accesses or routes data in ways that authorization alone would not flag.

  1. Legitimate access is granted when the same user prompt and access chain are accepted for execution.
  2. Scope drifts mid-session when the second run touches broader records and routes data differently from the first.
  3. Tool and endpoint misuse appears when the agent sends output to an external destination it has never used before.
  4. Impact follows when authorization logs still look clean while the runtime behaviour has already crossed the intended boundary.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Runtime context is now the decisive control boundary for AI agents: Identity and authorization answer access, not appropriateness. When the same prompt and access chain can produce materially different outcomes, security programmes need a control plane that judges behaviour in execution, not only entitlement at setup. The practitioner conclusion is that AI agent governance fails if it stops at who authenticated.

Layered agent identity creates hidden governance blind spots: Static credentials, runtime tokens, inherited tool permissions, and delegated A2A interactions all contribute to what the agent can actually do. A control that reviews only the originating identity can miss the effective privilege surface created during orchestration. The practitioner conclusion is that the identity model must follow the workflow, not just the initial login event.

Appropriateness has replaced access as the harder security question: The traditional question asks whether an agent may reach a system; the more important question asks whether the observed action still makes sense given purpose, data touched, and runtime environment. That is a governance shift, not a tuning exercise. The practitioner conclusion is that AI agent security programmes need runtime policy decisions, not only pre-execution approvals.

Context-aware policy is the missing concept for agentic security: The article surfaces a runtime context gap, where identity checks pass but behavioural risk remains invisible. That gap spans data, model behaviour, posture, and environment, which means no single control domain can prove safety on its own. The practitioner conclusion is to treat runtime context as the security primitive for agentic workflows.

Assumption collapse is the real story here: The assumption that authorization is sufficient was designed for systems where access and action are closely coupled. That assumption fails when the actor is an AI agent because the same allowed request can unfold into different tool use, data access, and routing decisions at runtime. The implication is that identity governance must stop treating permission as evidence of safety.

From our research library:

What this signals

Runtime context is the control gap practitioners should now operationalise: AI agents can pass identity checks while still drifting into broader data use or unfamiliar routing. Programmes that stop at provisioning-time authorisation will keep generating clean logs and unclear risk signals.

The governance shift is from access verification to behaviour verification. That means the control question becomes whether the agent's observed actions still fit the declared task, the approved data scope, and the current environment.

Context-aware agent governance: this is the practical concept emerging from the article, and it should shape how teams design reviews, policy enforcement, and escalation thresholds for multi-step workflows.


For practitioners

  • Define runtime context as a control objective Document which signals must be present before an AI agent's output is considered acceptable, including identity, data touched, tool path, model behaviour, posture, and environment.
  • Inventory every identity layer the agent can inherit Map static credentials, runtime tokens, tool permissions, MCP-connected services, and delegated A2A access so hidden privilege paths do not sit outside the review boundary.
  • Set behavioural thresholds for agent workflows Define what makes an action proportionate to the task, then flag runs that broaden record access, change routing destinations, or deviate from declared purpose.
  • Review human approval points around delegation Check where human review still exists in multi-step or multi-agent workflows and whether it is late enough to catch scope drift before data leaves the trusted boundary.

Key takeaways

  • AI agent security cannot be judged from identity and authorization alone when the same allowed request can produce materially different runtime behaviour.
  • The article shows why broader data access and unfamiliar external routing can appear even when the access chain is unchanged.
  • Security teams need runtime context, behavioural thresholds, and delegated identity visibility before they can trust agentic workflows.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centres on agents whose effective privilege changes at runtime despite the same access chain.
ASI02 — Tool MisuseThe risk includes unexpected tool selection and external routing that authorization alone does not catch.
Recommendation — Assess agent execution paths for privilege expansion and constrain tool and data use to declared purpose. Monitor agent tool calls for off-scope actions and block runtime use of unapproved endpoints.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article discusses layered identities, runtime tokens, and delegated access across agent workflows.
NHI-05 — Overprivileged NHIBroader data access in the second run shows effective privilege exceeding the intended task scope.
Recommendation — Bind each agent identity layer to its approved scope and verify it during execution, not only at issuance. Reduce agent privilege to the minimum data and tool scope needed for the declared workflow.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is fundamentally about governance over AI behaviour and accountability for runtime decisions.
Recommendation — Establish governance for runtime AI decisions and require accountability for behaviour as well as access.

Key terms

  • Runtime Context: Runtime context is the set of signals used to judge whether an AI agent's behaviour is appropriate while it is acting. It includes identity, data access, model behaviour, posture, and environment. In practice, it is the difference between checking permission and evaluating purpose.
  • Layered Identity Surface: A layered identity surface is the full set of identities and permissions a coding agent uses across its lifecycle. It includes static credentials, runtime session tokens, and permissions inherited from connected tools such as MCP servers. Traditional IAM often sees only the outer layer, leaving deeper operational risk unaddressed.
  • Behavioural Appropriateness: The security judgment that an action still makes sense given the agent's declared purpose, data scope, and operating environment. For AI agents, this is distinct from authorization because a permitted action can still be risky, excessive, or operationally inconsistent.
  • Agent-to-Agent Delegation: Agent-to-agent delegation is the handoff of work from one AI agent to another, often across different tools or identity contexts. It expands the governance boundary because the original actor no longer controls every action, and inherited permissions can create risk that the first approval never covered.

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 building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org