Tool Contract Read-Only vs Mutating Operation Tag Prompt

This prompt is for security engineers and platform operators who need to classify every operation in a tool contract as read-only, side-effect, or destructive before an agent is allowed to invoke it. The job-to-be-done is safety gating: you have a tool schema—likely from an OpenAPI spec, an MCP server, or an internal service definition—and you need a machine-readable tag on each operation so your agent runtime can enforce confirmation rules, require human approval, or block calls entirely based on risk level. The ideal user is someone integrating a new tool into a production agent system where a misclassified DELETE or a silent POST that mutates state could cause data loss, compliance violations, or customer impact.

Do not use this prompt when you need runtime argument-level analysis (e.g., 'this specific call would delete 10,000 records'). This prompt classifies operations by their declared contract, not by the blast radius of a particular invocation. Do not use it for tools where the schema is so ambiguous that even a human reviewer cannot determine side effects from the description alone—garbage descriptions produce garbage tags. This prompt also does not replace a full threat model; it is one layer in a defense-in-depth strategy that should include argument validation, output sanitization, and human-in-the-loop approval for destructive actions. If your tool contract uses non-standard HTTP methods or custom RPC verbs, you must include those in the [CUSTOM_VERB_RULES] section of the prompt or the model will default to conservative classification, which may over-block legitimate operations.

Before running this prompt, ensure you have the complete tool contract with operation IDs, HTTP methods, path patterns, and natural-language descriptions. The output is a structured tag per operation, not a narrative summary. Wire the output into your agent's tool selection layer so that read-only operations proceed without friction, side-effect operations trigger a confirmation or logging step, and destructive operations require explicit human approval. If your agent framework does not support per-operation gating, start by implementing it for destructive tags first—that alone prevents the highest-severity incidents. After classification, spot-check at least 10% of operations manually, focusing on any operation where the model's confidence score falls below 0.9 or where the description contains words like 'update,' 'modify,' or 'remove' without clarifying scope.

This prompt template is designed to be dropped into a security review pipeline where every tool operation must be classified before an agent is allowed to invoke it. The prompt takes a tool contract as input and returns a structured operation tag with a mutability classification, a risk level, and a rationale. The output is intended to be consumed by an agent safety gate that enforces approval workflows for destructive or side-effect operations. Use this prompt when you need consistent, auditable operation classification across a heterogeneous tool ecosystem.

textCopy
You are a tool safety classifier. Your job is to analyze a tool operation and classify it by mutation risk.

## INPUT
Tool Name: [TOOL_NAME]
Operation: [OPERATION_NAME]
Description: [OPERATION_DESCRIPTION]
Arguments: [ARGUMENTS]
HTTP Method: [HTTP_METHOD]
Path: [PATH]

## CLASSIFICATION RULES
1. **read-only**: The operation does not create, update, or delete any resource. It only retrieves data. Safe to call without approval.
2. **side-effect**: The operation creates or updates resources but is reversible or low-risk (e.g., creating a log entry, updating a status field). May require logging but not always human approval.
3. **destructive**: The operation deletes resources, modifies critical configuration, triggers financial transactions, or exposes sensitive data. Always requires human approval.

## OUTPUT SCHEMA
Return a JSON object with these fields:
- `operation_tag`: "read-only" | "side-effect" | "destructive"
- `risk_level`: "low" | "medium" | "high" | "critical"
- `requires_approval`: boolean
- `rationale`: string explaining the classification with specific evidence from the operation description
- `concerns`: array of strings listing specific risks (empty array if none)

## CONSTRAINTS
- If the operation description is ambiguous, default to the higher-risk classification.
- If the HTTP method is DELETE, the operation is at minimum "side-effect" and likely "destructive".
- If the operation accesses PII, credentials, or financial data, flag it in `concerns`.
- Do not invent information not present in the input.

## EXAMPLES
Input: Tool "user-service", Operation "getUser", GET /users/{id}, returns user profile
Output: {"operation_tag": "read-only", "risk_level": "low", "requires_approval": false, "rationale": "GET request that retrieves data without modification", "concerns": ["Returns PII if user profile includes email or phone"]}

Input: Tool "billing-service", Operation "chargeCustomer", POST /charges, creates a payment
Output: {"operation_tag": "destructive", "risk_level": "critical", "requires_approval": true, "rationale": "Initiates financial transaction that cannot be automatically reversed", "concerns": ["Financial impact", "Irreversible without refund process"]}

Now classify the operation described in the INPUT section.

Adapt this template by replacing the placeholder values with your actual tool metadata. The [ARGUMENTS] placeholder should include the full argument schema with types and descriptions, as argument sensitivity often drives classification. If your approval workflow has more granular levels, extend the operation_tag enum and adjust the requires_approval logic accordingly. For production use, pair this prompt with a validation step that checks the output JSON against the declared schema before the safety gate consumes it. If the model returns an unrecognized tag or missing required fields, reject the classification and retry with a more explicit error message rather than defaulting to a permissive setting.

This prompt is not a standalone classifier; it is a safety gate that must be wired into your agent's tool execution pipeline. The harness should intercept every tool call before execution, classify the operation using this prompt, and enforce a policy based on the returned tag. A read-only tag allows immediate execution. A side-effect tag should trigger a confirmation step or log the operation for audit. A destructive tag must halt execution and require explicit human approval. The harness must never execute a tool call that returns an invalid or missing tag—treat that as a destructive operation by default to fail closed.

Implement the harness as a pre-execution middleware in your agent framework. For each tool call, construct the prompt by injecting the tool's full contract—name, description, argument schema, and the specific arguments the agent intends to pass—into the [TOOL_CONTRACT] placeholder. Use a fast, inexpensive model (such as GPT-4o-mini or Claude Haiku) for classification to keep latency low. Set temperature=0 and enforce a structured output mode that returns a JSON object with exactly the operation_tag field. Validate the response immediately: if the tag is not one of read-only, side-effect, or destructive, or if the JSON is malformed, retry once. If the retry also fails, escalate to a human operator and block the tool call. Log every classification decision with the tool name, arguments, tag, model used, and timestamp for auditability.

For high-throughput systems, cache classification results by a hash of the tool name and argument schema (not the argument values, since those change per call). A tool's contract rarely changes, so re-classifying the same tool on every invocation is wasteful. Invalidate the cache when the tool schema version increments. For tools with dynamic behavior where the same tool can be read-only or mutating depending on arguments (e.g., an HTTP client that can GET or DELETE based on the method argument), do not cache—classify every call with the full argument context. Wire the harness to emit structured logs and metrics: count classifications by tag, track retry rates, and alert if the destructive tag rate spikes unexpectedly, which may indicate a prompt regression or an agent attempting unauthorized mutations.