Most agent security writing stops at "use least privilege." This matrix says where the control actually lives.
It maps sixteen common agent tool classes to their primary risks, the specific engineering controls each one requires, and the enforcement point where that control sits, then assigns each class a default trust tier. It is the controls-side companion to the Frontier Cyber Risk Evaluation Taxonomy: the taxonomy names the threats, this turns them into a default-deny grant table an architect can hand to an implementer.
What's inside
- Sixteen agent tool classes, from browser automation to payment rails
- Primary risks, required controls, and the enforcement point for each
- A default trust tier per class, from read-only observation to privileged and irreversible
- Cross-cutting controls that apply across every tool class
- A cross-walk to the OWASP Top 10 for Agentic Applications 2026
The full document
This page renders the canonical matrix live from the GitHub repository at build time. Nothing is copied into the site, so the page and the source cannot drift. For the full document, version history, and license, go to the source:
A default-deny grant table mapping agent tool classes to their risks, the engineering controls each one requires, and where that control is enforced.
Version: 0.3 Date: 2026-06-16 Author: Larry Peseckis (larrypeseckis.ai) License: CC BY 4.0 Purpose: Map common agent tool classes to their primary risks, the engineering controls each one requires, and where that control is enforced. The point of this document is to turn agentic threat modeling into a default-deny grant table that an architect can hand to an implementer.
Design principles
- Default deny. A tool grant is an exception, not a baseline.
- Least agency. Grant the minimum autonomy and scope a task needs, time-boxed, and nothing more.
- Instruction / data separation. Page text, emails, retrieved documents, tool outputs, tool descriptions, and memory reads are data, never instructions, no matter how authoritative they sound.
Scoping note: enforcement points assume a broker / gateway architecture (a tool broker, a sandbox runtime, an egress proxy, and a central audit plane). Adapt the enforcement column to your own platform if it differs.
The Matrix
| Tool class | Default tier | Primary risks | Required controls | Enforcement point | OWASP ASI 2026 |
|---|---|---|---|---|---|
| Browser / web automation | Tier 0 unless state-changing | Indirect prompt injection from page content, session and cookie abuse, credential autofill theft, attacker-directed navigation | Per-task session isolation, URL allowlist with trust labels on retrieved content, confirmation gates on state-changing actions (purchases, submits), no credential autofill into agent sessions | Browser sandbox profile + content trust labeler | ASI01, ASI09 |
| Desktop / clipboard / GUI automation | Tier 0 observe, Tier 2 cross-app action | Copying secrets from other apps, pasting unsafe content into trusted sessions, clickjacking-style UI confusion, acting in the wrong window or account | Isolated desktop session, clipboard disabled by default, active-window allowlist, screenshot redaction, confirmation for cross-app paste or submit, no access to password managers | Virtual desktop sandbox + UI action broker | ASI02, ASI03, ASI09 |
| Shell / command execution | Tier 1 sandboxed, Tier 2 destructive | Destructive commands, persistence (cron, systemd, profile edits), privilege escalation, living-off-the-land | Ephemeral sandbox, deny-by-default command allowlist, no sudo, human approval for irreversible commands, immutable base image | Container sandbox + command broker | ASI05, ASI02 |
| File system | Tier 0 read, Tier 1 scoped write | Data exfiltration outside scope, overwrite or deletion of source data, path traversal, symlink escape | Scoped or chrooted directories, read/write separation, deny-by-default outside the workspace, no access to home, dotfiles, or secret stores, copy-on-write for inputs, canonicalize before access | Mount namespace + path canonicalizer | ASI02, ASI06 |
| Cloud API / control plane | Tier 0 list/read, Tier 2 create/delete/IAM | Resource abuse (compute spin-up, mining), credential misuse, IAM privilege escalation, lateral movement | Per-task least-privilege roles (short-lived, no static keys), explicit approval for create / delete / IAM actions, permission boundaries or SCPs, spend and resource quotas, full control-plane audit logging | IAM permission boundary + policy gateway | ASI03, ASI02 |
| Email / chat / messaging | Tier 0 read, Tier 2 send external | Social engineering via spoofed outbound, data leakage to wrong recipient, agent-driven phishing, injection from inbound messages | Recipient allowlist with confirmation on external addresses, DLP scan on outbound, no auto-send to new external recipients, inbound treated as untrusted data, volume and rate caps | Send gateway + DLP filter | ASI09, ASI01 |
| Code execution / interpreter | Tier 1 sandboxed, Tier 2 with egress or install | Malware generation and execution, unsafe dependency install, network exfil from the runtime, resource exhaustion | Isolated ephemeral runtime, egress blocked by default with an allowlist, packages from a vetted mirror only, CPU / memory / wall-clock limits, no host mount, dropped privileges | Microvm or gVisor sandbox + egress proxy | ASI05, ASI04 |
| Package manager / dependency install | Tier 1 vetted mirror, Tier 2 arbitrary install | Malicious packages, dependency confusion, post-install scripts, typosquatting, build-time secret theft | Vetted mirror, lockfiles, no arbitrary package install, post-install scripts blocked unless approved, SBOM generation, network isolation during build | Package proxy + build sandbox | ASI04, ASI05 |
| Memory / persistent context store | Tier 0 read, Tier 1 write-back | Memory poisoning that persists across sessions, cross-session or cross-tenant contamination, retrieval of poisoned RAG content, stale-trust escalation | Provenance and source tags on every stored item, integrity checks and signing, tenant and session partitioning, untrusted-at-read handling, TTL plus review on auto-written entries, separate read and write-back permissions, quarantine for externally sourced content | Memory broker + provenance layer | ASI06 |
| Database / data store (direct query) | Tier 0 read-replica, Tier 2 writes or DDL | Mass read and exfiltration, destructive writes (DROP, mass UPDATE or DELETE), injection via constructed queries, schema modification | Read-replica for reads, parameterized queries only, row and column scoping via views, no DDL, statement allowlist or review for writes, result-set size caps, separate read and write credentials | DB proxy / query broker | ASI02, ASI03 |
| Secrets / credential vault | Tier 1 broker-mediated, Tier 2 direct retrieval | Credential exfiltration, scope creep across secrets, secret leakage in logs and traces, replay | Just-in-time short-lived issuance, per-tool scoped secrets (no blanket vault read), redaction so secrets never hit logs or transcripts, broker-mediated use so the agent never sees the raw value where possible, audit on every retrieval, rotation | Secrets broker with dynamic secrets + log redactor | ASI03 |
| Network egress / raw HTTP and sockets | Tier 1 allowlisted, Tier 2 raw or new destination | SSRF against internal and metadata endpoints, exfiltration channels, command-and-control beaconing, DNS exfil | Default-deny egress with destination allowlist, block link-local metadata (169.254.169.254) and RFC1918 by default, DNS filtering, payload size and rate caps, no raw sockets unless explicitly granted | Egress proxy / firewall | ASI02 |
| MCP / dynamic tool loading | Tier 2 | Malicious or spoofed server, tool shadowing and name collisions, post-approval rug-pull where a tool definition changes after trust, injection via tool descriptions and metadata | Pinned and signed tool manifests, server allowlist with identity verification (mTLS), version pinning with change review, least-agency scope per tool, tool descriptions treated as untrusted, human approval to add servers | Tool registry / broker with signature verification | ASI04, ASI02 |
| Sub-agent spawning / orchestration | Tier 2 | Privilege escalation through delegation, loss of control or unbounded recursion, rogue or colluding agents, injection across inter-agent messages | Subset-only scope inheritance (child scope is always a subset of parent, never wider), delegation depth and fan-out caps, signed and authenticated inter-agent messages, per-agent identity and audit, kill switch that propagates to children, no self-replication | Orchestrator with identity and scope-inheritance enforcement | ASI07, ASI03, ASI10 |
| Scheduler / autonomous triggers | Tier 2 | Persistence beyond the session, time-delayed or logic-bomb actions, trigger flooding, unattended execution without oversight | TTL and expiry on every scheduled task, human approval to create recurring or persistent jobs, scheduled actions inherit the same scope and approval gates as live ones, registry and audit of all triggers, max-concurrency caps | Scheduler service with task registry and expiry | ASI10, ASI08 |
| Payment / financial transactions | Tier 2 | Irreversible financial loss, fraud, unbounded spend, unauthorized transfers | Hard spend caps (per-transaction and cumulative), pre-authorization and human approval above threshold, payee allowlist, no new payee without confirmation, dual control on large amounts, full transaction audit, reversibility window where the rail supports it | Payment gateway with policy and approval engine | ASI02, ASI09 |
Default tier sourcing: the defaults are author-assigned starting points based on reversibility, externality, privilege, and blast-radius logic. Tune them to your own risk appetite before adopting.
Secrets handling: direct secret retrieval should be exceptional. The preferred pattern is broker-mediated use where the agent never sees the raw secret value.
OWASP ASI sourcing: the ASI column is my own cross-walk to the OWASP Top 10 for Agentic Applications 2026 (ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, ASI10 Rogue Agents). OWASP organizes by risk, not by tool, so the tool-to-ASI mapping is mine for traceability, not an official OWASP table.
Cross-Cutting Controls
These apply to every row above. They are factored out here so the matrix does not repeat them sixteen times.
| Control | What it gives you |
|---|---|
| Agent identity | Every agent and tool call carries a distinct non-human identity, so every action is attributable to a principal. Ties directly to ASI03. |
| Centralized audit and provenance | A tamper-evident log of every tool call, its inputs, and the decision that triggered it. Provenance tags travel with data so a poisoned input is traceable to its source. |
| Rate limits and quotas | Per-tool and global caps that bound both cost and blast radius when an agent goes off the rails. |
| Kill switch / circuit breaker | The ability to halt an agent and its children immediately, with auto-trip on anomaly thresholds. |
| Human-in-the-loop tiering | Actions classified by reversibility and impact, with the irreversible and high-impact ones gated behind explicit approval. |
| Blast-radius caps and replay testing | Bound the damage a single run can cause. Replay a window of recorded agent actions in an isolated clone of production before widening any policy, gated on containment thresholds. Treat each policy expansion as a regression test: the replay either passes the blast-radius caps or the expansion does not ship. This is the seam where security policy meets eval-style regression testing. |
| Untrusted-by-default content | Page text, emails, retrieved documents, tool outputs, tool descriptions, and memory reads are data. They never carry instruction authority. This is the single defense that most directly addresses ASI01. |
How to Use This
Assign every tool grant a trust tier, default to Tier 0, and escalate only through approval.
- Tier 0 — observe / read-only. No state change. Lowest gate. Most retrieval and enumeration lives here.
- Tier 1 — scoped write, reversible. Bounded, recoverable changes inside the workspace. Logged, rate-limited, no human gate required.
- Tier 2 — privileged or irreversible. IAM changes, external sends, payments, deletes, new MCP servers, persistent jobs. Always human-approved, always dual-logged.
The Default tier column gives the recommended starting grant for each class. Where it reads "Tier 0 unless X," X is the trigger that escalates the grant and pulls in the matching gate from the Required controls cell. A browser at Tier 0 reads pages. The same browser at Tier 2 may submit a purchase, and only then do the confirmation gate and audit requirements bind.
Escalate when an action is privileged, irreversible, externally visible, persistent, or materially expands blast radius. Externality matters on its own: sending an email, making a purchase, calling an external URL, or posting to a channel can be irreversible even when it changes no internal state.
Escalation triggers
Any of these moves a grant up a tier and pulls in the matching gate:
- State-changing action
- External communication
- New destination or recipient
- New tool or connector
- Persistent job
- IAM or security-policy change
- Destructive action
- Raw secret exposure
- Egress expansion
- Dependency installation outside the vetted mirror
Policy expansion review
Any request to widen a grant should be treated like a production change: state the use case, identify the new trust boundary, replay recent agent actions under the proposed grant, verify the blast-radius caps still hold, and record the approval.
Changelog
v0.3
- Reworded the Default tier sourcing note to a public-facing version (author-assigned starting points based on reversibility, externality, privilege, and blast-radius logic).
- Added a Secrets handling note: direct retrieval is exceptional, broker-mediated use is the default.
- Added externality to the tier logic and an explicit escalation principle.
- Added an Escalation triggers list and a Policy expansion review procedure.
- Readability: Database row now reads "Tier 2 writes or DDL."
v0.2
- Added a Default tier column so each tool class ships with a recommended starting grant.
- Added a Desktop / clipboard / GUI automation row for computer-use and screen-driving agents.
- Added a Package manager / dependency install row to make the supply-chain boundary explicit instead of folding it into code execution.
- Added tool outputs to the instruction / data separation principle and the untrusted-by-default control.
- Wording: "attacker-directed navigation" (browser), "post-approval rug-pull" (MCP), and a stronger eval-regression framing on blast-radius replay testing.
Cite this
Peseckis, L. (2026). Agent Tool Permission Matrix (v0.3). https://github.com/larrypeseckis/agent-tool-permission-matrix
Licensed under CC BY 4.0. Attribution required. Tune the default tiers to your own risk appetite before adopting.
Agent Tool Permission Matrix v0.3. Living document. Cross-walked to OWASP Top 10 for Agentic Applications 2026.