AI agent security now hinges on runtime boundaries and trust

At a glance

What this is: This summit recap argues that securing AI agents now depends on runtime boundaries, monitoring, and explicit approval gates as agents evolve into active security risks.

Why it matters: It matters because IAM, PAM, and governance teams must extend their controls to AI agents whose identity, tools, and behaviour can change during execution.

By the numbers:

• 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%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Zenity’s summit recap on AI agent security and runtime trust

Context

AI agent security is no longer a theoretical problem about future autonomy. The governance gap is that agents can change tools, actions, and timing at runtime, which breaks assumptions built into conventional IAM and application controls.

Zenity’s summit recap puts prompt injection, memory poisoning, unapproved MCP servers, and agent-insider behaviour into one operational frame. That is the right lens for security teams: treat AI agents as identities that require runtime control boundaries, not just policy statements.

The article also reflects a broader market shift. Security teams are moving from asking whether agents can be secured to deciding which runtime controls, monitoring signals, and approval boundaries must exist before deployment scales further.

Key questions

Q: How should security teams govern AI agents that can select tools at runtime?

A: Security teams should treat runtime tool selection as an access decision, not just a code-path decision. Put approval gates around new tools, connectors, and external data sources, then log every expansion in the agent’s effective privileges. Governance only works when tool discovery, authorisation, and audit trails are tied together.

Q: Why do AI agents complicate existing IAM and PAM models?

A: AI agents complicate IAM and PAM because their identity is not fully static during execution. A human or service account usually has a clearer entitlement boundary, but an agent can change actions, tools, and timing in response to context. That makes least privilege harder to define and privileged access harder to review in real time.

Q: What do security teams get wrong about prompt injection in agentic AI?

A: Teams often treat prompt injection as a content filter problem when it is really a runtime control problem. The agent may still follow malicious instructions if the execution path, tools, or retrieval sources are not constrained. Security needs to cover the whole instruction-to-action chain, not only the input layer.

Q: Who should be accountable when an AI agent causes a security incident?

A: Accountability should rest with the team that owns the agent, its approved tools, and its runtime controls. That ownership must include identity governance, monitoring, and incident response responsibilities. Without a named owner, agent behaviour becomes an operational blind spot rather than a managed risk.

Technical breakdown

Runtime tool selection creates a new identity control surface

AI agents are not just applications that call tools. They can discover tools, select them during execution, and chain them in ways that were not fixed at build time. That turns the tool layer into an identity control surface, because access is no longer only about whether a principal can authenticate. It is also about whether the agent should be allowed to invoke a new connector, a new MCP server, or a new action path in the middle of a session. Traditional entitlement models struggle here because they assume the permitted action set is known in advance.

Practical implication: enforce runtime approval gates for new tools and connectors before agents can expand their effective access.

Prompt injection is an operational condition, not a one-off flaw

Prompt injection matters because it lets hostile instructions ride inside content the agent is already processing. In agentic systems, that can redirect retrieval, alter tool choice, or trigger unsafe outputs without any separate compromise of the underlying platform. The problem is persistent because the agent’s behaviour is adaptive and instruction-following by design. Treating this as a patchable bug underestimates the architecture. It is better understood as an ongoing control problem where content, context, and execution are all part of the attack surface.

Practical implication: reduce attack surface with content handling limits, tool restrictions, and runtime monitoring of agent instruction paths.

Agent insiders require behaviour analytics, not just access reviews

The summit’s insider-threat framing is useful because agents can create risk from inside the environment even when they have legitimate access. That makes behaviour the key signal. Repeated destructive actions, unusual data access, and use of unapproved MCP servers are more informative than static entitlement lists. This is where standard user and entity behaviour analytics can be adapted, but the baseline must account for nondeterministic execution. An agent may be authorised and still become risky because its runtime decisions change with context.

Practical implication: build anomaly detection for AI agent behaviour and use it alongside identity governance, not instead of it.

NHI Mgmt Group analysis

AI agent identity is becoming a governance category, not just a deployment label. The article shows why runtime decision-making changes the identity problem. When an agent can select tools, alter its path, and act without a fixed script, conventional application identity assumptions stop being enough. Practitioners should treat agent identity as a governed runtime relationship, not a static account inventory.

Prompt injection should be managed as a standing operational reality. Zenity’s recap is right to frame the issue as persistent rather than occasional. The field has already moved past the point where simple filtering can be assumed sufficient, because agents are built to follow instructions and exploit whatever execution path appears valid. The implication is that security programmes must assume hostile instruction content will recur and design around that reality.

