How should security teams govern autonomous systems that create their own access?

Why This Matters for Security Teams

Autonomous systems that create their own access change the control problem from identity provisioning to runtime governance. Once an agent can request tokens, chain tools, and continue operating without a human in the loop, static IAM assumptions stop holding. Current guidance suggests treating the agent as a workload with active decision-making capability, not as a passive service account. That is why NHI governance must focus on ownership, expiry, policy, and traceability at the moment access is used.

This matters because agent behaviour is not fully predictable. A system may start with a narrow task and then expand its own reach through tool chaining, delegated access, or repeated token use. That risk is reflected in the AI Agents: The New Attack Surface report, where most organisations reported agent actions beyond intended scope. The broader NHI context is similar: the State of Non-Human Identity Security shows how weak rotation, monitoring gaps, and over-privilege continue to drive incidents. In practice, many security teams encounter agent overreach only after data has been accessed or credentials have already been reused, rather than through intentional design.

How It Works in Practice

Governance needs to shift to runtime controls that follow the agent through execution. That starts with registering every autonomous system as a distinct workload identity, then binding it to an owner, a purpose, and a hard expiry condition. For agentic systems, workload identity is the primitive that matters most because it proves what the agent is, while short-lived secrets prove what it may do for a specific task. Standards-based approaches such as NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both point toward context-aware controls rather than fixed entitlements.

In practical terms, security teams should combine:

• Just-in-time issuance of ephemeral credentials for a single task or session.
• Policy evaluation at request time, using context such as data sensitivity, destination system, and current risk posture.
• Automatic revocation when the task ends, the context changes, or the agent deviates from the approved goal.
• Continuous logging of tool calls, token use, and downstream actions for audit and incident response.

This is also where policy-as-code matters. Current best practice is evolving toward runtime decisions with tools such as OPA or Cedar, but there is no universal standard for this yet. The operating model should be informed by NHIMG guidance in the Lifecycle Processes for Managing NHIs and the Top 10 NHI Issues, both of which emphasise lifecycle control and exposure reduction. These controls tend to break down when agents operate across many SaaS tools and custom APIs because the authorisation context becomes fragmented and difficult to evaluate consistently.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance security gains against developer friction and automation latency. That tradeoff is real, especially in environments where agents need fast access to multiple systems or where workflows are highly dynamic.

There are also important edge cases. Some autonomous systems run inside vendor-managed platforms, where the organisation cannot directly enforce token lifetime or inspect every downstream call. Others use delegated human credentials, which creates ambiguity about whether the access belongs to the person, the workflow, or the agent itself. In those situations, current guidance suggests treating delegation as a high-risk exception and compensating with tighter scope, stronger logging, and shorter TTLs. The CSA MAESTRO agentic AI threat modeling framework is useful here because it pushes teams to map control failures across orchestration, memory, tools, and external systems. NHIMG’s Moltbook AI agent keys breach also shows why long-lived agent keys remain dangerous even when they are technically “machine only.” The real question is not whether an agent has access, but whether that access can be bounded, observed, and revoked before the next autonomous action begins.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams govern machine identity credentials in agentic AI environments?