Abstract
Of all the controls in this cluster, tool-permission scoping is the most tractable and the highest-leverage. You cannot reliably stop a model from being tricked, but you can deterministically bound what its tool calls are permitted to do — and that bound holds even when the trick succeeds.
We develop least privilege for agents concretely: why the model cannot be its own policy enforcer, how deterministic privilege control works, why monotonic confinement(privilege can only narrow without approval) is the right invariant [1], and how much the security/utility balance depends on the quality of the policies you write.
01Tool authority equals blast radius
The union of everything an agent’s tools can do is the exact definition of what a compromised agent can do. Least privilege is not hygiene here — it is the blast-radius bound.
A summarization task does not need a shell. A calendar assistant does not need to send money. Yet agents are routinely wired with a broad tool belt “so they can handle anything,” which means any successful injection or jailbreak inherits the full belt. The single most effective thing most teams can do is shrink the set of tools — and the set of arguments to those tools — available for a given task to the minimum that task requires.
02Why the model cannot self-police
A tempting design is to instruct the model to police its own tool use (“only call payment tools for legitimate purchases”). This fails for the same structural reason injection works: the policy lives in the same manipulable channel as the attack. If an injected instruction can change what the model does, it can change how the model interprets its own rules. Self-policing is a behavioral control; we need a structural one.
The enforcement point must be outside and after the model: the model emits a proposed tool call; a deterministic engine decides whether to allow it. The engine reads structured facts (tool name, argument values), not free-form intent, so it cannot be prompt-injected. This is the reference-monitor role in the mediation plane.
03Deterministic privilege control
Progent: Securing AI Agents with Privilege Control
T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, D. Song — submitted 2025-04-16 · revised 2026-05-14
- Question
- Can a deterministic layer confine an agent so a successful attack (e.g. injection) still cannot cause harm, without destroying utility?
- Method
- Symbolic policies over tool names and arguments; the model generates an initial policy from the task and may propose updates; an SMT solver classifies each update as narrowing (auto-applied) or expanding (requires approval), enforcing that privilege only ever contracts automatically. Integrates with mainstream agent frameworks.
- Key finding
- Significantly reduces attack success rate on standard agent-security benchmarks while preserving task utility.
- Reported metric
- Large ASR reduction with retained utility (AgentDojo / ASB)
- Limitations
- Effectiveness depends on the quality of initial and updated policies; a loose policy confines little; some legitimate novel actions require an approval round-trip.
- Why it matters
- The reference design for tool-permission enforcement: policy outside the model, deterministic, and monotonic — the properties that make it survive a compromised model.
04Monotonic confinement: the right invariant
The elegant idea in deterministic privilege control is the direction constraint. Over the life of a task, the agent’s privilege may shrink freely but may only grow through an explicit, approvable step [1]. This monotonic confinement matches how tasks actually evolve — you usually learn you need less than you feared — and it makes the dangerous direction (privilege expansion) the one place a human or a stricter check is inserted. An attacker who wants the agent to do something outside scope must trigger an expansion, which is exactly the event you gate and audit.
05The policy-authoring problem
Deterministic control moves the difficulty rather than removing it: someone must author policies that are tight enough to bound harm yet loose enough to let real work happen. Too loose and confinement is theater; too tight and the agent stalls on approval requests. Three practical strategies help:
- Model-proposed, human-ratified policies. Let the model draft the initial policy from the task, but treat it as a proposal the engine (and, for expansions, a human) validates — never as self-authorization [1].
- Tiered tool classes. Group tools by sensitivity (read-only, state-changing, irreversible/financial) and set defaults per tier, so most tasks inherit sane bounds without bespoke policies.
- Argument-level constraints. Bound not just which tool but with what arguments — a payment tool limited to a payee allowlist and a cap is far safer than an unbounded one.
06Over-privilege is the norm, not the exception
The empirical direction across agent-tool ecosystems is that skills and tools ship with far more privilege than their function requires, and that gap is exploitable. This mirrors the decades-old finding in conventional systems that permissions accrete and are rarely pruned. For agents the stakes are higher because the over-privileged actor is also injectable. The governance frameworks now name this explicitly as a top agentic risk [4].
07Allowlist, model-judged, or human-approve?
| Enforcement mechanism | Injection-resistant? | Utility impact | Where it fits |
|---|---|---|---|
| Model self-policing (prompt) | No — same channel | None | Not a security control; convenience only |
| Deterministic allowlist policy | Yes — reads structured facts | Low if policies are good | The default enforcement layer [1] |
| A second model as judge | Partially — judge is also injectable | Medium (latency, cost) | Outer heuristic layer, not load-bearing |
| Human approval per expansion | Yes | High if over-used | Gate on privilege expansion only |
Make the deterministic allowlist policy the load-bearing layer, enforced outside the model over tool name and arguments, with monotonic confinement [1]. Add a model-judge only as a soft outer heuristic, never as the guarantee, and reserve human approval for privilege expansion. Never rely on model self-policing as a security control — it is the behavioral trap this whole series warns against.
08Production failure modes
The agent has broad standing tool access for every task
Mechanism
To avoid re-configuring per task, the agent is granted its full tool belt (including state-changing and irreversible tools) for all work. A single successful injection wields the entire belt.
Why the existing control failed
Privilege was provisioned for the union of all possible tasks rather than the current one; there was no per-call authorization bounding tool or arguments.
Signals to monitor
- Tool calls outside the current task’s expected set
- Arguments outside expected ranges (e.g. large amounts, unknown payees)
- Rapid succession of state-changing calls after reading external data
- Privilege-expansion requests that are auto-granted
Controls
- Deterministic policy over tool name + arguments [1]
- Task-scoped tool set; deny-by-default outside it
- Monotonic confinement: auto-narrow, approve to expand
- Argument-level constraints (allowlists, caps, ranges)
09Limitations
- Deterministic privilege control shifts effort to policy authoring; a loose policy provides little protection, and the security/utility trade-off is workload-specific [1].
- Benchmark results are measured on AgentDojo/ASB-style suites [2]; real deployments have messier tool surfaces where policy coverage may be incomplete.
- Argument-level policies are only as good as the schema; tools with free-form arguments are hard to constrain precisely.
- Least privilege bounds capability but does not detect in-policy misuse; it composes with identity, egress, and monitoring rather than replacing them.
10Where this leads
Bounding what tools can do pairs with bounding who the agent is (identity & access control) and where data can go (egress control). All three are enforced by the mediation plane and exist because content-layer defense against prompt injection is not sufficient on its own.
—References
- T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, D. Song. Progent: Securing AI Agents with Privilege Control. arXiv:2504.11703 [cs.CR], 2025. https://arxiv.org/abs/2504.11703
- E. Debenedetti, J. Zhang, M. Balunović, L. Beurer-Kellner, M. Fischer, F. Tramèr. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. arXiv:2406.13352 [cs.CR], 2024. https://arxiv.org/abs/2406.13352
- K. Huang, V. S. Narajala, J. Yeoh, J. Ross, R. Raskar, et al.. A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control. arXiv:2505.19301 [cs.CR], 2025. https://arxiv.org/abs/2505.19301
- OWASP. OWASP Top 10 for LLM Applications & Agentic AI Threats and Mitigations. OWASP GenAI Security Project, 2025. https://genai.owasp.org/
Engineering assistance
ProxyTech works with engineers and teams building production AI, cloud, security, data and distributed systems. If this analysis maps to a system you are designing or operating, we provide hands-on support and interview preparation for these domains.