TL;DR: AI agent security tools are largely built to observe behavior after the fact, while the real breach condition is a toxic combination of overbroad permissions and exposure to unauthorized invokers, according to Obsidian Security. The architectural gap is that detection without runtime enforcement cannot stop legitimate but dangerous execution before damage occurs.
At a glance
What this is: This is an analysis of why AI agent security tools miss the critical condition at runtime: agents become dangerous when excessive permissions meet an unauthorised invoker.
Why it matters: It matters because IAM and security teams need controls that evaluate both entitlement scope and invocation context before an agent action completes, not after the event is already logged.
Context
AI agent security fails when governance assumes agent risk can be understood from behaviour alone. The article argues that the actual break point is a toxic combination: an agent with more permissions than its workflow needs and reachable by someone who should not have access to the data it can touch.
In identity terms, this is a runtime enforcement problem across non-human identities, not a post-event alerting problem. The control failure is that current tools inspect actions after they happen, while the risky condition already exists at invocation time.
That makes the article relevant to AI agent governance, service account scope, and access control design. The starting point is atypical in one respect: it frames the failure as architectural, not as a single misconfiguration or one vendor's blind spot.
Key questions
Q: What breaks when AI agent security tools only monitor behavior?
A: Behavior-only tools miss the moment when an agent becomes dangerous through valid credentials and excessive reach. By the time the action looks suspicious, the agent may already have acted inside a trusted application. The control gap is not visibility alone. It is the absence of runtime enforcement tied to entitlement scope and invoker authority.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.
Q: How do you know if an AI agent is overexposed?
A: An AI agent is overexposed when it can reach resources that are not strictly necessary for its job, especially secrets, execution tools, and internal data stores. A good test is simple: remove a permission and see whether the use case still works. If not, the permission may be justified; if yes, it is likely excess reach.
Q: What should teams do when sensitive data moves through service accounts or automation?
A: Apply the same governance discipline used for human access, but make the audit and enforcement logic identity-aware. Service accounts and automated workflows should have explicit data paths, narrow scope, and reviewable exceptions, because they can move data without the behavioural cues that human users produce.
Technical breakdown
Why toxic combinations matter at execution time
A toxic combination exists when two conditions align at once: an agent has permissions beyond what the workflow requires, and an unauthorised invoker can reach it. That is different from a conventional alerting problem because the harm is created by the access state itself, not by obviously malicious behaviour. The article's core claim is that if the agent can act legitimately, behavioural monitoring may never flag the risk before damage occurs. The operational issue is not whether the agent looks suspicious, but whether it is allowed to do dangerous things for the wrong requester.
Practical implication: evaluate entitlement scope and invocation paths together, because either condition alone can hide the breach condition.
Why identity stacks miss agent risk
The article shows how agent access can bypass traditional identity controls. Agents often authenticate with OAuth tokens tied to service accounts, not through a human SSO flow, which means the IdP may never see session context, MFA, or a user identity to review. That leaves service account credentials outside normal human review cycles and creates a blind spot for access governance. The practical failure is attribution loss: the system can show that something accessed data, but not whether a human or agent triggered it, or on whose behalf.
Practical implication: map agent credentials to the downstream SaaS and cloud systems they actually reach, not only to the central IdP.
Why agent-specific tools still stop short
Agent security tools that focus on inventory, prompt monitoring, or suspicious tool calls still assume the main problem is what the agent does. The article argues the risk often lives one layer lower, inside the connected enterprise application where the service account can reach real records and actions. Without inspecting those application entitlements, a tool cannot determine whether a toxic combination exists, much less block it at the moment of execution. That is why visibility at the boundary is insufficient when the harmful action happens inside third-party systems.
Practical implication: treat connected application entitlements as the enforcement surface, not the agent console alone.
Threat narrative
Attacker objective: The objective is to make a legitimate agent perform an authorised-looking but dangerous action against data or systems the invoker should not reach.
- Entry occurs when an agent is invoked through a legitimate OAuth-backed path or a reachable third-party application connection.
- Credential access is already present because the agent runs under persistent service account credentials with broad entitlements.
- Escalation happens when an unauthorised invoker reaches the agent and can cause it to use those entitlements against data it should not expose.
- Impact follows when the agent completes the action inside the enterprise application before any post-event detection can intervene.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- 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
Runtime enforcement is the missing identity control for AI agents: the market has over-invested in post-event observation and under-invested in execution-time decision control. When an agent can act through valid credentials, the critical question is not whether the behaviour looks unusual after the fact. The question is whether the action should have been permitted at the moment of invocation. Practitioners need to treat execution as the control point, not the audit trail.
Toxic combination is a stronger governance concept than simple overprivilege: the article's framework is useful because it ties entitlement scope to invoker reachability. An agent with broad access is not automatically a breach condition, and an accessible agent is not automatically a breach condition. The failure is their overlap, which means governance has to consider both sides of the interaction as one policy problem.
IdP-centric governance leaves agents partially invisible: agent access often sits outside the session logic, MFA patterns, and review cadences designed for human users. That is not just a tooling gap, it is a category error in how identity control is applied. The implication is that machine access governed like human access will miss the part of the lifecycle where risk is created.
Application entitlement visibility is the real control plane: the dangerous act happens inside the connected SaaS or cloud application, where service account permissions determine what can be read, changed, or exfiltrated. If practitioners cannot see those entitlements in context, they cannot evaluate agent risk with any confidence. The control problem shifts from monitoring agent behaviour to governing the application rights the agent can exercise.
Agent governance now needs a named runtime concept: toxic combination capture. That is the point at which entitlement scope, invoker access, and execution timing meet inside one control decision. Practitioners should treat this as a distinct governance layer for AI agents, because without it, traditional security stacks may report activity while failing to stop the action that creates the loss.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 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
Toxic combination capture: this article names the gap practitioners need to govern explicitly. An agent can be perfectly legitimate in isolation and still unsafe when broad entitlements meet unauthorised invocation. The programme question is no longer whether the agent is observed, but whether execution can be stopped before the action completes.
Traditional access review cycles assume a stable identity and a reviewable session boundary. Agentic access breaks that assumption when service account credentials persist outside normal human review patterns and the risky state only exists at the moment of invocation. The 17% incident rate vs 76% for over-privileged systems shows why scoping AI access properly changes outcomes, according to the 2026 Infrastructure Identity Survey.
For identity programmes, the next step is to move governance closer to the application layer where agents actually operate. That means mapping invokers, entitlements, and data reach in one control view, then deciding where runtime blocking belongs in the chain.
For practitioners
- Map agent entitlement scope inside connected applications Inventory what each agent's service account can actually reach in Salesforce, ServiceNow, Workday, Slack, and similar systems, not just what the agent is configured to do.
- Tie invocation rights to data sensitivity Identify which users, workflows, or systems can invoke each agent and compare that reach to the sensitivity of the records and actions available to the agent.
- Separate detection from enforcement Require a control that can block execution before an agent action completes, because alerting after the action is logged does not stop the harmful state change.
- Review service account persistence Find agents operating under credentials that were issued once and now persist outside normal session boundaries or review cycles.
Key takeaways
- AI agent risk is not defined by behaviour alone, but by whether excessive entitlements and unauthorised invocation intersect at runtime.
- The article argues that current identity and network controls can miss the harmful action because the agent acts through legitimate credentials inside connected applications.
- Practitioners need application-level entitlement visibility and execution-time blocking to reduce the blast radius of agentic access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on agent access inside third-party applications and service accounts. |
| NHI-05 — Overprivileged NHI | The core risk is agents holding more permissions than their workflow requires. | |
| NHI-04 — Insecure Authentication | Agents authenticate through OAuth-backed service accounts outside human session controls. | |
| Recommendation — Map third-party agent credentials and revoke or constrain any integration that can reach sensitive data. Reduce agent entitlements to the smallest application and record scope that the workflow actually needs. Inspect how each agent authenticates and remove trust in authentication paths that lack reviewable session context. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The toxic combination is an agent privilege problem amplified by who can invoke it. |
| Recommendation — Constrain agent identity and privilege so invocation rights cannot turn valid access into harmful execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about access scope and who can exercise it at runtime. |
| Recommendation — Continuously validate agent entitlements against their actual business function and revoke excess authorization. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The abuse path depends on credentials and movement through connected enterprise systems. |
| Recommendation — Map agent credential abuse to credential access and lateral movement detection across SaaS integrations. | ||
Key terms
- Toxic Risk Combinations: Toxic risk combinations are unsafe interactions between datasets, access permissions, and AI workflows that only become problematic when combined. Individually they may appear harmless, but together they can expose sensitive information, enable re-identification, or create unintended inferences that traditional controls may miss.
- Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
- Agent Entitlement: An agent entitlement is the specific permission set assigned to an AI agent or its service principal. It should be narrower than the human’s browser access because the agent can execute tasks instantly, call multiple tools, and create a larger blast radius if privileges are not separated.
- Invocation rights: Permissions that allow an identity to call a deployed model, run inference, or trigger related AI actions. These rights are privileged because they can expose sensitive inputs, generate cost, or influence downstream business decisions.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org