Capability Declaration for Regulatory Compliance

Use this prompt when you are deploying an AI agent in a regulated industry—such as financial services, healthcare, or legal—and the agent must produce a formal, auditable statement of its own capabilities, limitations, and data-handling boundaries. The primary job-to-be-done is generating a compliance artifact that accurately reflects the agent's actual tool permissions, human-review requirements, and operational constraints, so that auditors, regulators, and internal governance teams can verify that the system does not over-promise or misrepresent its scope. The ideal user is a compliance engineer, AI platform architect, or product lead who already has a concrete permission specification and needs to translate it into a structured, human-readable declaration that survives external scrutiny.

This prompt is not a substitute for a legal review or a formal regulatory filing. It assumes you already know which tools, data stores, and actions the agent is permitted to use, and that you have defined deny lists, human-in-the-loop gates, and data classification boundaries. Do not use this prompt to generate a capability declaration from scratch without a source permission manifest; the model will hallucinate plausible but incorrect boundaries. Do not use it for consumer-facing feature descriptions where marketing language and aspirational capabilities might creep in. The output is designed for internal compliance review, audit evidence packages, and governance documentation, not for end-user help centers.

Before using this prompt, gather your source materials: the agent's system prompt, tool allowlist or deny list, MCP server configurations, human-approval escalation rules, data classification labels, and any existing regulatory requirements that apply to automated decision-making in your domain. Wire the prompt into a pipeline that validates the output against the source permission manifest using a structured diff check—if the declaration claims a capability not present in the manifest, or omits a documented limitation, flag it for human review. For high-risk domains, always require a qualified human to sign off on the final declaration before it enters an audit package or regulatory submission. If you only need a quick internal alignment doc, a simpler capability summary prompt without the compliance structure will be faster and cheaper.

This template produces a structured capability declaration for an AI agent operating in a regulated industry. It forces the model to accurately represent its own permissions, tools, and limitations in a format suitable for auditor review and user-facing documentation. The prompt is designed to prevent capability over-claiming—one of the most common compliance failures in production agents—by binding the declaration to the actual permission scope rather than the model's general knowledge of what it could theoretically do.

textCopy
You are an AI agent operating under a strict permission scope for a regulated environment. Your task is to generate a compliance-ready capability declaration that accurately describes what you can and cannot do, based solely on the permissions, tools, and constraints provided below. Do not infer, assume, or extrapolate capabilities beyond what is explicitly declared in your permission scope.

## PERMISSION SCOPE
[PERMISSION_SCOPE]

## TOOL MANIFEST
[TOOL_MANIFEST]

## REGULATORY CONTEXT
[REGULATORY_CONTEXT]

## OUTPUT SCHEMA
Generate a JSON object with the following structure:
{
  "agent_id": "string",
  "declaration_version": "string",
  "generated_at": "ISO8601 timestamp",
  "capabilities": {
    "allowed_actions": [
      {
        "action": "string (specific action name)",
        "tool": "string (tool used, or null if no tool)",
        "data_scope": "string (what data this action can access)",
        "constraints": ["string (specific limits on this action)"],
        "requires_human_approval": boolean
      }
    ],
    "explicitly_denied_actions": [
      {
        "action": "string",
        "denial_reason": "string (reference to policy or scope limitation)",
        "alternative_if_any": "string or null"
      }
    ]
  },
  "data_handling": {
    "data_categories_accessed": ["string"],
    "data_retention_policy": "string",
    "data_sharing_boundaries": "string",
    "encryption_requirements": "string"
  },
  "human_review_requirements": {
    "actions_requiring_review": ["string"],
    "review_trigger_conditions": "string",
    "review_workflow_description": "string"
  },
  "limitations": {
    "cannot_perform": ["string (actions outside scope)"],
    "uncertainty_triggers": ["string (conditions where the agent must escalate)"],
    "model_self_awareness_note": "string (explicit statement that the agent cannot promise capabilities beyond this declaration)"
  },
  "compliance_notes": {
    "regulatory_frameworks_relevant": ["string"],
    "audit_trail_commitment": "string",
    "declaration_review_cadence": "string"
  }
}

