AI agent agency is reshaping enterprise identity controls

At a glance

What this is: This is a conference-based analysis of how AI agents are moving from assistance to independent action, and the key finding is that enterprise identity controls are being outgrown by systems that can commit, test, deploy, and resolve work without direct human input.

Why it matters: IAM and IGA teams need to reassess authorisation, observability, and lifecycle governance when the identity subject is no longer a person or static workload, but an agent that can act, chain tools, and change state during a session.

By the numbers:

• Multiple founders said 70-80% of code at their companies is now written by AI.
• Intercom's AI agent resolves 86% of customer conversations without human involvement.

Context

AI agent agency is the point at which a system stops merely responding and starts initiating actions on its own. In enterprise identity terms, that changes the governance problem from granting access to managing runtime authority, because the actor can now choose tools, take steps, and complete workflows without a human click at each stage.

WorkOS frames the shift through conversations at AWS re:Invent 2025, where founders and builders described AI systems writing code, committing changes, running tests, and deploying software. That is a different identity model from traditional automation, because the security question is no longer only what the system can reach, but what it can decide to do once it is inside the workflow.

For IAM, IGA, and PAM teams, the implication is that access control needs to follow execution, not just provisioning. If the system can act with agency, then approval, logging, and revocation must account for actions taken mid-session, not only entitlements assigned at the start.

Key questions

Q: What breaks when AI agents can act faster than human approval processes?

A: Human approval workflows lose their value when an autonomous system can chain reconnaissance, credential use, and lateral movement in seconds. The practical failure is not just speed, but loss of intervention points. Security teams need runtime controls, scoped permissions, and detection that can interrupt the agent before it completes a goal-directed exploit chain.

Q: Why do autonomous AI systems create more identity risk than normal automation?

A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person. That makes intent less predictable and review cycles less useful. The risk increases when the system can broaden scope or trigger actions that affect data, money, or compliance.

Q: How can teams tell whether an AI agent is safely governed?

A: A governed AI agent has explicit ownership, narrowly defined tool access, visible decision paths, and tested failure modes under adversarial input. If the organisation cannot explain who approves its scope, what it can reach, and how it is monitored, the agent is operating outside acceptable control boundaries.

Q: Should organisations treat AI agents like human users in IAM?

A: No. Human IAM assumes a person logs in, works within a session, and can be reviewed later as a stable identity holder. Agents can act at machine speed, across multiple systems, and with changing runtime context, so they need identity governance built around execution and delegation rather than human authentication patterns.

Technical breakdown

From assistant to agent: why agency changes identity control

An assistant returns answers. An agent can take actions, chain tools, and continue a task until it reaches an outcome. That distinction matters for identity because traditional controls assume the actor waits for a request, then receives a bounded permission. An agent can instead initiate steps, select tools, and carry state forward across multiple actions. In that model, authorisation is no longer a single provisioning event. It becomes a runtime governance problem involving scopes, approvals, observability, and rollback when the agent’s behaviour diverges from what was intended.

Practical implication: design authorisation around task-scoped execution paths, not static entitlements.

Why autonomous execution breaks human-paced review models

Access reviews, recertification, and manual approvals assume access persists long enough to be observed and judged. Autonomous execution breaks that assumption when a system can request, use, and release privilege within the same workflow window. Even when the underlying identity is technically a service account or token, the behaviour is different because the decision loop is no longer human-paced. The result is governance lag: the control sees the grant, but not the sequence of actions that happened before a reviewer could intervene. That makes time, not just privilege, a security variable.

Practical implication: move governance checks to issuance and execution time, not quarterly review cycles.

Documentation, observability, and the control plane for AI agents

The article shows that better documentation can improve AI-generated output, but from an identity perspective the more important point is that agents depend on machine-readable context and operational telemetry. If a system can write code, commit to GitHub, run tests, and deploy, then identity control depends on whether those actions are visible, attributable, and bounded. Observability becomes part of authorisation enforcement, because you cannot govern what you cannot reconstruct. For autonomous systems, the control plane must include audit signals that show which tool was used, when, and under what delegated scope.

