Purpose
Ensure every tool, function call, MCP server, and external action invoked by a model is authorized, scoped, observable, and reversible or gated when impact is high.
Mandatory checks
Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.
Every production tool invocation shall be authorized server-side by an independent authz decision—proven by coverage of production tool-invocation paths plus automated deny tests at 100%, not by prompt instructions, client-side checks, or model-proposed tool name/args alone.
- Artifact
- Inventory or mapping of production tool-invocation paths (or attested gateway covering 100%); Tool gateway / tool-runtime authz enforcement config (server-side)
- Pass condition
- 100% of production tool-invocation paths are covered by server-side tool authz (gateway or runtime); automated tests show tool calls without a valid authz decision are denied at 100%; model-proposed tool name/args alone never bypass the gateway/runtime (measuredAt ≤90 days). If no production agents/workloads invoke tools, score NOT_APPLICABLE.
Why this control exists
Threat mapEnsure tool execution authority comes from server-side policy, never from model output.
Threats mitigated
Prompt InjectionUnauthorized Tool UsePrivilege EscalationExcessive AgencyTool AbuseProtects
ToolsExternal SystemsDataIdentityRuntimeMITRE: ATLAS AML.T0053 · ATLAS AML.T0051 · ATLAS AML.T0051.001 · ATLAS AML.T0086 · ATLAS AML.T0101 · ATT&CK T1078
Prompt injection becomes real-world impact at the exact moment a tool call is executed on the model's say-so. Independent server-side authorization at that boundary is the single most effective break in the injection-to-impact chain.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production agents and workloads shall have an explicit tool allowlist, and unknown or model-invented tool names shall be rejected at runtime—proven by an inventory of production agents that can invoke tools, 100% allowlist coverage, automated unknown-tool deny tests, and runtime rejection of invented names—not by open MCP "all tools" bindings, prompt-only restrictions, or a deny suite that covers only a subset of agents.
- Artifact
- Inventory of production agents/workloads that can invoke tools; Per-agent/workload tool allowlist configuration covering 100% of those agents
- Pass condition
- Inventory covers 100% of production agents/workloads that can invoke tools; each has an explicit tool allowlist; automated tests deny unknown-tool requests at 100%; unknown or model-invented tool names are rejected at runtime (measuredAt ≤90 days). If no production agents/workloads invoke tools, score NOT_APPLICABLE.
Why this control exists
Threat mapRestrict each agent to a fixed, approved set of tools it cannot expand at runtime.
Threats mitigated
Unauthorized Tool UseTool AbuseExcessive AgencySupply Chain CompromiseProtects
ToolsExternal SystemsRuntimeMITRE: ATLAS AML.T0053 · ATLAS AML.T0010.005 · ATLAS AML.T0110
An agent that can discover or synthesize new tools at runtime has an unbounded capability surface that no review has seen. A per-workload allowlist keeps capability fixed and reviewable, and stops a poisoned or newly advertised tool from being adopted mid-run.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Tools rated write, irreversible, or financial shall require an additional gate beyond base tool authz/allowlist—human approval, dual control, or a policy engine—proven by a complete impact-tiered inventory of production high-impact tools, 100% gate coverage, and automated tests that ungated execution is impossible—not by prompt "ask a human" text, base allowlists, or a bypass suite that covers only a subset of high-impact tools.
- Artifact
- Impact-tiered tool inventory marking write/irreversible/financial tools in production; Gate configuration (approval, dual control, or policy engine) for 100% of those tools
- Pass condition
- Impact-tiered inventory covers 100% of production write/irreversible/financial tools; 100% of those tools have a configured additional gate (approval, dual control, or policy engine); automated tests show ungated execution is impossible for those tools (measuredAt ≤90 days). If no write/irreversible/financial tools exist in production, score NOT_APPLICABLE.
Why this control exists
Threat mapRequire an additional gate before high-impact tools are permitted to execute.
Threats mitigated
Excessive AgencyTool AbuseHallucinated ActionsPrompt InjectionProtects
ToolsExternal SystemsDataSafetyMITRE: ATLAS AML.T0101 · ATLAS AML.T0053 · ATLAS AML.T0086 · ATLAS AML.T0048 · ATT&CK T1485
Destructive and irreversible tools warrant a stronger control than the routine authorization applied to every call. Approval, dual control, or a policy engine ensures a single manipulated invocation cannot cause unrecoverable damage or bulk exfiltration.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production tools shall declare argument schemas and reject invalid or malicious payloads before side effects—proven by an inventory of production tools, 100% schema coverage, and contract tests at 100% rejection—not by prompt-only "follow the schema" instructions, customer-API OpenAPI alone, or a reject suite that covers only a subset of tools.
- Artifact
- Inventory of production tools that accept arguments; JSON Schema (or equivalent) per inventoried production tool
- Pass condition
- Inventory covers 100% of production tools; each has a declared argument schema; invalid/malicious argument fixtures are rejected at 100% before side effects (measuredAt ≤90 days). If no production tools exist, score NOT_APPLICABLE.
Why this control exists
Threat mapPrevent unvalidated model-generated arguments from reaching an executor.
Threats mitigated
Unsafe Code ExecutionPrompt InjectionTool AbusePrivilege EscalationProtects
ToolsExternal SystemsRuntimeInfrastructureMITRE: ATLAS AML.T0102 · ATLAS AML.T0050 · ATLAS AML.T0051 · ATLAS AML.T0072 · ATT&CK T1059
Model-generated arguments are untrusted input, and passing them unchecked to shells, queries, or APIs reproduces classic injection flaws with a new source. Schema validation and sanitization stop generated malicious commands from reaching an interpreter.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production MCP and agent tool catalogs shall be signed (or equivalently integrity-verified) and supply-chain reviewed before use—proven by an inventory of production catalogs, verify-on-load that rejects unsigned/unapproved catalogs on 100% of load paths, plus a review ≤90 days or since last catalog change—not by SCI-M2 inventory pins alone or a reject config that covers only a subset of catalog loaders.
- Artifact
- Inventory of production MCP/agent tool catalogs; Signed (or integrity-verified) catalogs + verify-on-load / reject-unsigned for catalog consumers
- Pass condition
- Inventory covers 100% of production MCP/agent tool catalogs; catalog loaders reject unsigned or unapproved catalogs; last supply-chain review is ≤90 days or since the last catalog change (measuredAt ≤90 days). If no production MCP/agent tool catalogs are loaded, score NOT_APPLICABLE. (Level-5 / regulated advanced scope.)
Why this control exists
Threat mapEnsure tool catalog definitions are authentic and unchanged since they were reviewed.
Threats mitigated
Supply Chain CompromisePrompt InjectionTool AbuseUnauthorized Tool UseProtects
ToolsExternal SystemsRuntimeMITRE: ATLAS AML.T0110 · ATLAS AML.T0104 · ATLAS AML.T0010.005 · ATLAS AML.T0011.002 · ATLAS AML.T0109 · ATT&CK T1195
Tool descriptions are read directly into the model's context, which makes a modified catalog both a supply-chain compromise and a prompt-injection vector. Signing and reviewing catalogs detects silent redefinition of a tool after it was approved.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Evidence required
- Tool inventory with owners, scopes, and impact ratings
- Authorization policy examples
- Logs of denied tool invocations
Recommended checks
Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.
Destructive tools should expose dry-run or simulation in non-production environments, and the last promotion of a destructive tool should include a dry-run evidence link ≤90 days old—proven by an inventory of destructive tools, 100% dry-run coverage in non-prod, and promotion linkage—not by prompt-only "dry-run" flags, production confirmation dialogs, or promotion evidence without a complete destructive-tool inventory.
- Artifact
- Inventory/catalog of destructive tools marking dry-run/simulation support; Sample lower-env dry-run logs or promotion evidence links ≤90 days
- Pass condition
- Inventory covers 100% of tools classified destructive; each exposes dry-run or simulation in non-prod; the last promotion of a destructive tool includes a dry-run evidence link ≤90 days old (measuredAt ≤90 days). If no destructive tools exist, score NOT_APPLICABLE.
Why this control exists
Threat mapLet destructive tool behaviour be validated without producing irreversible effects.
Threats mitigated
Excessive AgencyHallucinated ActionsTool AbuseProtects
External SystemsDataSafetyMITRE: ATLAS AML.T0101
Dry-run and simulation modes let an agent's destructive paths be exercised where mistakes are recoverable. This reduces the chance that a defect or manipulated invocation first manifests against production data.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
High-impact tools should have documented QPS/daily caps and max-affected-entities budgets, with ≥1 limit hit or synthetic enforcement test in the last 30 days—proven by an inventory of high-impact tools, 100% rate+blast budget coverage, and ≤30d enforcement proof—not by global API gateway limits alone, docs without enforcement, or budgets that cover only a subset of high-impact tools.
- Artifact
- Inventory of high-impact tools requiring rate and blast-radius budgets; Per-tool rate-limit and blast-radius policy config for those tools
- Pass condition
- Inventory covers 100% of high-impact tools; each has a documented QPS or daily cap and a max-affected-entities (or equivalent) blast-radius budget; ≥1 limit hit or synthetic test proves enforcement in the last 30 days (measuredAt ≤90 days). If no high-impact tools exist, score NOT_APPLICABLE.
Why this control exists
Threat mapBound how much damage a single agent or tool can do within a given window.
Threats mitigated
Tool AbuseExcessive AgencyData ExfiltrationDenial of WalletDenial of ServiceProtects
ToolsExternal SystemsDataCostAvailabilityMITRE: ATLAS AML.T0034.002 · ATLAS AML.T0086 · ATLAS AML.T0101
Rate and blast-radius budgets cap the volume of actions available to a hijacked agent before a human can intervene. They limit bulk exfiltration and mass destructive operations even when each individual authorization check legitimately passes.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution
Engineering philosophy
The model proposes; the platform disposes. Tools are privileged APIs. Never let natural language become an unrestricted remote control over production systems.
Why it matters
Tool misuse converts language model errors into real-world damage—deleted data, fraudulent transactions, leaked secrets, or lateral movement through MCP and A2A bridges.
Common failures
- Tools run with service-wide credentials instead of user-scoped tokens
- No allowlist of tools per agent or environment
- Destructive tools without confirmation or dry-run modes
- MCP servers exposed without authentication
Severity & risk
- Severity
- critical
- Impact if violated
- Risk level
- critical
- Typical residual risk (impact × likelihood)
Engineering best practices
- Map each tool to an impact tier (read, write, irreversible, financial)
- Pass user identity into tools; avoid god-mode service accounts where possible
- Return structured errors; do not leak internal stack traces into the model context
- Treat MCP and A2A endpoints as public-facing APIs with the same hardening
Automatic validations
- Contract tests for tool schemas
- Policy-as-code denying unauthorized tool calls
- CI scanning for overly broad tool permissions
Manual validations
- Impact rating review for new tools before production
- Penetration testing focused on tool and MCP surfaces
Examples
- A coding agent can run tests but cannot push to main without human approval
- An MCP file server exposes only a workspace directory, not the host filesystem
References
Crosswalks
Show 31 peer mappingsexpandcollapse
MANAGE Manage
NIST AI Risk Management Framework · supports
Secure & Resilient Secure and Resilient
NIST AI Risk Management Framework · aligns-with
§8 Operation
ISO/IEC 42001 · supports
LLM01 Prompt Injection
OWASP Top 10 for Large Language Model Applications · supports
LLM05 Improper Output Handling
OWASP Top 10 for Large Language Model Applications · supports
LLM06 Excessive Agency
OWASP Top 10 for Large Language Model Applications · supports
C2.1 Prompt Injection Defenses
OWASP AI Application Security Verification Standard (AISVS) · supports
C7.1 Output Format Enforcement
OWASP AI Application Security Verification Standard (AISVS) · supports
C7.2 Hallucination Detection & Mitigation
OWASP AI Application Security Verification Standard (AISVS) · supports
C7.3 Output Safety
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.1 Execution Budgets, Loop Control, and Circuit Breakers
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.2 High-Impact Action Approval and Irreversibility Controls
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.3 Component Isolation and Tool Authorization
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.4 Agent and Orchestrator Identity
OWASP AI Application Security Verification Standard (AISVS) · partial
C9.5 Agent Authorization, Delegation, and Continuous Enforcement
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.6 Shutdown and Graceful Degradation
OWASP AI Application Security Verification Standard (AISVS) · supports
C10.1 Component Integrity
OWASP AI Application Security Verification Standard (AISVS) · partial
C10.2 Authentication & Authorization
OWASP AI Application Security Verification Standard (AISVS) · partial
C10.3 Secure Transport
OWASP AI Application Security Verification Standard (AISVS) · partial
C10.4 Schema, Message, and Input Validation
OWASP AI Application Security Verification Standard (AISVS) · partial
C11.1 Model Alignment, Safety, and Robustness Testing and Training
OWASP AI Application Security Verification Standard (AISVS) · supports
C11.4 Model Runtime Anomaly Detection
OWASP AI Application Security Verification Standard (AISVS) · supports
CWE-22 Path Traversal
OpenCRE (Open Common Requirements Enumeration) · partial
CWE-502 Deserialization of Untrusted Data
OpenCRE (Open Common Requirements Enumeration) · partial
CWE-78 OS Command Injection
OpenCRE (Open Common Requirements Enumeration) · aligns-with
CWE-79 Cross-site Scripting (XSS)
OpenCRE (Open Common Requirements Enumeration) · partial
CWE-89 SQL Injection
OpenCRE (Open Common Requirements Enumeration) · partial
L3 Agent Frameworks
CSA MAESTRO (Multi-Agentic Threat Model) · supports
heterogeneous-multi-agent-exploits Heterogeneous Multi-Agent Exploits
CSA MAESTRO (Multi-Agentic Threat Model) · aligns-with
CC5 Control Activities
SOC 2 Trust Services Criteria · evidence-for
Security Security
AWS Well-Architected Framework · aligns-with
Future evolution
Standardized tool impact taxonomies and portable capability tokens for agent tool use.