Least-Privilege Access Enforcement for AI Agents at Runtime

Least-privilege access enforcement for AI agents must govern what happens during execution. Provisioning sets the starting permissions, but agents can combine access across tools as a task unfolds. Enforcement therefore needs controls that keep checking against the task, block violations before they complete, and end permissions when the work ends.

Why provisioning-time scoping is not enough for AI agents

An employee’s access usually follows a manager’s approval or a ticketing workflow and is recertified on a cycle. An agent’s access is granted programmatically at deployment, often without a review step. Employees sign in as themselves, with grants tied to their roles and employment. Agents may instead run through service accounts, inherit the invoking user’s permissions, and retain access after its purpose has ended. The approval process and the working life of the permission no longer line up.

The least-privilege principle remains sound. Grant only the access a task requires, for only as long as the task runs. Applying that restriction only once leaves a system free to assemble its action paths while working. A deployment record shows what access was first granted, but it cannot show whether every later mix of tools and resources serves the task at hand. Entitlement review is still needed at the start, but it cannot keep execution within bounds.

How agents combine inherited permissions into access no one approved

An agent can combine access through services, connectors, and delegated tokens to reach more than its own grant seems to allow. Linked services, nested roles, and inherited API scopes make that reach difficult to see in a flat entitlement report. Shared service accounts then obscure attribution, while standing access keeps those paths available after the original need has passed. Each permission may look ordinary on its own, but together they allow something no one approved.

Varonis’ SearchLeak research found a concrete route through this problem. Because Copilot Enterprise operates with the user’s full graph permissions, manipulating the agent effectively gives an attacker the victim’s access to organizational data. Prompt injection thus turns inherited reach into an exploit path using existing permissions. The OWASP GenAI Security Project identifies three roots of excessive agency, namely excessive functionality, excessive permissions, and excessive autonomy. Together, they describe tools the task does not need, access it does not require, and high-impact actions without an approval gate.

Where static entitlement controls break down in practice

SkillScope, by Wu et al., accepted at ACM CCS 2026, identified 6,590 of tens of thousands of real-world Skills as exhibiting over-privileged behaviors. Its “deep-work” example declares a local session-tracking purpose but also instructs the agent to send reports to an external Telegram recipient. It additionally calls for collecting host identifiers, network settings, and command-history artifacts for outbound transmission. Those behaviors go beyond the requested task even if the agent has permission to carry out the operations involved. SkillScope also establishes why a permanent allowlist cannot settle the issue, since the same action may be legitimate under one prompt and over-privileged under another.

Palo Alto Networks Unit 42 documented a different failure in “Double Agent” on Google Cloud’s Vertex AI Agent Engine. A deployed agent inherited excessive default permissions through a Google-managed service account, which allowed credentials to be extracted and gave privileged access to consumer-project resources. The exploit depended on overpermissioned service-account scoping. In a separate case, security researchers documented hundreds of malicious Skills on the OpenClaw ClawHub marketplace that delivered credential stealers and executed unauthorized code. Those Skills inherited the broad system permissions that the OpenClaw agent process already had.

MCP leaves another gap at the protocol boundary. It does not define a role-based access control model, requires no mandatory authentication, and does not specify how a request maps to a verifiable enterprise identity. A provisioning record cannot give those missing guarantees for each request.

Why runtime behavior, not the provisioning record, is the true privilege boundary

Access review asks whether access was approved. Runtime enforcement checks whether the agent stays within its effective scope as it works. Only the latter can catch the moment when two legitimate permissions become an unauthorized action. Because over-privilege depends on the task, capability scope must be evaluated against the specific request and adjusted as the work evolves.

That scope includes both the sensitive data the agent can reach and the tools it can call. Agents can find, surface, and act on data faster and more thoroughly than a human, making reachable data part of the privilege boundary. Monitoring that reach matters, but observing a violation after completion is not the same as preventing it. Least privilege requires a decision before an operation crosses the sanctioned boundary. Runtime enforcement is therefore an architectural layer.

Intercepting tool calls before they complete

The most direct enforcement point sits between the agent and its tools. Progent, introduced by Shi et al. in 2025, provides a programmable policy framework that intercepts tool calls at runtime. It applies fine-grained allow or forbid decisions to tool invocations and arguments, with support for fallback actions and dynamic policy updates. Progent was evaluated on frameworks and products including LangChain, OpenAI Agents SDK, OpenHands, and AutoGen. Its central property is pre-completion enforcement, so a blocked call does not produce side effects.

Policy at this gate directly addresses excessive functionality and excessive permissions by restricting which tools may run and what they may do for the task. High-impact actions can also need explicit human approval before they run. But this layer sees only operations that go through the tool-call interface. Agents running through harnesses can reach file systems, network sockets, and process execution by other paths, leaving a gap below the gate.

Enforcing policy at the OS level to cover execution paths the tool layer cannot see

