What breaks when authorisation is based only on the agent’s starting permissions?

You lose sight of authorisation drift. An agent may begin within scope and then expand its effective access by chaining tools or changing actions as context changes. If governance only checks the starting permission set, it can miss the actual path the agent took through the environment.

Why This Matters for Security Teams

When authorisation is checked only at the start of an agent run, security teams lose the ability to see what the agent actually did after it began acting. That is a different problem from ordinary least privilege. An autonomous system can chain tools, change tactics, and accumulate access as context evolves, which means the original permission snapshot is no longer a reliable control point. Current guidance in the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime governance because agent behaviour is dynamic, not fixed.

NHIMG research shows the scale of the underlying identity problem: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames, which makes stale access easier to exploit once an agent begins to drift. The risk is not theoretical. Incidents such as Replit AI Tool Database Deletion and CoPhish OAuth Token Theft via Copilot Studio show how quickly tool use can move outside the intended path once an agent has initial access.

In practice, many security teams encounter authorisation drift only after the agent has already chained tools and crossed trust boundaries, rather than through intentional runtime policy checks.

How It Works in Practice

Static, role-based IAM answers the wrong question for autonomous systems. It asks, “What was this agent allowed to start with?” The better question is, “What is this agent trying to do right now, with this context, on this resource?” That is why intent-based or context-aware authorisation is emerging as the practical model for agents. The decision point moves from pre-defined entitlements to runtime evaluation, where policy can inspect task context, data sensitivity, destination tool, user approval state, and risk signals.

In mature designs, the agent’s workload identity becomes the identity primitive, not a long-lived secret. Standards such as SPIFFE and OIDC are commonly used to prove what the workload is, while just-in-time credentials limit what it can do for a short window and revoke access when the task ends. That approach aligns with the control logic described in the OWASP Non-Human Identity Top 10 and with NHIMG guidance in the Ultimate Guide to Non-Human Identities, which emphasizes visibility, rotation, and offboarding as baseline governance.

• Issue ephemeral credentials per task, not standing access for the life of the agent.
• Evaluate policy at request time using policy-as-code such as OPA or Cedar.
• Bind access to workload identity and current context, not only to the agent’s starting role.
• Revoke or narrow scope when the agent changes tools, data classes, or destinations.
• Log the full action path so drift can be reconstructed after the fact.

This model is especially important because agents can pivot in ways humans usually cannot, including chaining tools and escalating by composition rather than by a single obvious privilege jump. These controls tend to break down in legacy environments that still rely on shared service accounts, long-lived API keys, or opaque third-party integrations because there is no reliable runtime signal to re-evaluate trust.

Common Variations and Edge Cases

Tighter runtime authorisation often increases operational overhead, requiring organisations to balance stronger containment against latency, policy complexity, and developer friction. That tradeoff is real, and current guidance suggests it is better to absorb the complexity centrally than to let each agent accumulate unchecked privilege. There is no universal standard for agent runtime authorisation yet, so teams should treat intent-based controls as an evolving practice rather than a settled checkbox.

Some environments can tolerate coarse-grained checks if the agent is read-only, tightly sandboxed, and never exposed to sensitive data. Others cannot, especially where the agent can write to production systems, call external APIs, or operate alongside human approvals. In those cases, static permissions are not enough even if the starting role looks narrow. The same warning appears in recent NHIMG analyses such as Amazon Q AI Coding Agent Compromised and Analysis of Claude Code Security, where the important failure mode is not just access at launch, but what the agent can do after instructions, tools, or context change.

For security leaders, the practical rule is simple: if the agent can decide, adapt, or chain actions, authorisation must be re-decided at runtime. Starting permissions are only the opening condition, not the control boundary.

Related resources from NHI Mgmt Group

• What breaks when a classifier is used as the approval layer for agent actions?
• What breaks when agent approval is handled only at the platform level?
• What breaks when retrieval permissions are not separated from execution permissions?
• Why do MCP-based agent workflows matter for NHI governance?