Capability Overstatement Prevention Prompt

This prompt is for product teams deploying customer-facing assistants, internal copilots, or tool-augmented agents where the model must accurately represent its limitations. Use it when the cost of a model claiming it can perform an action it cannot execute is high: compliance violations, broken user trust, or unsafe tool invocations. The prompt produces capability declaration rules that bind the model to only claim abilities that match its actual tool access, data scope, and system permissions. It is designed for the system instruction layer and should be combined with runtime overstatement detection evals.

Deploy this prompt when your assistant has a defined, limited set of tools or data sources and users may ask it to perform actions outside that scope. For example, a customer support bot that can look up order status but cannot process refunds must never say 'I can issue that refund for you.' An internal HR copilot that can retrieve policy documents but cannot update employee records must never claim write access. The prompt is also critical for regulated industries where claiming an unlicensed capability—such as providing medical advice or financial recommendations—creates legal exposure. If your system uses retrieval-augmented generation (RAG), the prompt should bind capability claims to the actual knowledge base scope, preventing the model from offering to search databases it cannot access.

Do not use this prompt as a substitute for proper tool authorization at the application layer. The prompt constrains what the model says it can do, but it does not prevent the model from attempting unauthorized tool calls if the tool router does not enforce permissions independently. Always pair this prompt with server-side authorization checks, tool access control lists, and runtime validation of tool call arguments. For low-risk internal prototypes where overstatement has no compliance or trust consequences, a simpler instruction like 'Only use the tools provided' may be sufficient. This prompt becomes essential when the gap between claimed and actual capability carries real cost.

Before implementing, map every capability your system actually possesses—every tool, every data source, every API endpoint, every permission scope. The prompt template requires this inventory as input. If you cannot enumerate your system's actual capabilities, you are not ready to deploy this prompt. Next, identify the highest-risk overstatement scenarios: what would a user ask that the system cannot do, and what would the worst-case claimed capability sound like? These scenarios become your eval cases. Finally, decide whether overstatement detection will run inline during generation or asynchronously as a post-processing guard. Inline detection adds latency but catches overstatements before the user sees them; async detection is faster but requires a correction or retraction mechanism.

This prompt template is designed to be placed in the system instruction layer of your AI application. It defines a strict contract for what the assistant can and cannot claim to do, providing refusal language for out-of-scope requests. The primary goal is to prevent capability overstatement—a common failure mode where models confidently claim abilities, data access, or authority they do not possess, creating compliance, brand, and safety risks in production.

codeCopy
## Capability Boundary Declaration

You are an AI assistant with a strictly defined set of capabilities. You must never claim abilities, access, or authority outside this boundary. When asked to perform an action or provide information beyond your scope, you must refuse clearly and constructively.

### Declared Capabilities
[CAPABILITY_LIST]

### Explicit Limitations
- You do not have access to [RESTRICTED_SYSTEMS_OR_DATA]
- You cannot perform [FORBIDDEN_ACTIONS]
- You are not authorized to [UNAUTHORIZED_COMMITMENTS]
- You do not possess [NONEXISTENT_KNOWLEDGE_OR_ABILITIES]

### Refusal Protocol
When a request falls outside your declared capabilities, respond with:
"I don't have the ability to [requested action]. I can help you with [nearest valid alternative] instead. Would you like me to proceed with that?"

### Overstatement Prevention Rules
1. Never use phrases like "I can definitely," "I have access to," or "I am able to" unless the capability is explicitly listed in [CAPABILITY_LIST]
2. When uncertain about your scope, default to refusal with an alternative suggestion
3. Never invent capabilities to satisfy a user request
4. If asked "Can you do X?" and X is not in [CAPABILITY_LIST], respond: "That's outside my current capabilities. I can [closest match] if that helps."
5. Never claim to have real-time data, personal knowledge, or system access unless explicitly granted in [CAPABILITY_LIST]

### Examples of Correct Refusal
User: "Can you access my account and check my balance?"
Assistant: "I don't have the ability to access your account or check your balance. I can help you understand how to check it yourself or explain account-related concepts. Would you like me to proceed with that?"

User: "Can you approve this purchase order?"
Assistant: "I'm not authorized to approve purchase orders. I can help you draft the approval request or review the order details for completeness. Would either of those help?"

To adapt this template, replace the square-bracket placeholders with your specific constraints. [CAPABILITY_LIST] should contain an exhaustive, positive list of what the assistant can do—not just what it cannot. [RESTRICTED_SYSTEMS_OR_DATA] should name specific internal systems, databases, or data categories. [FORBIDDEN_ACTIONS] should list concrete operations like 'delete records,' 'approve transactions,' or 'access PII.' [UNAUTHORIZED_COMMITMENTS] covers promises the model shouldn't make, such as 'guaranteeing outcomes' or 'committing company resources.' [NONEXISTENT_KNOWLEDGE_OR_ABILITIES] should explicitly deny capabilities users might assume, like 'real-time market data' or 'medical diagnosis.' The refusal language is designed to be brand-safe and constructive—it declines the request while offering a valid alternative, preventing dead-end interactions that frustrate users. Before deploying, test this template against adversarial inputs that attempt to extract capability claims, and verify that the model never volunteers abilities outside [CAPABILITY_LIST] even under pressure.

This prompt is not a one-off check; it's a guardrail that should run before any model-generated response is shown to a user or passed to a downstream system. The implementation harness wraps the model call, intercepts the output, and runs the overstatement detection eval before the response leaves your application boundary. The core pattern is: generate a draft response, run the capability declaration rules against it, and either pass the response, rewrite it, or escalate based on the detection result.

Start by integrating the prompt as a post-generation filter. After your primary model produces a response, send the response text and the original system role definition to this prompt. The prompt returns a structured JSON object with an overstatement_detected boolean, a violations array listing specific overstatements, and a corrected_response string. In your application code, check overstatement_detected. If false, forward the original response. If true, log the violation details and decide whether to use the corrected response, trigger a retry with the primary model using the violation feedback as additional constraints, or escalate to a human reviewer. For high-risk domains like healthcare or finance, always require human review when overstatement is detected rather than auto-correcting.

Model choice matters here. Use a fast, instruction-following model for this guardrail check—GPT-4o-mini, Claude Haiku, or a fine-tuned small model work well—to keep latency low. The guardrail model should be different from your primary generation model to avoid correlated failures. Implement a retry loop with a maximum of two attempts: if the guardrail detects overstatement, feed the violations back to the primary model with an instruction like 'Revise the response to eliminate the following overstatements: [violations]'. If the second attempt still fails, escalate. Log every guardrail invocation with the original response, the detection result, the violations found, and the disposition (passed, auto-corrected, retried, escalated). These logs become your overstatement audit trail and feed into eval improvement cycles.

For agent workflows, insert this guardrail at every external communication point—before the agent speaks to a user, before it calls an API with self-described capabilities, and before it writes to a shared context that other agents will read. In multi-agent systems, each agent should have its own capability declaration rules scoped to its actual tool access and permissions. Wire the guardrail into your agent framework's response pipeline, not as an optional add-on. If an agent claims it can perform an action it doesn't have a tool for, the guardrail should block the claim and trigger a capability re-grounding step where the agent re-reads its available tools before responding again.