OS-level enforcement moves the decision to where system actions occur, regardless of how the agent reaches them. ActPlane, introduced by Zheng et al. in 2026, lets agents declare policies in a domain-specific language and enforces them in the OS kernel using eBPF. The agent is closest to the task and can express the relevant constraint, but the kernel applies it across execution paths. A detour around the tool interface does not become a detour around policy.

ActPlane’s information-flow control language attaches labels showing which sources have influenced an object. It propagates those labels across process, file, and network operations, allowing rules about isolated actions, data flow, and event ordering. A policy can, for example, require successful tests after changes before a commit. ActPlane also provides semantic feedback, unlike the opaque errors from OS sandboxes that can confuse an agent. With low end-to-end overhead, this approach complements tool-call interception by covering the execution paths that the higher layer cannot observe.

Scoping agent identity to the session so permissions expire with the task

Neither behavioral layer removes the risk of an underlying identity that retains standing credentials. The identity layer closes that gap by checking access requests as they come in, applying least-privilege policies, and creating temporary identities scoped to each session. Those identities are automatically decommissioned when the session ends. OPA can provide auditable, deterministic policy decisions at this layer.

The prerequisite is knowing which agents need those identities. An undiscovered agent cannot reliably receive a session scope, and an incomplete inventory leaves uncertainty about what data it can reach. Discovery matters here because it makes credential policy applicable across the fleet. Microsoft documents managed identities and least-privilege RBAC rather than shared service accounts as a deployment baseline. Session-scoped credentials extend that baseline to the duration of the work, giving permissions an expiry that matches their purpose.

Why LLM-enforced policy alone cannot substitute for deterministic runtime controls

Instructing the model to respect a boundary is simpler than building enforcement around it. It is also a different kind of control. ActPlane’s 2026 research states the distinction directly, since LLMs comply with instructions probabilistically and may violate them. A natural-language security specification offers no guarantee that the model will honor it, whether the failure comes from hallucination or an adaptive attack. Better wording does not turn a probability into an access check.

MCP orchestration makes the mismatch concrete. The agent predicts what a competent operator would try next, while validation and RBAC were built around explicit intent. The model can help express policy, but it cannot be the sole authority deciding whether its own next action obeys it. Deterministic controls outside the model keep what it proposes to do separate from permission to complete it. That separation is the point of the tool and OS layers.

Human approval is still important for high-impact actions, but people cannot make every routine decision. Research published in 2026 under arXiv:2606.08919 argues that oversight has a capacity ceiling and that fatiguing reviewers undermines approval-gating reliability. Machine-speed, deterministic enforcement scales, with human attention reserved for the decisions that require it.

What regulators and international safety bodies now expect from agent access controls

The 2026 Singapore Consensus on Global AI Safety Research Priorities places this architecture within a broader safety expectation. Published in July 2026, it followed the second International Scientific Exchange on AI Safety and included contributors from 13 countries. Its companion report lists Least Privilege first among ten foundational principles for managing agentic risk. It also names Runtime Assurance as Principle 7, which calls for checks throughout execution to make sure behavior stays within allowed boundaries. Deployment controls and operational assurance are treated as distinct responsibilities.

Other national and international guidance points in the same direction. China’s National Information Security Standardization Technical Committee (TC260) recommended enforcing least privilege for the work needed to complete a task and banning administrator privileges for agentic systems. The NSA’s Artificial Intelligence Security Center published its MCP security design considerations on May 20, 2026, to address the risks at the protocol level. Multi-country guidance developed with the FBI and the National Security Agency also recommends strict access controls, API security, least privilege, and defense-in-depth. These frameworks differ in scope, but converge on a clear expectation that agent access must be constrained in operation.

Building the enforcement stack in practice

The operational sequence starts with discovery. Security teams need a complete inventory before they apply policy, because an agent they do not know about stays outside the control process. That inventory establishes which agents exist and provides the starting point for understanding what data they can reach.

Second, record each agent’s effective privilege boundary as it works on a live task. Map its resources, connectors, and delegated scopes, including transitive paths through linked services and nested roles. Compare that reachable access with the intended entitlement model rather than treating the flat permission report as the whole picture.

Third, replace standing credentials with temporary identities scoped to each session. Apply deterministic policy evaluation, such as OPA. Decommission those identities automatically when the task ends.

Fourth, insert the tool-call policy layer. It should block over-privileged invocations before they complete and place explicit human approval gates on high-impact actions. This is where the task’s intended scope becomes a decision about the next proposed operation.

Fifth, add OS-level enforcement for file system, network, and process paths that go around the tool interface. An eBPF-based policy engine with semantic feedback can enforce those constraints without leaving the agent to interpret opaque errors.

Sixth, monitor and right-size continuously, using approved AI traffic, anomalous behavior, policy violations, and complete audit logs. Access reviews held each quarter miss day-to-day drift, and logs on their own cannot stop it. The required combination is agent discovery, behavioral monitoring, enforceable policy, and an auditable record of actions.