Agents need boundaries as agentic AI security becomes a category

At a glance

What this is: This analysis says agentic AI security is now a distinct category, and that guardrails alone cannot control agents acting across enterprise systems.

Why it matters: It matters because IAM teams now have to govern delegated machine action, not just authentication, and that changes how NHI, autonomous workflows, and human oversight must be designed.

By the numbers:

• Gartner publishes over 130 Hype Cycles a year, and the inaugural Hype Cycle for Agentic AI arrived in April ahead of the usual June to August window.

👉 Read Zenity's analysis of agentic AI security boundaries and governance

Context

Agentic AI security is the governance problem created when software can perceive, decide, and act across business systems on behalf of a user. This post argues that the market is now treating that problem as its own category, and the primary keyword here is agentic AI security.

The gap is not model safety in the abstract. It is delegated action at runtime, where an agent connected to CRM, email, Slack, or external APIs can carry out a sequence of actions that no one explicitly authorised. For IAM teams, that means identity, privilege, and enforcement must be evaluated at the point of action, not only at login or provisioning.

The article’s starting position is typical of the current market shift: enterprises already understand the risk conceptually, but the control stack still lags behind the operating model. That makes the discussion relevant across NHI governance, autonomous systems oversight, and human approval paths that now delegate into machines.

Key questions

Q: How should security teams govern AI agents that can act across multiple enterprise systems?

A: Security teams should govern them as delegated identities with runtime authorisation, not as chat interfaces with safety filters. The control point must evaluate who the agent is acting for, what data it can touch, where the output goes, and whether the action is permitted before the tool executes. That is identity governance applied to machine action, not model moderation.

Q: Why do guardrails fail to secure agentic AI workflows?

A: Guardrails fail because they are probabilistic and operate on model output, while the risk lives in the execution chain. An agent can still turn a harmless-looking prompt into a harmful sequence of tool calls, data updates, or external actions. Security teams need deterministic boundaries around action, not just content screening after the model has already decided.

Q: What breaks when AI agents are reviewed like human users?

A: Human review assumes access is stable long enough to be observed, approved, and recertified. Agentic workflows often complete within one session and can change scope mid-execution, so the review cycle arrives too late to matter. The result is a governance gap where the action has already happened before anyone can certify it.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

Why guardrails fail for agentic AI security

Guardrails are probabilistic content filters, not hard enforcement points. They can flag or block some unsafe outputs, but they still depend on the model recognising bad intent correctly. In this article’s framing, that is too weak for agents because the failure happens when a model turns a request into action across tools and data sources. A compromised prompt does not need to defeat the whole system if the agent can still execute a harmful workflow after the guardrail misses it. The security problem is therefore not just content moderation. It is runtime enforcement around delegated action, context, and tool use.

Practical implication: teams should treat guardrails as a supplementary control, not the control boundary for agentic systems.

Enforced boundaries and context-aware policy engines

The article argues for deterministic boundaries that operate outside the agent’s reasoning loop. That means policy must decide whether an action is allowed before execution, using context such as actor identity, target system, data type, destination, and intent signals. This is closer to identity-aware runtime authorisation than to traditional prompt filtering. The interesting technical point is that a blunt deny rule is not enough either, because without context the system may block legitimate workflows. The real architecture problem is fine-grained enforcement that understands enough about the session to separate normal delegation from manipulated behaviour.

Practical implication: define enforcement points that can inspect identity, data, and destination before tool execution.

Why DFIR-grade traceability becomes mandatory for agents

A conventional security stack often fragments an agentic workflow into separate events. One tool sees a CRM update, another sees a Slack message, and a third sees an API call. What is lost is the sequence, the delegated identity, and the reasoning chain behind the actions. Without session reconstruction, teams cannot tell whether the workflow was legitimate, manipulated, or partially hijacked. That is why the article’s DFIR comparison matters: agent incidents need evidence quality, replay, and attribution detail comparable to endpoint compromise investigations. Otherwise, detection may exist without explainability, and response will still be guesswork.

Practical implication: require session-level logs and reconstructible evidence chains for every high-risk agent workflow.

Threat narrative

Attacker objective: The objective is to coerce a legitimate agent workflow into making unauthorised business changes across connected enterprise systems without immediate detection.

1. entry: A user asks a routine question and the connected agent receives legitimate access to CRM data and related tools as part of the workflow.
2. credential_harvested: An attacker-planted record or crafted input manipulates the agent into following an unsafe instruction path without bypassing authentication.
3. escalation: The agent executes a harmful sequence across systems, including updating customer records and invoking external actions at machine speed.
4. impact: The workflow silently changes business data across the database, leaving the user unaware until after the damage is done.

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