## CONSTRAINTS
- Every allowed action must map to a tool or permission explicitly listed in the TOOL MANIFEST or PERMISSION SCOPE.
- If an action is not explicitly permitted, it must appear in explicitly_denied_actions.
- Do not invent capabilities, tools, or data access that are not in the provided scope.
- If the PERMISSION SCOPE or TOOL MANIFEST is empty or missing, declare zero capabilities and note the absence.
- Use precise, auditable language. Avoid vague terms like "appropriate" or "as needed."
- If [REGULATORY_CONTEXT] specifies a framework (e.g., HIPAA, GDPR, SOC 2), ensure the declaration addresses relevant requirements.
- The model_self_awareness_note must explicitly state that this declaration is the authoritative capability boundary and supersedes any general knowledge the model may have.

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

Adapt this template by replacing each square-bracket placeholder with concrete values from your agent's actual configuration. The PERMISSION_SCOPE should come directly from your role-based access control system, not from a human-written summary. The TOOL_MANIFEST should be the machine-readable tool definitions your agent actually uses—ideally extracted from your MCP server or function registry. For high-risk deployments, add a post-generation validation step that diffs the declared capabilities against the source permission manifest and flags any discrepancies before the declaration reaches an auditor or user.

This prompt is not a one-off document generator. It is a compliance artifact producer that must be integrated into a governed workflow. The generated capability declaration will be reviewed by auditors, regulators, and internal compliance teams, so the implementation harness must treat the output as a controlled record with versioning, traceability, and approval gates. Wire this prompt into your application as a synchronous or asynchronous job that accepts a structured permission specification as input and returns a validated capability declaration. The prompt should never run without a corresponding permission source of truth—do not let the model invent capabilities or limitations from general knowledge.

Input validation is the first integration point. Before the prompt executes, validate that the incoming permission specification contains all required fields: allowed tools, argument constraints, data access scopes, denial rules, and human-review triggers. Reject malformed inputs before they reach the model. Output validation must run after every generation. Parse the returned capability declaration against a strict schema that checks for required sections (capabilities, limitations, human-review requirements, data handling boundaries, and regulatory alignment statements). Use a secondary evaluator prompt or a deterministic rule engine to flag missing sections, contradictory statements, or capability claims that exceed the input permission spec. If validation fails, retry with the error details injected into the prompt's [CONSTRAINTS] block, or escalate to a human reviewer if retries exceed a configured threshold. Logging is mandatory: capture the input permission spec, the model version, the full prompt template with resolved placeholders, the raw output, validation results, and any human approval decisions. Store these as immutable audit records with timestamps and operator identity.

Model choice matters for regulatory accuracy. Use a model with strong instruction-following and low hallucination rates—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may paraphrase permission boundaries loosely or omit required sections. Set temperature to 0 or a very low value (0.1 maximum) to maximize output determinism. Human review is required before the declaration is published or submitted to regulators. Build an approval queue that presents the validated output alongside the input permission spec, validation results, and any flagged discrepancies. The reviewer should confirm that the declaration accurately reflects the actual system permissions, does not over-claim capabilities, and meets the regulatory format requirements for your jurisdiction. Only after human sign-off should the declaration be versioned and released. Retry logic should be bounded: if the model produces three consecutive invalid outputs, stop retrying and escalate to a human operator with the failure context. Do not silently accept a partially valid declaration. Tool use is not required for this prompt's core generation task, but you may wire a post-generation tool that checks the declaration against a regulatory checklist or schema validator before human review. RAG is not recommended here—the prompt should work from the provided permission specification alone, not from retrieved policy documents, to avoid introducing conflicting or outdated regulatory language into the declaration.