Practical implication: require end-to-end action logs across tools, repositories, and deployment systems.

NHI Mgmt Group analysis

Runtime authority is now the identity problem, not just access permission. When an AI system can commit code, run tests, and deploy changes, the control objective shifts from granting access to governing action sequence. That means the important question is no longer what the actor can theoretically reach, but what it can do in a live workflow before any human review occurs. Practitioners should treat agency as a governance boundary, not an implementation detail.

Access review processes assume access persists long enough to be reviewed, and autonomous actors invalidate that assumption. The model behind recertification is built on stable entitlements and human-paced decision loops. An autonomous agent can acquire and release privilege within a single session, leaving no durable state for the reviewer to certify. The implication is not simply that reviews need to happen faster, but that the review model itself is misaligned with the actor’s runtime behaviour.

Identity blast radius becomes a more useful concept than broad least-privilege slogans. In agentic systems, the critical question is how far one delegated action can propagate across code, infrastructure, and customer-facing workflows. A single tool-use decision can trigger downstream state changes that traditional IAM does not model well. Practitioners should map the complete action chain, because the risk is no longer one permission in isolation but the compounded effect of delegated actions.

AI governance and identity governance are converging at the execution layer. The article’s examples show that AI adoption is not just a model-risk issue or a developer productivity issue. It is becoming an identity lifecycle issue because the same system can be provisioned, used, observed, and retired like a non-human identity with independent behaviour. The field now needs governance that spans identity, telemetry, and execution context, not separate policy silos.

Named concept: agentic execution boundary. This is the point where an AI system stops being a passive tool and starts operating as an actor with its own runtime decision path. Once that boundary is crossed, controls built for request-response software lose fidelity. Practitioners need to define where agency begins, because everything before and after that point requires different governance assumptions.

What this signals

Agentic execution boundary: the line between assistance and independent action will become a core governance object. Once systems can decide, chain tools, and act without a human in the loop, IAM teams need to define where authority starts, where it ends, and which actions require renewed trust.

The practical shift is away from periodic entitlement review and toward runtime guardrails. Security teams should expect AI agents to behave less like static workloads and more like short-lived actors whose permissions, logs, and rollback conditions must all be bound to a specific task.

Workflows that span code repositories, CI, and deployment systems need identity controls that travel with the action path. If the organisation cannot correlate each step back to the delegated scope, it cannot prove that the agent stayed inside policy.

For practitioners

• Define the agentic execution boundary Map exactly where an AI system is allowed to move from suggestion into action, including tool use, code changes, and deployment triggers. If the workflow can continue without a human approval gate, treat that boundary as an identity governance control point.
• Scope agent permissions to a single task Assign the narrowest workable set of tools and resources for one workflow, then revoke or invalidate that scope as soon as the task ends. Do not rely on standing permissions for systems that can chain actions across repositories, tests, and release pipelines.
• Instrument every agent action end to end Require logs that show tool selection, execution timing, and downstream state changes across source control, CI, and deployment systems. Without correlated telemetry, it is impossible to reconstruct what the system actually did or to prove that it stayed within scope.
• Separate human review from machine execution Keep human approval at the points where autonomy could expand blast radius, such as production deploys, privilege escalation, or cross-system changes. Review should validate the policy, not try to observe every micro-action after the fact.

Key takeaways

• AI agents are moving beyond answer generation into independent workflow execution, which changes the identity problem from access assignment to action governance.
• The most important control gap is not whether the system has credentials, but whether organisations can bound, observe, and revoke its runtime authority fast enough.
• IAM and IGA programmes need to treat agent agency as a distinct governance boundary and redesign reviews, approvals, and logging around that boundary.

Key terms

• Agentic execution boundary: An agentic execution boundary is the point at which an AI agent is allowed to move from proposing actions to actually performing them. For identity teams, this boundary matters because it determines when runtime decisions begin to affect access, data, and external systems.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• 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.

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 IAM programme, it is worth exploring.