AI guardrails expose the limits of traditional IAM for agents

At a glance

What this is: This article argues that AI guardrails are now an identity and access control problem, not just an AI safety problem, because excessive agent privilege and runtime data movement create visibility gaps.

Why it matters: IAM, IGA, PAM, and NHI teams need to treat AI agents as governed identities because the same access, audit, and least-privilege failures that affect NHIs now show up in agentic workflows.

By the numbers:

• Research across enterprise customers shows AI agents move 16x more data than human users.
• 90% of those agents hold excessive privileges, creating a visibility gap that grows wider with every new deployment.

👉 Read Obsidian Security's analysis of AI guardrails for enterprise AI systems

Context

AI guardrails are policy and runtime controls that constrain what AI systems can see, decide, and do. The identity governance problem is that enterprise AI now behaves like a privileged non-human actor, but most access models still assume fixed roles, predictable workflows, and human-paced review cycles. This article is about AI guardrails, but the underlying issue is AI agent identity and access control.

Traditional security controls were built for deterministic systems, where authority is granted, used, and reviewed in a stable way. AI agents break that assumption because they can chain prompts, tools, and data access at runtime, which turns access scope into a moving target for IAM, PAM, and NHI governance.

The article's starting point is typical for current enterprise AI programmes: adoption is moving faster than control design. That makes it a useful lens for what happens when AI is added to identity environments that were never designed to govern non-human decision-making at production speed.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents complicate least-privilege access models?

A: Because agents often use shared or long-lived NHIs, move quickly, and cross platform boundaries that human-centric review processes do not cover well. Least privilege still applies, but it has to be enforced at the identity, resource, and execution layers together. Otherwise the agent keeps more reach than the task requires.

Q: What breaks when AI guardrails are only tested before deployment?

A: Static testing misses production drift, new jailbreak variants, and data leakage patterns that appear only under real traffic. When controls are never validated live, false confidence grows while the model learns from contexts the test set never covered. Continuous monitoring closes that gap by turning live incidents into new test cases.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why runtime policy matters more than static AI settings

AI guardrails work only if they evaluate behaviour at runtime, not just declared configuration. A model or agent may be provisioned with a narrow policy, but the real risk comes from what it can actually access after prompts, tool calls, retrieval, and delegated actions are combined in-session. This is where identity, authorization, and monitoring converge. Static allowlists and one-time configuration checks cannot see prompt injection, scope drift, or token abuse once the session is live. The result is a gap between theoretical permissions and effective authority.

Practical implication: instrument runtime access decisions and compare them to intended policy, not just to provisioning records.

How identity-first authorization changes AI guardrails

The article frames authentication as only the first layer. Authorization is the harder problem because AI agents often act across multiple systems using API tokens, SSO grants, and delegated service credentials. Role-based access is usually too rigid, while attribute- and policy-based controls can adapt to context, task, and data sensitivity. That matters because an agent's risk is defined by reachable systems, reachable data, and the combinations that emerge when privileges are reused across workflows. In NHI terms, this is effective authority, not theoretical entitlement.

Practical implication: map AI agents to least-privilege policies by task and data scope, then verify effective authority continuously.

Why agent-to-agent communication creates a new control surface

The article treats unauthorized agent-to-agent communication as a distinct risk because one agent can influence another without human review. That creates a machine insider pattern: compromised or misdirected agents can propagate data, decisions, or tool actions across an estate faster than traditional user analytics expects. Conventional detection was built around human behaviour and does not naturally interpret autonomous exchanges between non-human identities. Once agents begin delegating work to other agents, the trust boundary shifts from a single identity to a chain of identities and permissions.

Practical implication: define explicit trust boundaries for agent-to-agent calls and log delegation paths as first-class identity events.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI workflow into a privileged access path for data exposure, lateral movement, or unauthorized business actions.

1. Entry occurs when an attacker manipulates prompts, compromised tokens, or exposed AI access paths to reach an agent or model-connected workflow.
2. Escalation follows when the agent's effective authority exceeds its intended scope, allowing access to connected systems, sensitive data, or downstream tools.
3. Impact arrives when the compromised or misdirected agent leaks data, executes unauthorized actions, or propagates failures across other agents and SaaS environments.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI guardrails are really identity guardrails for non-human decision-makers. Once an agent can select tools, move data, and act across systems, the security question becomes who or what is authorised to do those things at runtime. That shifts the centre of gravity from model safety alone to identity, privilege, and observability. Practitioners should treat AI guardrails as part of the identity control plane, not as a separate AI feature set.

