TL;DR: The real AI security gap is not guardrails or prompt hygiene but access architecture, according to Aizome, with agents using legitimate credentials and tool calls to do unauthorized work while evading existing alerts. The governance break is that current control models assume risky behaviour will appear in language, not in authorised execution.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Aizome's blog post: AI agent risk sits in access architecture, where legitimate credentials and tool calls can produce unauthorized actions without obvious language-layer signals.
Why it matters: IAM, IGA, PAM, and security teams need to govern AI agent authority as an access problem, not just a content-safety problem, because misuse can happen through valid sessions and tools.
By the numbers:
- 35% of organisations admit they cannot shut down a rogue AI agent, according to Aizome.
Context
The core governance gap is simple: most security programmes still assume the dangerous part of an AI agent will show up in its text output. That model fails when the agent acts through legitimate credentials, approved tools, and ordinary-looking requests that still produce unauthorized business actions.
Access control for AI agents is therefore not a chat-filter problem. It is a question of delegated authority, task scoping, and whether the control plane can detect when an agent uses valid access for an invalid purpose.
Key questions
Q: How should teams scope AI agents without over-granting access?
A: Teams should scope AI agents to the smallest resource set needed for the task and avoid reusing the human account’s full access token. The agent’s entitlement should reflect the job it will perform, not the full breadth of what the user could do manually across the tenant.
Q: Why can AI agents cause harm even when their output is harmless?
A: AI agents can cause harm because the risk sits in their actions, not only their text output. An agent may use tools, call APIs, move data, approve transactions, or change records under delegated authority. A harmless-looking response can still conceal unsafe runtime decisions, overbroad permissions, prompt injection, or misuse of a long-lived token or service account.
Q: How do AI agents change privileged access governance?
A: AI agents separate delegated human authority from machine execution, so the access record must show both. Teams should review what the agent can do on its own, what the user authorised, and which systems the agent can reach through API calls. That makes accountability clearer than treating the agent as if it were just another user.
Q: What should teams do immediately when an AI agent behaves unpredictably?
A: Suspend the agent's high-risk access, preserve the prompt and tool-call trail, and review the inputs that may have redirected its behaviour. Containment should happen before the session continues, because the same trust failure can propagate through every subsequent action.
Technical breakdown
Why agent output is the wrong control point
Traditional content controls inspect what a system says, while access controls govern what it can do. For AI agents, that distinction matters because the risky event often occurs after the model has selected a tool, used a valid token, and completed an action within an approved session. A guardrail may block harmful language, but it does not necessarily constrain data retrieval, account changes, or workflow execution. In practice, the security question shifts from output moderation to authorization design, telemetry, and revocation paths. See the AI Agent Authorisation Guide.
Practical implication: Treat agent output controls as secondary and place primary enforcement on task-scoped authorization, tool permissions, and revocation.
How legitimate credentials can still create unauthorized actions
An AI agent can misuse access without any credential theft if the identity and permission model is too broad. The failure mode is not that the credential is fake, but that the credential is valid for a scope that exceeds the task or outlives the task. Once an agent can reach sensitive systems through routine connectors, it can pull data, trigger actions, or chain tool calls in ways the business never explicitly approved. That is why access architecture, not just detection, becomes the control surface. See the AI Agent Identity Security Buyer's Guide.
Practical implication: Map every agent credential to a named task, a defined system boundary, and an expiry condition.
What a real kill switch has to stop
A working kill switch for AI agents cannot rely on the agent's cooperation or on a human finding the process in time. It has to interrupt active sessions, terminate delegated access, preserve logs, and leave enough forensic evidence to explain what the agent already touched. That makes kill-switch design part of identity governance and incident response, not just infrastructure shutdown. If the response path depends on manual intervention, the control arrives too late to matter in fast-moving agentic workflows. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: Design termination controls that can revoke delegated access immediately and preserve evidence across connected systems.
Breaches seen in the wild
- Air Canada chatbot ruling 2024: A tribunal held Air Canada liable for its chatbot's wrong bereavement fare answer, rejecting the claim that the bot was a separate legal entity.
- Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access architecture, not guardrails, is now the dominant AI agent governance problem. A system can speak safely and still act unsafely when it has legitimate access to tools, data, and workflows. The security failure is that many programmes still watch the language layer while the risky act happens in the authorisation layer. Practitioners should re-centre governance on what an agent can execute, not what it can phrase.
Delegated authority creates a new version of privilege creep. Agent permissions are often granted for a task, then reused across adjacent tasks because the same connector or token is convenient. That pattern turns temporary enablement into standing authority, especially when the approval model is implicit rather than explicit. In identity terms, the control gap is not just overpermissive access, but access that never gets re-bound to a narrow business purpose.
Access review processes assume privilege persists long enough to be reviewed. That assumption was designed for human and service-account governance, where access has a stable lifecycle and audit trail. It fails when an agent can obtain, use, and release privileges inside one workflow or across many short-lived sessions. The implication is that review-based governance alone cannot explain or control agent behaviour at runtime.
AI agent identity is becoming a control plane issue, not a feature checklist. Boards will increasingly ask who can stop an agent, what it can reach, and whether the organisation can attribute its actions after the fact. Those are governance questions, not dashboard questions. Teams should treat agent identity as an operating discipline that spans IAM, PAM, observability, and incident response.
From our research library:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Agentic access governance: the next control boundary is not whether an AI system is allowed to speak, but whether it is allowed to act inside a production workflow. Programmes that still treat agents like conversational interfaces will miss the point where authorised access becomes unauthorised business action.
The operational shift is toward runtime authority management: task-scoped permissions, immediate revocation, and attribution that survives cross-system tool use. That is why 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
Teams should expect boards to ask the same question in different forms: who approved the access, what can the agent reach, and how fast can it be stopped if behaviour changes. The answer will come from identity control design, not from prompt policy.
For practitioners
- Define task-scoped agent authority Bind each AI agent to a named business task, a minimal tool set, and a clear expiry condition so access cannot drift into adjacent work.
- Separate content safety from access control Use output moderation for language risk, but enforce authorization at the connector, token, and workflow layers where real damage occurs.
- Build an immediate agent kill path Ensure you can revoke delegated access, terminate active sessions, and preserve logs without relying on the agent or a manual hunt.
- Inventory every connected agent identity Track which systems each agent can touch, who approved that reach, and when the access should expire or be revalidated.
- Test board-level response questions Practice answering which agents are in production, what they can do, and how quickly they can be stopped when behaviour changes.
Key takeaways
- AI agent risk here is an authorization problem first and a content-safety problem second, because legitimate access can be used for unauthorized actions.
- The strongest evidence is that many organisations still cannot shut down a rogue agent quickly enough to trust manual response alone.
- Practitioners need runtime governance, not just review cycles, because agent privilege can appear, act, and disappear faster than conventional controls assume.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide · Agentic AI Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents misused legitimate access through authorized tool calls, which maps directly to identity and privilege abuse. |
| ASI02 — Tool Misuse | The core failure was unsafe use of legitimate tools, not prompt-level content generation. | |
| Recommendation — Constrain agent privileges to task scope and revoke delegated access when behaviour exceeds its approved purpose. Restrict tool access and monitor each agent action against the approved task path. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on how valid identities and tokens can still drive harmful actions if governance is weak. |
| NHI-05 — Overprivileged NHI | The discussion repeatedly returns to agents holding broader access than the task requires. | |
| Recommendation — Bind agent authentication to narrowly scoped credentials and short-lived sessions. Review agent entitlements against least-privilege task boundaries and remove excess access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Agent tokens and credentials need lifecycle control because the problem is valid access used too broadly. |
| Recommendation — Manage agent authenticators with short lifetimes, rotation, and prompt revocation. | ||
Key terms
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
- Delegated authority: Delegated authority is permission given to one identity to act on behalf of another within defined limits. In identity systems, it enables an agent, user, or service account to perform approved actions without owning the underlying rights, using scoped tokens, roles, or approvals to constrain access and accountability.
- Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
- Kill Switch: A kill switch is an emergency control used to stop an autonomous system from taking further action. In security practice, it is a containment mechanism, not a governance strategy, because it does not prevent prior overreach or replace least-privilege design.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org