What should organisations do when agent access keeps expanding during pilots?

Why This Matters for Security Teams

When access keeps expanding during pilots, the problem is rarely the pilot itself. It is usually a sign that the identity model cannot keep pace with autonomous behaviour, changing tool use, and unclear task boundaries. Static roles are easy to approve, but they do not describe what an agent should do next, which is why privilege expands one exception at a time. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to runtime governance, not open-ended entitlement growth.

This is especially important for agents because they can chain tools, retry actions, and pursue goals in ways that are difficult to anticipate during initial access approval. If access is granted by exception review after exception review, the organisation is effectively training itself to accept overbroad permissions as normal. That creates a wider blast radius, weakens auditability, and turns the pilot into a hidden production exception. In practice, many security teams discover excessive agent privilege only after the agent has already accumulated broad access across systems, rather than through intentional design.

How It Works in Practice

The practical fix is to stop treating the agent like a user whose access can be permanently catalogued. For autonomous workloads, identity should be bound to the workload and the task, not to a human-like job title. That means using workload identity as the primitive, issuing short-lived credentials per task, and evaluating policy at request time based on the action, context, and risk. Standards-oriented approaches such as NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework both support this shift toward governance at runtime.

In operational terms, that usually looks like this:

• Issue ephemeral secrets with tight TTLs, then revoke them automatically when the task finishes.
• Authorise actions using context-aware policy rather than pre-approved role expansion.
• Bind the agent to a cryptographic workload identity, such as OIDC-based workload credentials or SPIFFE-style identity, so the system knows what the agent is.
• Separate planning from execution, so the agent cannot silently inherit new tool permissions just because a pilot needs a new step.
• Log each privilege grant and each tool invocation as an auditable event, not as a manual approval trail.

NHIMG research on the Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which is why repeated expansion during pilots should be treated as a design failure, not a normal growing pain. The same pattern appears in the OWASP NHI Top 10, where privilege creep and weak lifecycle control are recurring risks. These controls tend to break down when the pilot spans multiple SaaS tools and teams, because no single owner can see the full permission chain.

Common Variations and Edge Cases

Tighter agent access control often increases operational overhead, so organisations must balance speed of experimentation against the cost of repeated privilege changes. That tradeoff is real, especially in early pilots where requirements are still moving. There is no universal standard for this yet, but current guidance suggests keeping the pilot narrow, setting explicit task boundaries, and using policy-as-code so changes are deliberate rather than ad hoc.

Two edge cases matter. First, some pilots genuinely need broader access for a short discovery window. Even then, the access should be time-boxed and reviewed against a rollback plan, not left in place because the team is waiting for a future cleanup cycle. Second, some environments cannot support fine-grained runtime policy everywhere on day one. In those cases, security teams should start with the highest-risk tools, such as systems that can move money, modify production data, or chain into other credentials. NHIMG’s 52 NHI Breaches Analysis and the external OWASP Non-Human Identity Top 10 both reinforce the same operational lesson: the longer a pilot tolerates expanding access, the more likely it is to harden into permanent overprivilege. The model breaks down fastest in multi-agent pipelines where one agent can request access for another and the approval chain is not explicitly bounded.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• How can organisations reduce secret leakage in ServiceNow at scale?