Capability Self-Report Limiter Prompt

This prompt is for product teams shipping customer-facing AI agents that must never promise features they cannot execute. The core job-to-be-done is preventing capability hallucination—where a model confidently tells a user 'I can do that for you' and then fails because the underlying tool, API, or permission isn't actually wired up. This is a trust-and-safety problem, not a politeness problem. The ideal user is an AI engineer or platform developer who controls the system prompt and needs a reusable instruction block that constrains the model's self-reported capabilities to match the exact set of deployed tools and permissions.

Use this prompt when your agent has a defined tool set or action surface and you need the model to accurately describe its own boundaries in conversation. It is most effective when combined with a structured capability manifest—a machine-readable list of what the agent can actually do. The prompt works by instructing the model to consult that manifest before making any capability claim, to refuse requests outside scope with a specific refusal pattern, and to never invent capabilities based on general world knowledge. Do not use this prompt if your agent has no tool access and is purely conversational, or if you need the model to creatively suggest workarounds that might imply unbuilt features. It is also insufficient as a standalone security control—this prompt shapes self-reported behavior, but actual tool access must still be enforced at the gateway or middleware layer.

Before deploying, pair this prompt with a capability over-claim detection eval: feed the agent questions like 'Can you export this to PDF?' or 'Can you access the customer database directly?' and verify it responds with a capability denial rather than a confident but false 'yes.' If your agent's tool set changes during a session (dynamic tool registration or permission revocation), you must update the capability manifest in the prompt context or the model will continue reporting stale capabilities. Start with a narrow allowlist and expand it only after testing each new capability's self-report behavior.

This prompt template is designed to be placed in the system instructions of a customer-facing agent. Its primary job is to force the model to introspect its actual tool and data access before describing what it can do for a user. Without this constraint, models frequently hallucinate capabilities—claiming to send emails, access databases, or perform actions that exist only in their training data, not in the deployed environment. The template uses a strict 'deny-by-default' posture: the model must only claim capabilities explicitly listed in the [PERMITTED_CAPABILITIES] block and must actively refuse to speculate about unlisted features.

textCopy
You are a customer-facing assistant. Your primary directive is to accurately represent your capabilities. You must never claim you can perform an action unless it is explicitly listed in your permitted capabilities below.

## PERMITTED_CAPABILITIES
[PERMITTED_CAPABILITIES]

## CAPABILITY DECLARATION RULES
1.  **Strict Allowlist:** You can ONLY perform actions described in the PERMITTED_CAPABILITIES block. If a user asks for something not listed, you must state clearly that you cannot perform that action.
2.  **No Speculation:** Do not guess, infer, or suggest you might have a capability. If it is not in the list, you do not have it.
3.  **Refusal Format:** When refusing a request for an unlisted capability, use the following format: "I don't have the ability to [requested action]. I can help you with [suggest 1-2 relevant permitted capabilities if applicable, otherwise state 'other topics']."
4.  **Tool-Output Grounding:** If a tool call fails with a permission error, you must report the failure accurately and not re-attempt the action or claim it succeeded.
5.  **Dynamic Updates:** If the [PERMITTED_CAPABILITIES] block is updated mid-session, you must immediately adopt the new scope and forget the previous one.

## CURRENT USER QUERY
[USER_INPUT]

To adapt this template, replace the [PERMITTED_CAPABILITIES] placeholder with a concrete, bulleted list of actions your agent can actually perform. For example: - Look up order status by order ID. - Provide shipping timelines for in-stock items. - Cancel an order that is still processing. Avoid vague terms like 'assist with orders.' The [USER_INPUT] placeholder should be dynamically populated with the latest user message at inference time. For high-risk domains, add a [RISK_LEVEL] variable that triggers an additional instruction to remind the user that a human review is required for certain actions, even if they are permitted.

The Capability Self-Report Limiter is not a standalone prompt; it is a contract layer that sits between your application's actual permission system and the model's response generation. In production, you must treat the model's self-reported capabilities as untrusted output that requires verification against a source-of-truth permission manifest. The implementation harness should extract the model's capability claims from its response, compare them to the deployed tool and data access configuration, and either pass the response through, flag a discrepancy for review, or trigger a corrective re-prompt. This is especially critical in customer-facing agents where an over-claim—such as 'I can delete your account' when the agent lacks that tool—creates immediate trust and compliance risk.

A robust harness begins with a structured output contract. Require the model to emit its capability claims in a parseable schema, such as a JSON object with can_do and cannot_do arrays of action descriptors. On the application side, maintain a canonical permission manifest—derived from your actual tool allowlists, API scopes, and data access policies—and run a post-generation validator that diffs the model's claims against the manifest. Any action the model claims it can perform but is absent from the allowlist is an over-claim; any action the model denies but is present in the allowlist is an under-claim. Both are failures. Log the diff with the session ID, prompt version, and model identifier for traceability. For high-risk domains, route over-claims to a human review queue before the response reaches the user. For lower-risk applications, you can implement an automatic retry loop: feed the validator's diff back into the model with a correction instruction such as 'You previously claimed you could [ACTION]. This is incorrect. Update your capability declaration to match the following allowlist.' Set a maximum of two retries before escalating to a fallback response that explicitly states the agent's limitations from the canonical manifest, bypassing model generation entirely.

Model choice matters here. Smaller or older models are more prone to hallucinating capabilities, especially when user input implies a feature the model has seen in training data. If you observe over-claim rates above your threshold, consider routing capability-declaration responses through a more capable model or adding few-shot examples of correct denials to the prompt. Do not rely on the prompt alone as a security boundary—the validator must be an application-layer control that cannot be bypassed by prompt injection or model error. The next step after implementing this harness is to build a regression test suite: a set of user inputs designed to probe capability boundaries, paired with expected allowlist diffs, that runs in your CI pipeline whenever the prompt or permission manifest changes.