Notifications
Clear all
Topic starter
22/06/2026 10:07 am
TL;DR: Access control now has to cover what an agent can do, know, and retain across a work loop, not just what a person can click, as ConductorOne’s C1 Autonomous Worker adds stateful, code-executing, delegated agents across its API surface, shifting governance from dashboards to runtime execution and auditability according to ConductorOne.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
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.
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.
Q: How should security teams govern context access for autonomous workers?
A: Security teams should treat context as a separate control surface from action.
Practitioner guidance
- 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.
What's in the full announcement
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- How the C1 Autonomous Worker is configured to approve, deny, reassign, and escalate requests across the platform
- Examples of how the agent writes code to analyse entitlements and deliver CSV, PDF, or JSON outputs
- The runtime policy model that determines when sensitive changes route to a human approver before execution
- The product walkthrough for linking Slack identity to C1 identity and handing off work in thread
👉 Read ConductorOne's post on the C1 Autonomous Worker and identity governance →
Autonomous worker governance: what changes for identity teams?
Explore further
22/06/2026 10:53 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: C1 Autonomous Worker and the new identity control plane
