AI agent agency is reshaping enterprise identity controls

At a glance

What this is: This is a round-up of re:Invent takeaways showing that AI agents are moving from code generation into real execution, with clear implications for identity, authorization, and operational control.

Why it matters: It matters because IAM teams now have to govern actors that can write, commit, deploy, and respond without the human pacing assumptions embedded in traditional access models.

By the numbers:

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

👉 Read WorkOS's takeaways from AWS re:Invent 2025 on AI agents and enterprise adoption

Context

AI agent governance is the problem space here: the article shows systems moving from suggestion to execution, with agents now writing code, committing changes, running tests, and even deploying. That shift matters because identity controls built for humans assume a stable operator, predictable approval points, and review windows that exist long enough for governance to happen.

The primary keyword is AI agent identity controls, and the article points to why that phrase now belongs in mainstream IAM planning. Once software can choose actions and carry them out inside developer workflows, the question is no longer whether the tool is useful, but whether the identity boundary around it is actually enforceable.

WorkOS frames the change through developer tools and enterprise adoption, but the governance implication extends beyond software delivery. Authentication, authorization, observability, and incident response all need to account for actors that behave more like runtime executors than conventional users.

Key questions

Q: How should security teams govern AI agents that can write and deploy code?

A: Security teams should govern AI agents as distinct identities with explicit tool scope, task boundaries, and revocation paths. If an agent can write, commit, test, and deploy, those permissions should be separated and logged so one workflow cannot silently become a production change path. Governance must follow the action chain, not just the application label.

Q: Why do AI agents create new identity risks compared with normal automation?

A: AI agents create new identity risks because they can choose their next action at runtime instead of following a fixed script. That makes privilege harder to predefine and easier to overextend, especially when one agent can chain repository access, CI execution, and deployment authority. The risk is not automation itself, but decision-making inside the workflow.

Q: What do teams get wrong about AI agent access reviews?

A: Teams often assume an access review can certify an agent the same way they certify a human or a service account. That fails when the agent’s behaviour changes session by session, because the review describes a static snapshot while the risk is dynamic execution. Review evidence should include tool use, action logs, and revocation tests.

Q: How should organisations offboard an AI agent when a workflow changes?

A: Organisations should offboard an AI agent by revoking credentials, removing tool bindings, and checking for downstream service accounts or deployment hooks created for the workflow. If the agent can still reach repositories or runtime environments after its job changes, the lifecycle was never fully closed and the identity remains active in practice.

Technical breakdown

Assistant to agent: why execution changes the identity model

A chat-style assistant responds to prompts, but an agent can take action: write code, commit it, run tests, and trigger deployment steps. That changes the identity problem because the system is no longer only producing text. It is operating inside a delegated execution chain where actions have side effects and privileges can be exercised without fresh human intent at each step. In identity terms, the trust boundary shifts from who can ask a question to what the actor can do after it decides to act. For IAM, that means the relevant unit is not the prompt, but the action path and the credentials behind it.

Practical implication: map every agent to the specific tools and permissions it can invoke, not just the application it talks to.

Why AI-generated code creates a secrets and access problem

When AI writes most of the code, it also increases the chance that secrets, tokens, or over-broad access patterns get copied into workflows, documentation, and deployment logic. The issue is not only code quality. It is identity propagation, because machine-created code often inherits machine credentials, service accounts, and CI permissions that outlive the task they were meant for. This is where NHI governance and software delivery meet: generated code can amplify standing privilege if access is embedded in templates, pipelines, or environment configuration. The result is more scale, but also more repeatable exposure if secrets are not tightly bounded.

Practical implication: review generated code for credential placement, pipeline privilege, and secret reuse before it reaches production.

The five-minute control window problem in autonomous workflows

The article’s five-minute sweet spot shows a common control boundary in AI operations: humans remain effective when they can re-enter the loop quickly, but long autonomous runs lose accountability and context. In identity terms, that means runtime decision-making can outrun review cadences, especially when the system is investigating, fixing, or deploying on its own. The control issue is not simply speed. It is that the governance artefact appears after the action has already happened. For agentic systems, observability, approval gates, and rollback design have to sit inside the action path, not after it.

Practical implication: design approval checkpoints and rollback hooks inside the task flow, not only at the end of the workflow.

Threat narrative

Attacker objective: The objective is to turn trusted development automation into an execution path that can modify code, reach production, or expose high-value credentials at machine speed.

1. Entry begins when an AI agent is granted legitimate access to developer tools, repositories, or deployment workflows as part of normal productivity tooling.
2. Escalation occurs when the agent can chain actions such as writing code, committing changes, running tests, and initiating deployment without fresh human approval.
3. Impact follows when the same delegated access is used to move changes into production or to propagate secrets, logic errors, or privilege misuse across the delivery pipeline.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 agent identity controls are now the governance gap, not the interface layer. The article makes clear that agents are moving from answering questions to performing work inside developer and operations pipelines. That changes the control problem from access to a tool to authority over a sequence of actions. Practitioners should treat each agent as a governed executor with explicit tool scope and revocation paths.

