How should security teams govern LLM and agent access in production?

Why This Matters for Security Teams

Production LLMs and agents are not just applications; they are identity-bearing workloads that can read data, call tools, and trigger downstream actions. That makes access governance a control-plane problem, not a model-quality problem. Current guidance from the OWASP Agentic AI Top 10 and NIST AI governance material points to the same issue: when an agent can chain tools, static permission models become brittle fast.

NHI Management Group research on the State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a strong signal that most teams still lack consistent ownership, rotation, and monitoring for machine identities. In practice, access drift is especially dangerous for LLM systems because the blast radius is often invisible until logs are reviewed after the fact. Security teams that treat a connector, a service account, and an autonomous agent as separate problems tend to miss the way they operate as one attack path. In practice, many security teams encounter abuse only after an agent has already touched sensitive data or invoked a privileged workflow, rather than through intentional access review.

How It Works in Practice

The most workable pattern is to govern LLMs and agents as a single identity surface with runtime controls. That means each model endpoint, agent runtime, connector, and service account needs an owner, a scoped purpose, and a policy that is evaluated at request time. For autonomous workloads, role-based access alone is usually too coarse because the agent’s next action is not fully knowable in advance. Instead, teams are moving toward intent-based or context-aware authorisation, where the policy engine decides whether a specific task is allowed based on data sensitivity, environment, tool risk, and current session state.

In practice, that also means short-lived credentials. Just-in-time provisioning and ephemeral tokens reduce the value of stolen secrets and make revocation possible when a task completes. For workload identity, many teams are adopting cryptographic identity primitives such as SPIFFE/SPIRE or OIDC-issued workload tokens so they can prove what the agent is, not just what password it knows. This matters because agents can move laterally, chain prompts into tools, and escalate in ways that are hard to predict. Controls should therefore be evaluated alongside logging and policy-as-code, not as separate checkpoints.

• Define a named owner for every model, agent, connector, and secret issuer.
• Scope access to task, data class, tenant, and environment.
• Issue credentials per task, with short TTLs and automatic revocation.
• Log the acting identity, prompt or request context, data touched, and downstream actions.
• Review policies continuously with tools such as OPA or Cedar rather than relying on static grants.

This aligns with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize governance, accountability, and operational controls over unchecked autonomy. These controls tend to break down when agents are allowed to operate across legacy systems that cannot enforce request-time policy or when shared service accounts obscure which workload actually performed the action.

Common Variations and Edge Cases

Tighter access controls often increase integration overhead, requiring organisations to balance blast-radius reduction against developer friction and operational latency. That tradeoff is real, especially in environments with many third-party tools or rapidly changing prompts. Best practice is evolving, but there is no universal standard for agent authorisation yet, so teams should be explicit about which parts are mandatory and which are compensating controls.

One common edge case is a human-in-the-loop agent that can take suggestions from a model but still execute privileged actions. In those workflows, approval gates help, but they do not replace workload identity or per-task scoping. Another edge case is vendor-managed AI where the organisation cannot directly control the runtime. In that situation, security teams should insist on logging, connector inventory, and constrained OAuth scopes, because visibility gaps are often where compromise begins. NHI Management Group’s research on the LLMjacking report and the AI LLM hijack breach illustrates how quickly exposed credentials can be abused once an attacker reaches the identity layer.

For agentic systems, the safest assumption is that behaviour will be dynamic and partially unpredictable. That is why current guidance suggests treating every change in tool access, data scope, or environment as a new authorisation decision, not a one-time onboarding event.

Related resources from NHI Mgmt Group

• How should security teams govern agent-native payments without creating new shadow access paths?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern access for agents and ephemeral workloads?