Tool Exposure Risk Assessment Prompt Template

This prompt is for agent platform engineers and AI security architects who need to systematically audit the tools exposed to an AI agent for authorization gaps before an attacker finds them. The job-to-be-done is producing a risk-scored inventory of every tool, its argument surface, confirmation states, and privilege escalation paths. Use this when you are integrating a new tool, reviewing an existing agent's tool manifest, or preparing for a red-team exercise. The ideal user understands the agent's tool definitions, authentication model, and what each tool can do in the production environment.

Do not use this prompt for general system prompt review, user-input injection testing, or RAG pipeline auditing—those require separate playbooks. This prompt assumes you already have a concrete list of tool definitions, schemas, and access policies to feed in as [TOOLS] and [POLICIES]. If you lack structured tool documentation, run an architecture review first. The prompt is designed for single-agent tool surface analysis; multi-agent handoff surfaces require the separate Multi-Agent Attack Surface Mapping Prompt. For high-risk production systems where tool misuse could cause data loss, financial impact, or privilege escalation, always pair the output with human security review and a follow-on red-team test.

Before running this prompt, gather your tool manifest with argument schemas, the agent's system prompt or instruction set, and any existing authorization or confirmation policies. The prompt will produce a structured risk inventory with severity ratings, but it cannot replace runtime testing—use the output to prioritize manual penetration testing and automated fuzzing. If the agent operates in a regulated environment, ensure the assessment is reviewed by a qualified security engineer and documented as audit evidence.

This template is the core engine for a Tool Exposure Risk Assessment. It instructs the model to act as an agent security architect, systematically analyzing a provided list of tool definitions and their execution context. The goal is to produce a structured, risk-scored inventory that highlights missing confirmation steps, overly permissive argument surfaces, and potential privilege escalation paths. Use this prompt when you have a concrete set of tool schemas and need a consistent, repeatable analysis to feed into a security review or automated testing harness.

codeCopy
You are an AI security architect specializing in agent tool authorization. Your task is to perform a rigorous risk assessment on the provided tool definitions and execution context.

**INPUT TOOLS AND CONTEXT**
<Tool Definitions>
[TOOL_DEFINITIONS]
</Tool Definitions>

<Execution Context>
[EXECUTION_CONTEXT]
</Execution Context>

**ASSESSMENT INSTRUCTIONS**
For each tool, analyze the following dimensions and assign a risk score (Low, Medium, High, Critical) with a detailed justification:
1.  **Argument Surface Risk:** Assess the potential for misuse based on the tool's arguments. Consider injection points, lack of input validation, and dangerous default values.
2.  **Confirmation State Risk:** Evaluate whether the tool requires explicit user confirmation before execution. Flag any tool that performs a destructive or data-exfiltrating action without a confirmation step.
3.  **Privilege Escalation Risk:** Analyze whether a successful call to this tool could grant the agent or an attacker higher privileges, access to new tools, or the ability to modify system-level instructions.
4.  **Data Exposure Risk:** Determine the sensitivity of data the tool can access or return. Flag tools that can read secrets, PII, or proprietary business logic.

**OUTPUT FORMAT**
Respond exclusively with a valid JSON object conforming to this schema. Do not include any other text.

[OUTPUT_SCHEMA]

**CONSTRAINTS**
- Base your analysis strictly on the provided definitions and context. Do not invent capabilities.
- If a tool's behavior is ambiguous, flag it as High risk and note the ambiguity in the justification.
- Prioritize authorization bypass paths. A missing confirmation on a destructive action is a Critical finding.

To adapt this template, replace the [TOOL_DEFINITIONS] placeholder with a structured list of your agent's tools, ideally in a format that includes the tool name, description, and a full parameter schema. The [EXECUTION_CONTEXT] placeholder should describe the agent's overall purpose, its system prompt, and the trust level of the data sources it interacts with. The [OUTPUT_SCHEMA] placeholder is critical for integration; replace it with a strict JSON Schema that defines the structure of the risk inventory, ensuring fields like tool_name, risk_score, and findings are typed and required. For high-stakes production systems, always route the generated report for human review before using it to drive automated security policy changes.

The Tool Exposure Risk Assessment prompt is not a one-off query; it is a structured security review step that should be integrated into your agent's pre-deployment checklist and continuous monitoring pipeline. The prompt expects a complete inventory of tool definitions, including their JSON schemas, argument surfaces, and confirmation states. Before calling the model, your harness must assemble this inventory programmatically from your agent's tool registry or OpenAPI specification. The harness should also inject a [RISK_LEVEL] parameter—typically 'high' for production-facing agents with access to mutable data or external APIs—to calibrate the model's severity scoring. Do not rely on manual copy-paste for tool definitions; automation ensures consistency and prevents stale data from skewing the risk assessment.

After the model returns its JSON output, the harness must validate the response against a strict schema before accepting it. At minimum, validate that every tool in the input inventory appears in the output, that each risk score is an integer within the defined range, and that required fields like privilege_escalation_paths and missing_confirmation_checks are present and non-null. For high-risk agents, implement a secondary validation step that cross-references the model's output with a static authorization policy file. If the model flags a tool as missing a confirmation check but your policy engine already enforces one, log a discrepancy for human review. Store every assessment as a versioned artifact in your security logging system, including the full prompt, model response, and validation results, to maintain an audit trail for governance reviews.

This prompt is designed for a single LLM call, but the output should feed into a downstream workflow. Use the authorization_bypass_detected boolean field to trigger an automated ticket in your vulnerability tracker. Route assessments with severity: 'critical' to the security on-call channel. For agent platforms with frequent tool updates, schedule this assessment to run automatically on every tool registry change, treating it like a linter in a CI/CD pipeline. Choose a model with strong reasoning capabilities and low refusal rates for structured security analysis; avoid small or instruction-light models that may hallucinate tool paths or miss subtle escalation chains. If the model returns a refusal or an incomplete JSON object, implement a single retry with a simplified [CONSTRAINTS] block that asks for partial results, then escalate to a human security reviewer if the retry also fails.