Notifications
Clear all
Topic starter
06/06/2026 11:08 am
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.
NHIMG editorial — based on content published by Zenity: Identity Isn’t Enough: Why AI Agent Security Requires Runtime Context
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map agent identity layers end to end Inventory static credentials, runtime tokens, tool identities, and delegated agent permissions for each AI workflow.
- 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.
- 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.
What's in the full article
Zenity's full blog post covers the operational detail this post intentionally leaves for the source:
- The article's full breakdown of how runtime context combines identity, data, model, posture, and environment into one security decision.
- The specific scenarios showing how the same prompt can produce different risk outcomes across different execution paths.
- The discussion of agent-to-agent delegation and why inherited permissions complicate accountability.
- The source article's framing of how organisations can think about building contextual controls in live environments.
👉 Read Zenity's analysis of AI agent security and runtime context →
AI agent runtime context: are your controls keeping up?
Explore further
06/06/2026 11:46 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent security depends on runtime context, not identity alone
