When should organisations move beyond role-based controls for AI systems?

Why This Matters for Security Teams

Role-based access works when behaviour is predictable. AI systems that can pick tools, sequence actions, or retry work at runtime do not behave like static job functions, so a role can be both over-permissive and under-scoped in the same session. That mismatch creates preventable exposure around data access, tool invocation, and secret handling. NHI Management Group’s coverage of the LLMjacking threat pattern shows how quickly compromised machine identities become an attack path once AI workloads can be reached.

Security teams also need to separate human-centric access design from workload-centric authorisation. For AI systems, the question is not only who owns the account, but what the system is allowed to do at the moment it is acting. Current guidance from the NIST Cybersecurity Framework 2.0 and NHI research at Ultimate Guide to NHIs — Standards points toward tighter identity, access, and governance alignment, but the practical shift is from role membership to runtime context.

In practice, many security teams encounter excessive AI access only after a tool chain has already been abused, rather than through intentional design review.

How It Works in Practice

The usual move beyond role-based controls is to treat the AI system as a workload identity and evaluate permissions per action, not per job title. That means issuing credentials just in time, keeping them short-lived, and revoking them when the task ends. Where mature patterns exist, teams use workload identity primitives such as OIDC-issued tokens or SPIFFE-based identities to prove what the agent is, then layer policy decisions on top at request time.

In practice, this shifts authorisation from static RBAC to context-aware control. A retrieval step may be allowed to read one data source, while a summarisation step is blocked from writing to a ticketing system unless the prompt, destination, and data classification all match policy. That is why policy-as-code matters: tools such as OPA or Cedar can evaluate the live request, the agent state, and the target resource together instead of relying on pre-approved roles.

• Use ephemeral credentials per task, not shared long-lived secrets.
• Bind each token to a workload identity and a narrow execution context.
• Evaluate every tool call against policy at runtime.
• Revoke access automatically when the workflow completes or drifts.

This approach aligns with the operational realities described in the DeepSeek breach discussion, where exposed credentials and leaked data show how quickly broad access becomes a containment problem. It also fits the direction of NIST Cybersecurity Framework 2.0 when applied to autonomous systems, where continuous governance matters more than one-time assignment.

These controls tend to break down when agents are allowed to chain multiple tools across loosely governed SaaS systems because no single policy point sees the full end-to-end action.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance stronger containment against developer friction and latency. That tradeoff is real, especially where teams want fast automation but still need auditability and revocation. Current guidance suggests starting with the highest-risk agent actions first: writing data, moving money, changing infrastructure, or accessing secrets.

There is no universal standard for exactly how much context an authorisation engine should inspect for AI systems yet. Some environments can enforce a simple allowlist of tools and destinations, while others need prompt-aware or state-aware policy evaluation. The right boundary depends on whether the agent is merely recommending actions or actually executing them.

Edge cases also matter. A model with read-only access can still create risk if it can exfiltrate sensitive data into downstream systems. Likewise, a “safe” role may become unsafe when combined with delegated credentials, cached tokens, or plugin privileges. NHI Management Group’s broader standards view at Ultimate Guide to NHIs — Standards is useful here because it frames identity as a lifecycle problem, not just an access grant.

Best practice is evolving, but the practical signal is clear: if the AI can decide what to do next, role-based controls alone are already too coarse.

Related resources from NHI Mgmt Group

• How should organisations test AI systems for bias before deployment?
• Why do identity controls matter before organisations claim AI productivity gains?
• Why is identity such a critical factor in securing AI agent systems?
• When is it appropriate to implement MCP in the context of AI systems?