AI agent security depends on runtime context, not identity alone

At a glance

What this is: This is an analysis of why AI agent security needs runtime context, with the core finding that identity and authorization are necessary but not sufficient to judge agent behaviour.

Why it matters: It matters because IAM, NHI, and agentic AI programmes need controls that can evaluate purpose, data use, and workflow consistency, not just authenticated access.

👉 Read Zenity's analysis of AI agent security and runtime context

Context

AI agent security is the practice of deciding whether an agent's behaviour is appropriate at the moment it acts, not just whether it was permitted to authenticate. The article argues that identity tells you who showed up, while runtime context tells you whether the action made sense for the agent's declared purpose.

For IAM teams, that means identity controls remain foundational but incomplete when agents operate across static credentials, runtime tokens, tool identities, and delegated sub-agents. The governance gap is not access alone, but the ability to judge intent, data use, posture, and environment as one decision surface.

Key questions

Q: How should security teams assess AI agent behaviour beyond identity checks?

A: They should correlate identity with runtime signals such as data touched, model behaviour, posture, and environment. A valid login or token proves access, but it does not prove the action was appropriate for the task. Security teams need a decision model that can compare observed behaviour with declared purpose during execution.

Q: Why do AI agents create more risk than standard service accounts?

A: AI agents can change scope across a session, invoke tools dynamically, and delegate to other agents or services. That makes the effective privilege boundary fluid rather than fixed. Standard service account controls can confirm access, but they cannot reliably prove that the resulting behaviour stayed within the intended purpose.

Q: What do teams get wrong about authorization in AI agent security?

A: They often treat authorization as the final security decision when it is only the entry check. A system can authorize the same prompt twice and still produce very different risk outcomes if the runtime behaviour changes. The mistake is assuming permission and appropriateness are the same question.

Q: How should organisations govern agent-to-agent delegation?

A: They should treat delegation as a formal governance boundary, not just an integration pattern. That means defining what data can move between agents, how inherited permissions are recorded, and when delegated actions require review. Without that, one agent can extend another's access in ways the original control model never saw.

Technical breakdown

Why identity and authorization miss runtime intent

Identity and authorization answer a narrow question: was this actor allowed to connect and invoke a tool. Runtime intent is different. It asks whether the specific sequence of actions, data touched, and destination chosen still matches the agent's declared purpose at that moment. In multi-step workflows, the same permission set can support benign execution or inappropriate behaviour. That is why clean access logs can coexist with a serious incident. The security boundary shifts from approval of entry to evaluation of conduct during execution.

Practical implication: evaluate agent actions in context, not just at the point of login or token issuance.

Layered identities in AI agent workflows

AI agents rarely operate through one identity. They can use build-time service credentials, runtime tokens, inherited tool permissions, and delegated identities from other agents or integrations. Each layer changes the effective blast radius. If one layer is visible and the others are opaque, security teams can only see part of the chain. That creates false confidence, because a valid credential does not prove that the resulting activity was safe or aligned with the task.

Practical implication: map every identity layer an agent can touch, including tool and delegation identities.

Context signals that determine whether agent behaviour is appropriate

The article frames runtime context as a composite decision made from identity, data, model behaviour, agent posture, and environment. Data shows what was touched, model signals indicate manipulation, posture shows whether code or configuration drifted, and environment reveals surrounding anomalies. None of these signals is sufficient alone. Together, they tell you whether the agent remained within its declared purpose or drifted into risky territory that authorization alone would never flag.

Practical implication: build decisions from multiple telemetry domains instead of relying on a single IAM control.

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

Authorization without runtime context creates a false security boundary. The article shows that two identical prompts can produce materially different risk outcomes even when access is technically allowed both times. That means the decisive governance question is not whether the agent authenticated, but whether the action remained appropriate as the workflow unfolded. For practitioners, this is a reminder that access approval is only one layer of control.

AI agent security is becoming a multi-domain governance problem. Identity, data, model behaviour, posture, and environment all contribute to the final decision about whether an action is acceptable. No single control plane can answer that question on its own. The implication is that agent governance has to be treated as an integrated runtime discipline, not a narrow IAM extension.

Runtime context is the named control gap this article exposes. The runtime context gap was designed for a world where permissions and behaviour could be judged at different times. That assumption fails when an agent can change data scope, route output externally, or traverse sub-agent chains in the same session. The implication is that security teams must rethink what evidence is needed before they trust an agent's output.

Agent-to-agent delegation expands the identity boundary beyond traditional review models. When one agent invokes another, the original access decision no longer captures the full risk path. The behaviour that follows may be valid at the token level and still inappropriate at the task level. Practitioners should treat delegation as a governance boundary, not just a technical integration.

Identity hygiene remains necessary, but it does not prove appropriateness. The article is right to keep NHI hygiene in scope, because weak credentials still widen exposure. But the deeper lesson is that good credentials cannot validate intent, and intent cannot be inferred from authorization alone. The field needs runtime proof of purpose, not just proof of access.

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 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• That gap makes runtime context controls the next practical step, as shown in OWASP Agentic Applications Top 10.

What this signals

Runtime context is becoming the decision layer that separates useful AI agents from risky ones. As agents move from single-prompt tasks into multi-step workflows, identity checks will increasingly serve as a floor rather than a conclusion. Teams that only measure authentication and authorization will miss the behaviour changes that matter most at runtime.

Context engineering is now a security discipline, not just an implementation detail. When data access, model outputs, posture, and environment are evaluated together, the programme can explain why a specific action was acceptable or not. That is the operational difference between visibility and audit-ready governance.

The governance pattern to watch is the shift from permission review to purpose review, especially where delegated tools and sub-agents are involved. Organisations should expect agent oversight to look more like continuous behavioural evaluation than classical access certification, and the distinction will shape how controls are designed.

For practitioners

• Map agent identity layers end to end Inventory static credentials, runtime tokens, tool identities, and delegated agent permissions for each AI workflow. Document where identity changes during execution and where your current controls lose visibility.
• Correlate runtime context before trusting output Tie identity telemetry to data access, model behaviour, agent posture, and environment signals so reviewers can judge whether an action matched declared purpose. Treat any one signal as incomplete evidence.
• Define approval boundaries for sub-agent delegation Require explicit policy for when one agent can call another, what data can be passed, and how inherited permissions are recorded for audit. Without that boundary, delegation becomes an invisible extension of privilege.
• Separate permitted access from appropriate behaviour Update review workflows so they flag sessions where valid access produced unexpected records touched, new external endpoints, or task drift. Those are the cases where authorization logs alone are misleading.

Key takeaways

• AI agent security cannot rely on identity alone because permission does not prove that runtime behaviour was appropriate.
• Multi-step workflows and delegation chains create a visibility gap that classic authorization checks do not close.
• Practitioners need runtime context controls that combine identity, data, model, posture, and environment into one decision surface.

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.
• 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.
• Purpose Alignment: Purpose alignment is the degree to which an agent's observed behaviour matches the task it was intended to perform. For security teams, it is not a model quality metric. It is an operational test for whether the agent stayed within the scope, data use, and routing boundaries it was given.
• Identity Surface: The identity surface is the full set of credentials, tokens, tool permissions, and delegated identities an AI agent can use during execution. It matters because agents often do not operate through a single account, and partial visibility into that surface creates false confidence about control coverage.

Deepen your knowledge

AI agent runtime context is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for delegated workflows and behavioural governance, it is worth exploring.

This post draws on content published by Zenity: Identity Isn’t Enough: Why AI Agent Security Requires Runtime Context. Read the original.