Agentic AI security is no longer a model-safety issue, it is an identity and authorisation issue. The article correctly shifts the centre of gravity from hallucinations and prompt injection to delegated runtime action. Once an agent can touch CRM, email, Slack, and external APIs, the control problem becomes who or what is allowed to act, on which data, under which context. Practitioners should stop treating agent safety as a separate AI topic and place it inside identity governance.

Guardrails are the wrong boundary for systems that can act across tools. A statistical filter can reduce some bad outputs, but it cannot replace deterministic enforcement around identity, scope, and destination. The market keeps calling these controls guardrails, but the underlying requirement is policy-enforced action boundaries that sit outside the model’s own reasoning. Practitioners should read that as a design failure, not a tuning problem.

Runtime context is the missing control plane for agentic behaviour. The article’s strongest technical point is that the same action can be legitimate or malicious depending on actor, data, destination, and intent. That is why static policy and log review are insufficient. Contextual action boundary: a named control concept for the policy layer that decides whether an agent may act in the current session. Teams should treat this as the operational definition of agent governance.

Human-paced oversight does not scale to machine-paced delegation. The article is right that thousands of agents cannot be governed by manual review loops. That is an organisational assumption collapse as much as a tooling gap, because the review model presumes humans can observe, approve, and reconstruct each meaningful action. Practitioners should redesign governance for automated decision cadence rather than trying to preserve a human approval fiction.

DFIR-grade traceability is becoming a baseline requirement for agentic incidents. If a security team cannot reconstruct what the agent saw, reasoned, and executed, it cannot reliably investigate manipulated automation. That pushes agent governance toward evidence integrity, session replay, and attribution quality, not just prevention. Practitioners should assume incident response for agents will be judged by reconstructibility, not by alert volume.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• Read the OWASP Agentic Applications Top 10 for the control patterns that should shape policy boundaries and runtime enforcement.

What this signals

Agentic AI governance is moving from experimentation to operational control. With 98% of companies planning to deploy more AI agents in the next 12 months, the governance gap will widen unless identity, authorisation, and evidence collection are designed into the workflow itself. Teams should expect policy engineering to sit alongside prompt engineering as a core discipline, especially for systems that can modify records or call external APIs.

Context-aware enforcement will become the dividing line between safe automation and unsafe delegation. The market is converging on the idea that simply adding a guardrail does not create a boundary. Practitioners should watch for policy engines that can evaluate actor, data, and destination in real time, and they should align that work with the NIST AI Risk Management Framework where AI governance and operational accountability intersect.

Session replay is becoming a governance requirement, not an investigation luxury. The need to reconstruct what an agent reasoned, saw, and executed is now central to incident response. That is where the OWASP Top 10 for Agentic Applications 2026 becomes useful, because it maps the kinds of runtime abuse that create evidence gaps and control failures.

For practitioners

• Define runtime boundaries for agent actions Map every high-risk agent workflow to a pre-execution policy decision that evaluates identity, target system, data sensitivity, and destination before any tool call is allowed.
• Separate delegated action from model output Stop relying on prompt filtering as the control layer. Use enforcement points that can block, step up, or constrain tool execution even when the model produces a plausible response.
• Instrument session-level evidence chains Log reasoning traces, tool invocations, data touched, and resulting actions in a way that supports reconstruction after an incident, not just alerting in real time.
• Rework approvals for machine-speed workflows Replace human approval assumptions with policy-driven delegation rules for repetitive agent tasks, especially where the same workflow can span multiple systems in one session.

Key takeaways

• Agentic AI security is an identity governance problem because delegated software can now act across business systems without human pacing.
• Zenity’s examples show that guardrails alone do not stop manipulated agent workflows, and the control gap becomes visible when actions span multiple tools in one session.
• Practitioners need deterministic boundaries, runtime context, and reconstructible evidence if they want agent governance to survive real operational scale.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of controlling software that can decide and act across tools and data on behalf of a user. The governance challenge is not only model output quality, but delegated execution, runtime scope, evidence collection, and accountability for actions taken at machine speed.
• Enforced Boundary: An enforced boundary is a deterministic control that blocks or constrains an agent before an action executes. Unlike a guardrail, it does not depend on the model correctly self-identifying unsafe behaviour, and it must use context such as identity, data sensitivity, destination, and task purpose.
• Session Reconstruction: Session reconstruction is the ability to replay what an agent saw, reasoned about, and executed during a workflow. In agent governance, it is essential for incident response because alert counts alone cannot explain whether a sequence was legitimate, manipulated, or partially compromised.
• Delegated Identity: Delegated identity is the identity context under which an agent acts for a user, service, or workflow. It determines what the agent is allowed to access and what actions it can perform, making it a core control object for authorisation, monitoring, and accountability.

Deepen your knowledge

Agentic AI security and runtime boundary design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for delegated machine action, it is worth exploring.

This post draws on content published by Zenity: Agents Need Boundaries. The Market Is Starting to Agree. Read the original.