C1 Autonomous Worker and the new identity control plane

At a glance

What this is: ConductorOne’s C1 Autonomous Worker is an autonomous agent for identity operations that runs work loops, carries state, executes code, and acts on behalf of a user across the platform’s API surface.

Why it matters: For IAM practitioners, it shows how autonomous execution pushes identity governance beyond static entitlements into runtime control, delegated authority, and auditable action chains across NHI, agentic AI, and human access programmes.

👉 Read ConductorOne's post on the C1 Autonomous Worker and identity governance

Context

Autonomous worker governance starts from a broken assumption: access review and approval models assume the actor is still waiting when the control runs. C1 Autonomous Worker is built to run work loops, preserve state, and execute code on behalf of a user, so governance must account for execution that progresses without human pacing.

That matters to identity teams because the same access graph now has to govern humans, non-human identities, and autonomous agents in the same environment. The practical question is no longer whether an agent can ask for work, but whether the programme can constrain what it can know, do, and persist across a session.

Key questions

Q: What breaks when autonomous workers carry state through identity workflows?

A: Periodic review models break because the worker can complete multiple steps, preserve intermediate results, and change identity state before any human control cycle can catch up. The control problem is no longer just whether access exists, but whether stateful execution can outpace certification, approval, and remediation. That is why session-aware governance matters.

Q: Why do autonomous agents complicate delegated access controls?

A: They complicate delegated access because the actor is not merely using a permission, it is executing a chain of actions on behalf of someone else. The boundary that matters is the operator’s real entitlement scope, enforced at runtime and preserved in audit trails. Without that, accountability becomes ambiguous.

Q: How should security teams govern context access for autonomous workers?

A: Security teams should treat context as a separate control surface from action. An autonomous worker may be allowed to perform a task without being allowed to read, combine, or retain every supporting data source. That separation reduces the chance that a session accumulates more knowledge than the task requires.

Q: Who is accountable when an autonomous worker makes an access change?

A: Accountability should remain tied to the operator, but only if the platform preserves a clear identity chain from human requester to agent action. If the audit trail cannot show who delegated the task, what access was used, and which action was taken, accountability becomes procedural rather than evidentiary.

How it works in practice

Stateful work loops and long-horizon execution

A stateful autonomous worker is different from a chatbot because it can carry intermediate results across multiple steps and return to them later. That long working horizon matters when a task spans entitlement discovery, analysis, and remediation, because the identity control plane has to survive beyond a single request-response cycle. State storage is what lets the agent resume work, but it also means the governance surface includes retained context, not just immediate action.

Practical implication: review how your controls behave when an actor keeps state across multiple steps and sessions, not just within one request.

Code execution versus inference in identity operations

The article draws a hard line between inference and code. Inference predicts likely text or action; code executes deterministic computation on real data. For identity governance, that distinction matters because a code-executing agent can process entitlements, generate evidence, and make changes at scale without relying on a human analyst to interpret each step. The risk profile is therefore not just automation volume, but delegated computation with operational authority.

Practical implication: classify code-executing agents as execution actors that need runtime guardrails, not as passive assistants.

Delegated API access and audit attribution

C1AW runs with the exact access of the user operating it, and each action is attributed to that user’s agent identity in the audit trail. That creates a governance model closer to delegated authority than shared service access. The key technical question is whether the runtime policy engine can consistently enforce the operator’s real permissions across every API call while preserving enough attribution to reconstruct intent after the fact.

Practical implication: verify that delegated actions remain bound to the operator’s actual entitlement scope and produce reviewable audit trails.

NHI Mgmt Group analysis

Autonomous workers collapse the assumption that governance can wait for the next review cycle. Access review processes were designed for actors whose privilege persists long enough to be observed, certified, and remediated. That assumption fails when a worker can carry state, execute code, and finish a task before a reviewer ever sees the action. The implication is not simply more review activity, but a rethink of what it means for an identity state to be governable at all.

