← Domains & pillars

SecurityView domain

APRF-05

Tool Safety

Make tool/MCP invocation fail closed with least privilege and side-effect control.

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.

  • TOL-M1L3 · DefinedTier 2 · ProductionhybridE3

    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 map

    Ensure tool execution authority comes from server-side policy, never from model output.

    Threats mitigated

    Prompt InjectionUnauthorized Tool UsePrivilege EscalationExcessive AgencyTool Abuse

    Protects

    ToolsExternal SystemsDataIdentityRuntime

    MITRE: 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.

  • TOL-M2L3 · DefinedTier 2 · ProductionhybridE3

    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 map

    Restrict each agent to a fixed, approved set of tools it cannot expand at runtime.

    Threats mitigated

    Unauthorized Tool UseTool AbuseExcessive AgencySupply Chain Compromise

    Protects

    ToolsExternal SystemsRuntime

    MITRE: 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.

  • TOL-M3L3 · DefinedTier 2 · ProductionhybridE3

    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 map

    Require an additional gate before high-impact tools are permitted to execute.

    Threats mitigated

    Excessive AgencyTool AbuseHallucinated ActionsPrompt Injection

    Protects

    ToolsExternal SystemsDataSafety

    MITRE: 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.

  • TOL-M4L3 · DefinedTier 2 · ProductionhybridE3

    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 map

    Prevent unvalidated model-generated arguments from reaching an executor.

    Threats mitigated

    Unsafe Code ExecutionPrompt InjectionTool AbusePrivilege Escalation

    Protects

    ToolsExternal SystemsRuntimeInfrastructure

    MITRE: 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.

  • TOL-M5L5 · OptimizingTier 3 · Mission CriticalhybridE3

    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 map

    Ensure tool catalog definitions are authentic and unchanged since they were reviewed.

    Threats mitigated

    Supply Chain CompromisePrompt InjectionTool AbuseUnauthorized Tool Use

    Protects

    ToolsExternal SystemsRuntime

    MITRE: 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
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 mappingsexpand
  • 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.