Why do RBAC and DLP often miss AI agent risk?

Why This Matters for Security Teams

RBAC and DLP were built for users, endpoints, and known data flows, not for autonomous software that can decide its next action in real time. An agent can chain tools, pivot across systems, and change its behavior after a prompt, which means the control point is no longer just access to a file or app. That is why guidance from the OWASP Agentic AI Top 10 and NHI research such as OWASP NHI Top 10 emphasizes runtime context, not just static entitlements.

The practical problem is that an AI agent may look authorized under RBAC while still being unsafe because the immediate action is not aligned with the user’s intent, the task boundary, or the current data sensitivity. DLP also struggles because it usually detects patterns after content is already in motion or already transformed. NHI Management Group’s report AI Agents: The New Attack Surface notes that 80% of organisations have seen agents act beyond intended scope, which is exactly the kind of drift static controls miss. In practice, many security teams only discover this after an agent has already touched the wrong system or moved data outside policy.

How It Works in Practice

The answer is not to replace RBAC and DLP, but to surround them with runtime authorisation and workload identity controls that understand the task the agent is trying to complete. Current best practice is evolving toward intent-based decisions, where each tool call is evaluated using context such as the originating prompt, the approved objective, the target system, the data classification, and the agent’s current trust state. That approach aligns with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which push teams toward continuous assessment rather than one-time approval.

In practice, the stronger pattern looks like this:

• Issue short-lived, task-scoped credentials instead of static API keys.
• Bind the agent to a workload identity such as SPIFFE, SPIRE, or OIDC-backed service identity.
• Evaluate policy at request time with policy-as-code, such as OPA or Cedar, using current context.
• Separate read, transform, and write permissions so the agent cannot silently escalate from analysis to exfiltration or deletion.
• Log the agent’s intent, tool use, and data access path so investigations can reconstruct decisions.

This is where the NHIMG analysis of LLMjacking: How Attackers Hijack AI Using Compromised NHIs becomes relevant: once a secret is stolen, an attacker can operate as the agent or alongside it with very little friction. Static DLP rules may still fire on known file types, but they will not reliably detect a legitimate-looking action that becomes unsafe because the agent has been redirected mid-task. These controls tend to break down in multi-tool, multi-step agent workflows because each individual action can look normal while the chain of actions is not.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance safety against latency, policy maintenance, and false positives. That tradeoff is real, especially when agents are used in developer tooling, support workflows, or business automation where teams expect low-friction execution. Guidance suggests starting with the highest-risk actions first, but there is no universal standard for exactly how much context an authoriser must inspect.

Some environments still rely on DLP as a compensating control for regulated data, which remains useful for known patterns and outbound channels. The limitation is that DLP is reactive and content-centric, while agent risk is often behavioral and intent-centric. In high-volume environments, best practice is to use DLP as a backstop while moving privileged agent actions behind runtime checks and just-in-time grants. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio illustrates how token theft can turn a normal workflow into an abuse path, and the Replit AI Tool Database Deletion case shows why write and destructive permissions need stricter guardrails than read-only access. In many real deployments, the failure appears only when a tool chain is promoted from test to production without rethinking the agent’s effective authority.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?
• Why do AI agents create new risk in non-human identity management?
• What is the difference between human identity governance and AI agent governance?