Hard approval boundaries are now part of the security architecture for agents. The article’s emphasis on explicit human approval for new tools and MCP servers points to a broader control truth. Once runtime expansion is possible, privilege is no longer only a provisioning issue, it is a session-boundary issue. Practitioners should recognise that the attack surface expands at the moment of tool discovery, not just at account creation.

AI agent behavior analytics is the right successor to human-centric anomaly detection. The insider-threat discussion shows that agent risk is best observed through actions, repetition, and access patterns. That does not replace IAM or PAM, but it does extend them into a runtime model where behaviour becomes the evidence of trust. Security teams should plan for detection that understands both identity and execution context.

Agentic identity needs a clearer governance model before scale makes the gap irreversible. The article’s question about what agentic identity actually is is the right one. Identity governance has long relied on stable subjects and predictable access lifecycles. That premise weakens when the subject is dynamic, tool-bearing, and context-sensitive. The practical conclusion is that teams need a defined agent identity model before they can govern at scale.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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.
• OWASP Agentic Applications Top 10 and the NIST AI Risk Management Framework both point practitioners toward runtime governance, not static trust assumptions.

What this signals

Agentic identity is moving from edge case to programme design requirement: the organisations that delay runtime controls will inherit a widening governance gap as tool discovery, instruction handling, and execution timing continue to blur together. The most practical next step is to define what an agent is allowed to do before it is allowed to learn new paths, then align that model with the OWASP Top 10 for Agentic Applications 2026.

The next phase of AI security operations will look less like model management and more like privileged identity governance for dynamic actors. That means teams will need clearer ownership, stronger runtime evidence, and better behavioural telemetry, especially where AI systems touch sensitive data and the NIST AI Risk Management Framework is being used as an operating reference.

With 80% of organisations already reporting agent actions beyond intended scope, the signal for practitioners is clear: agent governance is no longer an emerging policy topic, it is a control-plane issue. Teams should prepare for agent inventories, approval workflows, and monitoring models that work at the speed of runtime decisions.

For practitioners

• Define runtime approval boundaries for new tools Require explicit approval before an agent can connect to a new MCP server, API, or external data source. Make the approval step part of the runtime control plane, not a manual exception process after the fact.
• Instrument agent behaviour as a security signal Track unusual data access, repeated destructive actions, and tool use that deviates from expected patterns. Feed those events into risk scoring so governance teams can see when an agent is moving outside its intended operating envelope.
• Separate instruction handling from execution trust Limit how agents render, parse, and act on untrusted content so hostile instructions cannot freely influence downstream actions. Pair that with restrictive content processing and narrow permission scopes for high-risk workflows.
• Extend identity governance to agent lifecycles Create onboarding, review, and offboarding steps for agents just as you do for human and machine identities. Include ownership, approved tools, escalation paths, and decommission criteria in the same governance record.
• Review privileged access assumptions for autonomous behaviour Check whether existing privileged access controls assume that the subject remains stable long enough to review, certify, and revoke. If the answer is yes, redesign those controls for agents whose behaviour and access context can change during execution.

Key takeaways

• AI agents change the identity problem because runtime tool choice and execution timing can expand access after deployment, not just at provisioning.
• Zenity’s recap reinforces the scale of the issue: prompt injection, unapproved tools, and insider-like agent behaviour are already operational concerns.
• Practitioners should move to runtime approval, behaviour analytics, and explicit ownership before agent deployments widen the governance gap further.

Key terms

• Agentic Identity: The governed identity of an AI system that can choose actions, tools, and timing during execution. It is not just a login or service account. In practice, it combines identity, permissions, runtime context, and behavioural evidence into one control problem.
• Prompt Injection: A technique that places malicious instructions into content an AI agent processes so the agent follows attacker intent instead of the operator’s intent. The risk is not limited to chat prompts. It can affect retrieval, tool use, and downstream actions across the execution chain.
• Runtime Boundary: A control point that limits what an agent can do while it is running, including which tools it may call, which data it may reach, and which actions need approval. Runtime boundaries matter because agent behaviour can change after deployment.
• AI Agent Behavior Analytics: A monitoring approach that scores AI agents based on what they do, not only what they are allowed to do. It extends anomaly detection into agentic systems by watching for unapproved tools, unusual data access, and repeated risky actions.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: The League Assembled, reflections from the AI Agent Security Summit. Read the original.