TL;DR: AI is compressing code review, deployment, and agent tool use into microseconds, exposing a mismatch between human-paced security controls and machine-speed operations, according to WorkOS’s panel discussion from Enterprise Ready Conference 2025. The result is a governance problem as much as a technical one: identity, authorization, and audit patterns must be rethought for AI-enabled execution.
At a glance
What this is: This panel discussion says AI is compressing security-relevant actions into microseconds and forcing identity controls to operate at machine speed.
Why it matters: IAM, PAM, and NHI teams need to rethink approval, audit, and segregation-of-duty models when the actor can generate and execute actions faster than human review cycles.
Context
AI security becomes a governance problem when execution speed outpaces the controls built for human-paced change. In this discussion, the article frames the core issue as a mismatch between autonomous tool use and identity controls that assume a person will review, approve, or intervene before impact.
For identity and access teams, the practical question is not whether AI changes the need for authentication, authorization, and audit. It is whether those controls still function when an actor can chain actions, call tools, and move from request to execution in microseconds.
The article also shows a second-order shift: security teams are now using AI to secure AI, which means the boundary between the protected system and the protection layer is becoming more coupled rather than less.
Key questions
Q: What breaks when AI agents can make code changes faster than humans can review them?
A: Manual review stops being a meaningful control if it cannot keep pace with change volume. Teams then miss unsafe dependencies, unintended privilege use, and subtle architecture drift. The failure is not only in code quality, but in the programme’s ability to detect and contain agent-driven mistakes before they reach production.
Q: Why do AI agents change identity and authorization risk more than simple automation does?
A: Because the risk is not only volume, but runtime decision-making. A scripted workflow follows a predefined path, while an AI agent can choose among tools and timing at runtime, which means the control problem shifts from static access scope to dynamic action sequencing. That makes least privilege harder to define and easier to exceed in practice.
Q: How should security teams govern employee AI use without blocking productivity?
A: Start with visibility into sanctioned and shadow AI use, then apply runtime policies that inspect intent and context rather than only keywords. The goal is to allow legitimate work while preventing sensitive data from leaving controlled boundaries. Teams usually need ownership, approved models, and enforceable logging before they can scale access safely.
Q: What does machine-speed AI mean for audit, accountability, and control design?
A: It means audit is still necessary, but not sufficient. Accountability has to be designed into the identity path before execution starts, because post-event logs cannot stop an action that already completed in microseconds. The control model should answer who allowed the action, what context was present, and which next steps were possible from that state.
Technical breakdown
Machine-speed execution breaks human review windows
The panel’s core technical point is that AI can compress code generation, review, and deployment into a single runtime sequence. Traditional change control assumes discrete human steps with time between them for review, challenge, and rollback. When the actor is an AI system, those steps can collapse into one execution path, making approval gates either too slow to be usable or too shallow to matter. That creates a controls problem, not just an automation problem: the architecture of trust has to assume actions may be initiated, combined, and completed before a person can observe them.
Practical implication: Design controls around issuance and constrained execution, not around after-the-fact human review.
Contextual tool access is a new identity control pattern
The discussion around MCP showed that AI systems do not just authenticate once and then act like static software. They can be granted tool access that changes based on prior actions, context, or task state. That is closer to dynamic authorization than classic RBAC, because the same actor may need different capabilities at different points in the same workflow. The security problem is not simply granting access, but preventing tool chains that create unsafe cross-action paths. That is why the article draws on segregation-of-duty logic: one step should not unlock the next step automatically when the combined path becomes high risk.
Practical implication: Treat AI toolchains as stateful authorization paths and restrict which tool combinations can occur in sequence.
Verification shifts from single-pass trust to model consensus
The panel describes a pattern where multiple AI models are used to verify each other’s output, instead of trusting one pass of analysis. Technically, that reflects a recognition that AI output is probabilistic and context-sensitive, so confidence comes from repeated evaluation rather than a single authoritative decision. The article also notes the limits of formal verification when policy language is ambiguous or still being standardized. That matters for identity because the policy itself may not yet be expressible with enough precision to prove every permitted action mathematically. In practice, the control challenge is to make guardrails specific enough to be machine-enforced without pretending ambiguity has been eliminated.
Practical implication: Use layered verification and narrow policy language before expecting AI systems to behave predictably under security controls.
Threat narrative
Attacker objective: The objective is to weaponize machine-speed execution so that a legitimate AI workflow can cause broader unauthorized action before human controls can stop it.
- Entry occurs when an AI-enabled workflow or agent gains legitimate access to tools, code, or data that can be used at runtime.
- Escalation happens when that actor can chain actions faster than a human can review them, turning allowed tool use into broader operational reach.
- Impact follows when unexpected tool calls, prompt injection, or agent-to-agent propagation spreads actions across systems before oversight can intervene.
Breaches seen in the wild
- Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Human-paced identity governance is no longer a safe design assumption. The panel’s most important implication is not that AI introduces new tools, but that it breaks the old assumption that access persists long enough for a human to review it. Access review, approval workflows, and change management were built for observable, interruptible activity. Once execution happens in microseconds, those controls can still exist, but they no longer govern the moment that matters. The practitioner conclusion is that governance has to move upstream to issuance and path constraint.
AI tool access creates a machine-speed segregation-of-duty problem. The discussion around MCP and contextual tool access shows that the real control issue is not whether an AI can authenticate, but whether it can move from one permitted action to the next without crossing an unsafe boundary. That is an identity problem because the authorization state changes with each step in the sequence. The practitioner conclusion is that tool chaining, not just privilege level, now defines the blast radius.
Authentication, authorization, and audit remain the core primitives, but their operating model changes under AI. The panel repeatedly returned to the same fundamentals because they still apply, yet their implementation must reflect autonomous runtime behavior. Audit trails that are only useful after the fact will not constrain a tool chain that has already completed. The practitioner conclusion is that identity governance must be expressed as runtime policy, not just retrospective evidence.
AI-to-AI security creates recursive control dependencies across the stack. The article shows that organisations are using AI to secure AI, which means the detection layer and the protected layer are increasingly coupled. That matters because it weakens the old separation between control plane and workload plane in security operations. The practitioner conclusion is that governance must account for recursive trust, where one model validates another and neither can be treated as a final source of truth.
Least privilege is being redefined by sequencing, not just scope. The most useful named concept here is machine-speed authorization drift: an actor can remain within nominal permissions while still creating an unsafe end-to-end path. The panel’s discussion of contextual tool restrictions makes clear that privilege is no longer only about what the actor can access, but what it can cause next. The practitioner conclusion is that identity teams need to model action sequences, not just entitlements.
What this signals
Machine-speed identity control: Security teams should treat AI execution paths as identity events, not just application activity. When an agent can call tools, generate code, and trigger deployment in the same flow, the useful control point moves to authorization design and context-bound tool access rather than human review.
The panel points to a broader governance shift: security teams are now expected to secure AI with AI, which increases the need for precise guardrails, auditable action chains, and constrained delegation. That combination matters across NHI, PAM, and IAM programmes because the same trust assumptions fail once the actor can choose actions at runtime.
For practitioners
- Map machine-speed workflows to runtime authorization boundaries Identify where AI systems can generate, review, and deploy within the same task chain, then move controls to the point where the tool or action is first granted rather than after execution has started.
- Constrain AI tool chaining by context Define which tools an agent may reach after each prior step so a permitted action cannot automatically unlock a higher-risk one in the same session.
- Separate review from execution authority Make sure code review, deployment approval, and production action are not all available to the same agent path, even if the workflow is highly automated.
- Instrument AI actions with auditable identity context Log the agent, tool, input, and downstream action as one chain so security teams can reconstruct what happened when a model’s output becomes an operational change.
- Test whether your guardrails survive microsecond execution Run tabletop and simulation exercises that assume a task can complete before a human can intervene, then identify which controls still work under that condition.
Key takeaways
- AI changes the security problem by compressing action, review, and deployment into one machine-speed sequence that human controls cannot reliably interrupt.
- Authentication, authorization, and audit still matter, but they must be expressed as runtime boundaries and contextual tool constraints rather than retrospective checks.
- Security teams should focus on action sequencing, delegation scope, and tool-chain limits when governing AI-enabled execution.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centers on agents calling tools and needing contextual restrictions on what they can do next. |
| ASI03 — Identity & Privilege Abuse | The panel’s core risk is that autonomous actors can outpace human authorization and use granted identity in harmful ways. | |
| ASI07 — Insecure Inter-Agent Communication | The article’s agentic worm discussion depends on unsafe agent-to-agent propagation paths. | |
| Recommendation — Restrict agent tool paths so one permitted action cannot unlock unsafe downstream capabilities. Treat each agent identity as a bounded privilege domain with explicit runtime limits. Constrain inter-agent messages and validate every delegated instruction before execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article stresses that authentication remains necessary but must support machine-speed execution contexts. |
| NHI-05 — Overprivileged NHI | Machine-speed workflows become dangerous when agents can accumulate more privilege than each step requires. | |
| Recommendation — Bind authentication to the exact tool context and execution path the agent is allowed to use. Minimise each agent’s effective privilege at the action level, not just the account level. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | AI agents and toolchains authenticating to systems fit the service identity model in this article. |
| Recommendation — Apply service-authentication controls to every agent and tool interaction in the workflow. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article discusses agent chains and tool misuse that can expand access across systems. |
| Recommendation — Map agent tool chains to credential-access and lateral-movement detection coverage. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification — Continuous Verification | The article’s premise is that trust must be re-evaluated as the AI session progresses. |
| Recommendation — Enforce continuous verification for each tool call instead of relying on one-time approval. | ||
Key terms
- Machine-speed authorization: A control model in which permission decisions must keep up with automated or autonomous execution rather than human-paced workflows. In AI settings, it means access scope, tool reach, and approval logic must be enforced at runtime because the actor can complete meaningful work before a person can review it.
- Contextual tool access: A governance model where an agent’s allowed tools change based on prior actions, session context, or policy state. It is more precise than static role assignment because it treats the sequence of actions as part of the authorisation decision, not just the identity of the caller.
- Agentic worm: A hypothetical malware pattern in which one AI agent can cause another to run malicious or unsafe prompts, spreading behavior through inter-agent communication rather than through classic self-replication alone. The risk is recursive propagation through legitimate delegation and tool-use pathways.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org