Effective authority is the named concept this market still underestimates. The article correctly distinguishes what an agent is configured to access from what it can actually reach in production. That gap is where risk lives, because token reuse, delegated access, and chained workflows create privilege combinations that provisioning records do not describe. Identity teams should measure effective authority, not just assigned access.

Traditional access review logic is too slow for AI operations. Human-centric governance assumes access persists long enough to be reviewed, recertified, and revoked on a schedule. AI agents can create, consume, and propagate access inside the same operational window, which makes periodic review necessary but insufficient. The implication is that IAM and IGA programmes need runtime evidence, not just governance cadence.

Agent-to-agent trust is the next boundary failure. The article's discussion of unauthorized agent-to-agent communication points to a broader problem: trust chains are becoming recursive. A single agent can become both actor and broker, which means policy must govern delegation paths as carefully as direct access. Security teams should expect the next wave of NHI governance failures to emerge in these chained interactions.

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.
• Only 52% of companies can track and audit the data their AI agents access, which means nearly half operate with a compliance and investigation blind spot.
• For a broader control framework, use OWASP NHI Top 10 to map AI agent abuse scenarios to runtime identity risk.

What this signals

Effective authority will become the deciding metric for AI governance programmes because assigned permissions no longer explain runtime behaviour. Teams should expect board questions about what agents can really reach, not just what their policies say they can reach.

The practical next step is to fold AI agents into the same control disciplines used for other NHIs: identity inventory, privilege review, revocation, and audit. Where those controls stop at configuration management, the programme will still be blind to agent behaviour in production.

For practitioners

• Map effective authority for every AI agent Inventory the systems, data sets, and APIs each agent can actually reach during live sessions, then compare that to its intended task scope. Prioritise agents with broad SaaS reach, shared tokens, or delegated permissions that were never reviewed as NHI access.
• Enforce runtime policy checks on agent actions Require approval, filtering, or denial at the point of tool use, retrieval, and data export rather than relying only on pre-deployment configuration. Tie each control decision to identity context, sensitivity, and business purpose.
• Separate human, application, and agent privileges Avoid reusing the same credentials or broad OAuth grants across users, services, and AI workflows. Distinct identities make it possible to revoke, audit, and contain agent behaviour without disrupting unrelated human access.
• Log delegation paths and agent-to-agent calls Treat every chained action between agents as an auditable identity event, including the initiating identity, the target service, the retrieved data, and the downstream action. This is essential for incident reconstruction and compliance evidence.

Key takeaways

• AI guardrails matter because the risk is identity and privilege abuse at runtime, not just unsafe model output.
• The scale problem is already visible: agents are moving more data than humans and are frequently over-privileged.
• Practitioners should govern effective authority, delegation, and auditability before agent sprawl outruns existing IAM and NHI controls.

Key terms

• Prompt Guardrails: Prompt guardrails are policy controls that limit what prompts can request, transmit, or trigger before the model responds. They are most effective when enforced centrally because application-level implementations drift over time and often fail to stay consistent across many services and teams.
• Effective Authority: Effective authority is the control an identity can actually exercise after all inheritance, delegation, and cross-system relationships are applied. It can be broader than the permissions listed in a single console, which is why local reviews often understate risk. Security teams need to measure effective authority, not only assigned access.
• Agent-to-agent trust: The rules that determine whether one AI agent can authenticate, delegate, or share context with another. This is an identity problem as much as an integration problem, because uncontrolled trust propagation can create hidden access paths and make accountability harder to prove.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Specific examples of input validation, output filtering, and audit logging patterns for AI guardrails
• Identity provider integration guidance for SAML, OIDC, and token lifecycle management
• Policy-as-code configuration examples that show how runtime guardrails are structured in practice
• Compliance mapping details for ISO 42001, NIST AI RMF, MITRE ATLAS, and the EU AI Act

👉 The full Obsidian Security post covers implementation patterns, compliance mapping, and runtime guardrail examples.

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 building or maturing an identity security programme, it is worth exploring.