Least privilege stops being static when software can decide its own next step. The identity model behind many current controls assumes the actor’s intent is known at provisioning time. That assumption fails when an agent can branch, retry, or expand its action path at runtime based on what it sees. The implication is that privilege design has to account for action volatility, not just role assignment.

Identity review cycles are too slow for agentic execution loops. This article shows the pace mismatch between human governance and machine-paced task completion. Review, certification, and offboarding logic all presuppose that access persists long enough to be observed. When the actor completes the task in minutes, the control window collapses and the old cadence no longer proves anything.

Runtime governance gap: What this article really exposes is the gap between delegated permissions and delegated judgment. The agent is not only using access, it is choosing when to use it, which makes the policy boundary harder to define. Practitioners need to rethink whether their current IAM programme can distinguish between authorised use and machine-initiated execution.

Workflows, not users, are becoming the primary identity surface. The most important change here is structural: code pipelines, incident response paths, and deployment systems are now the place where identity risk accumulates. That is why NHI governance and agentic AI governance are converging. Security teams should stop treating agent access as a niche AI issue and start treating it as a core identity architecture problem.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• For the broader control model behind these failures, see The State of Secrets in AppSec for how secret sprawl, delayed remediation, and weak developer practice intersect.

What this signals

Runtime governance gap: AI agent adoption is forcing identity teams to move from provisioning-time thinking to action-time thinking. Once a system can commit code or trigger deploys on its own, the control question becomes whether the workflow can be interrupted, attributed, and revoked before the action chain completes.

The practical signal for programmes is that secrets, CI permissions, and deployment authority now need to be reviewed as one identity surface rather than three separate control domains. That is especially important when AI-written code can carry forward credentials or configuration patterns that expand blast radius faster than human review can catch them.

For teams mapping this to standards, the immediate reference point is OWASP Agentic AI Top 10. The broader warning is that 70-80% AI-generated code can become a governance multiplier when identity controls still assume human-paced execution.

For practitioners

• Inventory every AI agent as a distinct identity subject Record which repositories, build systems, ticketing tools, and deployment paths each agent can touch. Treat the agent’s tool graph as part of its identity profile so approvals and revocation can be traced to a named executor, not a generic platform role.
• Bound agent execution with task-scoped permissions Grant the minimum tool set needed for a single workflow and remove standing access where the task can be completed with ephemeral permissions. Separate code-writing, testing, and deployment privileges so one agent cannot cross all phases by default.
• Place human re-entry points inside the workflow Insert approval or verification steps before commit, before deployment, and before any privilege expansion. The goal is not to slow every action, but to ensure a human can interrupt a chain before the agent closes the loop.
• Watch for secret propagation through generated code Scan generated output and pipeline config for embedded tokens, API keys, and broad environment access. AI-written code should be checked for secret reuse and inherited privileges in the same way third-party code would be reviewed.
• Tie incident response to the agent lifecycle Define what it means to suspend, quarantine, or revoke an agent when behaviour changes or a model is replaced. Offboarding must cover credentials, tool bindings, and any downstream service accounts created for the workflow.

Key takeaways

• AI agents are becoming execution identities, which means identity controls now have to govern actions, not just access.
• The scale signal is clear: companies are already reporting 70-80% AI-written code and high-volume autonomous customer handling.
• Practitioners should separate tool scope, re-entry points, and offboarding logic so agentic workflows do not outrun governance.

Key terms

• AI Agent Identity: An AI agent identity is the set of permissions, credentials, and tool bindings that allow a software actor to take action in an environment. Unlike a human login, it may execute at machine speed and can chain multiple tools inside one session, which makes lifecycle control and attribution essential.
• Delegated Execution Chain: A delegated execution chain is the sequence of tools and systems an agent can invoke after it receives authority to act. The security risk is not only the first permission grant, but the ability to combine repository, CI, and deployment access into one uninterrupted path.
• Runtime Governance Gap: A runtime governance gap appears when a control is designed for static access but the actor makes decisions while running. In practice, this means review, approval, and certification happen too late to shape the action being taken, leaving the programme with visibility but no intervention point.
• Secret Propagation: Secret propagation is the spread of tokens, API keys, or certificates from one workflow into another through code, configuration, or automation. In AI-heavy development, generated code can copy or preserve credentials faster than human reviewers can notice, increasing exposure across environments.

Deepen your knowledge

AI agent identity controls and delegated execution paths are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting IAM for agentic workflows, it is worth exploring.

This post draws on content published by WorkOS: 10 takeaways from AWS re:Invent 2025. Read the original.