Delegated API access becomes a control-plane problem, not a permissions problem. Once an autonomous worker can act across a full API surface, the decisive issue is not whether a permission exists in isolation. It is whether runtime policy, context filtering, and audit attribution preserve the operator’s true authority boundaries as the agent chains actions. Practitioners should treat the API layer as the place where identity, execution, and accountability now meet.

State retention creates identity blast radius inside the session itself. When an autonomous worker stores intermediate results and resumes work later, the session becomes a governed object, not just a transport mechanism. That means context, not only credentials, can widen exposure if the agent is allowed to keep information it should never combine. The practical conclusion is that session design has become a security control surface in its own right.

Machine-speed governance will outpace human-paced administration unless identity programmes adapt their control assumptions. A worker that clears tasks, provisions actions, and delivers artifacts on behalf of a user changes the tempo of identity operations. The field should stop measuring control maturity only by whether actions are reviewable and start asking whether the programme can constrain autonomous execution before the action chain completes.

Identity governance is now the layer where work orchestration and entitlement control converge. The article signals a market shift toward systems that do not just authenticate actors but also govern what those actors are allowed to know, do, and preserve while they work. That is a broader category shift for IAM, PAM, and NHI programmes, and it will force teams to align lifecycle, runtime policy, and audit in one model.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control baseline, read OWASP NHI Top 10 alongside Ultimate Guide to NHIs.

What this signals

Runtime governance for autonomous workers will become a design requirement, not an operational nice-to-have. The more work shifts into agents that can hold state and act across API surfaces, the less useful periodic oversight becomes as a primary control. Teams should expect identity programmes to move toward session-aware enforcement, because the risk is not simply over-permissioning, but permission use that completes before review can begin.

Ephemeral decision windows will define the next control gap. The issue is not only whether an agent has access, but whether the access exists long enough for the programme to observe it. If the session is the governing unit, then lifecycle, audit, and policy need to be wired to action completion rather than human calendar cadence.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs, autonomous execution only widens the blast radius unless context, access, and execution are separated.

For practitioners

• Map autonomous execution points Identify where agents can write code, retain state, or make API calls on behalf of users, then classify those paths as execution surfaces rather than simple workflow automation.
• Reassess delegated permission boundaries Compare the agent’s effective access to the operator’s real entitlements, and require runtime checks at the API layer for every action that crosses privilege boundaries.
• Separate context access from action access Limit what an autonomous worker can read, combine, and persist even when the underlying permissions would allow it to act, especially across entitlement and evidence workflows.
• Instrument audit trails for agent identities Ensure every agent action is attributed to a distinct identity that can be reviewed alongside the human operator, so delegated activity can be reconstructed without ambiguity.
• Redesign reviews for within-session change Move beyond periodic recertification assumptions and test whether your controls can detect and constrain privilege use before the autonomous task completes.

Key takeaways

• Autonomous workers change identity governance from access approval to runtime execution control, because the actor can complete work before a reviewer sees the state change.
• The evidence base is already strong enough to justify action now, with most organisations reporting AI agents acting beyond intended scope in production environments.
• Practitioners should redesign delegation, context access, and audit attribution together, because those three controls now determine whether autonomous work remains governable.

Key terms

• Autonomous Worker: An autonomous worker is an identity-bearing software actor that can carry state, execute code, and take actions on behalf of a user without step-by-step human prompting. In identity governance terms, it behaves like a delegated execution principal with runtime authority that must be bounded, attributed, and reviewed.
• Delegated API Access: Delegated API access is permission granted to a software actor to act within the authority of a human operator. The important control question is whether the platform enforces the operator’s true entitlement scope at runtime and preserves a clear audit chain back to the requester.
• Stateful Execution: Stateful execution is the ability of an actor to retain intermediate results and use them in later steps of the same task. For autonomous identity workflows, that makes the session itself a governed object because context retention can widen exposure, alter decisions, and extend the blast radius of a task.
• Identity Blast Radius: Identity blast radius is the amount of access, context, and downstream change an identity can affect once it starts acting. In autonomous environments, it is shaped not only by entitlements but also by state retention, runtime policy, and the speed at which the actor can chain actions.

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.

This post draws on content published by ConductorOne: Introducing the C1 Autonomous Worker. Read the original.