Tool Authorization for PII and Sensitive Data Tools Prompt Template

This playbook is for privacy engineers and AI platform architects who need to enforce data access controls at the prompt layer before a tool call reaches the execution layer. Use this system prompt when your AI assistant has access to tools that can retrieve, display, or process personally identifiable information (PII), protected health information (PHI), or other sensitive data categories. The prompt classifies every available tool into a sensitivity tier, requires explicit justification before any PII-accessing tool is called, enforces data minimization by instructing the model to request only the minimum necessary fields, and defines refusal behavior for data subject access requests (DSARs) that exceed authorized boundaries.

This is not a general-purpose tool authorization prompt. It is purpose-built for workflows where a data protection impact assessment (DPIA) or regulatory requirement demands that the model itself reason about data sensitivity before acting. Do not use this prompt for simple read-only vs. write tool gating, for basic user-role permission mapping, or for rate-limiting tool calls—those scenarios have dedicated playbooks. This prompt is appropriate when the model must dynamically evaluate what data a tool might touch and apply data-minimization principles at inference time. For example, a customer support assistant that can look up order history (non-sensitive) and full account profiles (sensitive) needs this prompt to ensure it doesn't pull a full profile just to check a shipping status.

Before implementing this prompt, ensure you have completed a data inventory of all tools and their accessible fields, classified each tool into a sensitivity tier (e.g., non-sensitive, pii, phi), and defined the minimum necessary fields for each common user intent. The prompt template uses these classifications as its grounding context. Without this inventory, the model has no factual basis for its access decisions and will produce inconsistent, un-auditable behavior. After deploying this prompt, pair it with structured logging that captures every tool-call justification so that compliance reviewers can trace why a sensitive tool was invoked.

This is a system prompt. Place it in the system message of your model request. Square-bracket placeholders must be replaced with your specific tool catalog, data classification policy, and user context before use. The prompt is designed to act as a policy enforcement layer that sits between the model's reasoning and the tool execution layer, ensuring that no tool capable of accessing PII or sensitive data is called without explicit, justified intent.

codeCopy
You are a data-privacy-aware assistant with access to a catalog of tools. Your primary directive is to protect Personally Identifiable Information (PII) and Sensitive Data as defined by the organization's data classification policy.

## TOOL CATALOG
[TOOLS]

## DATA CLASSIFICATION POLICY
- **PII Data**: [PII_DATA_DEFINITION]
- **Sensitive Data**: [SENSITIVE_DATA_DEFINITION]
- **Public Data**: [PUBLIC_DATA_DEFINITION]

## AUTHORIZATION RULES
1.  **Default Deny**: You are forbidden from calling any tool tagged with `access_level: pii` or `access_level: sensitive` unless the user's request explicitly requires it and you have provided a valid justification.
2.  **Data Minimization**: When calling a tool that accesses PII or sensitive data, you MUST use the most restrictive parameters possible. Request only the specific fields required to fulfill the user's intent. Never request entire records if a single field will suffice.
3.  **Justification Requirement**: Before every call to a restricted tool, you must output a `justification` block in your response, explaining:
    - The specific user request that necessitates the access.
    - The exact data fields you will request.
    - Why less sensitive data or a non-restricted tool cannot fulfill the request.
4.  **Data Subject Request (DSR) Handling**: If a user request appears to be a Data Subject Request (e.g., "delete my data," "what do you know about me?"), you MUST NOT call any tool. Instead, respond with the standard DSR routing message: [DSR_ROUTING_MESSAGE].
5.  **Prohibited Actions**: You are strictly prohibited from:
    - Calling a restricted tool without a preceding justification block.
    - Combining PII from multiple users into a single response.
    - Outputting raw PII in your final response unless the user's request specifically requires it and it is a single, validated field.

## RESPONSE FORMAT
If a restricted tool call is required, your response must be structured as follows:
[Justification Block]
[Tool Call]

If no restricted tool is needed, proceed with the standard tool call or text response.

To adapt this template, replace the square-bracket placeholders with your concrete definitions. The [TOOLS] placeholder should be populated with a JSON schema or structured list of your actual functions, each annotated with an access_level field (e.g., pii, sensitive, public). The data classification definitions must be precise and match your legal and compliance team's language. The [DSR_ROUTING_MESSAGE] should be a pre-approved, static text block that instructs the user on the correct legal process. Before deploying, test the prompt's refusal behavior against a battery of direct and indirect PII extraction attempts to ensure the justification requirement is not merely cosmetic but acts as an effective gating mechanism.

This prompt is not a standalone artifact; it is a policy enforcement layer that must be integrated into a broader application harness. The system prompt defines what the model should do, but the application layer must enforce what actually happens. The harness described here ensures that the model's authorization decisions are validated before any tool is executed, that sensitive data exposure is prevented at the execution boundary, and that every access decision is logged for audit. The core principle is defense in depth: the prompt instructs the model to classify and justify access, but the harness independently verifies those classifications against a trusted policy store and blocks any tool call that does not match the declared sensitivity level, justification requirement, or data minimization rule.

The implementation loop follows a strict classify-then-validate-then-execute pattern. First, the application sends the user request and tool definitions to the model with this system prompt. The model returns a structured decision containing the tool name, arguments, a data_sensitivity classification (PII, SENSITIVE, PUBLIC), a justification string, and a minimization_applied boolean. Before execution, a policy enforcement middleware validates this output: it checks that the declared data_sensitivity matches the tool's registered sensitivity tier in a configuration store, confirms that justification is non-empty for any PII or SENSITIVE classification, and verifies that minimization_applied is true when the tool's schema includes fields tagged as PII. If validation fails, the tool call is blocked, the event is logged at WARN level, and a structured refusal is returned to the user without retrying the model. If validation passes, the tool executes, and the full decision payload is written to an immutable audit log alongside the execution result. For high-risk operations—such as bulk data exports or data subject access requests—the middleware should route the validated decision to a human approval queue before execution, presenting the justification and proposed arguments for review.

Retry logic in this harness is deliberately conservative. If the model returns malformed JSON or a decision that fails schema validation, the application should retry once with the same prompt plus the validation error message appended as a [VALIDATION_ERROR] context block. If the second attempt also fails, the request is escalated to a human operator and the session is flagged for review. Do not retry on policy validation failures—those indicate a model behavior problem, not a transient error. For observability, instrument every step: log the raw model output, the validation result, the policy decision (allow/block/queue), and the execution outcome. Use structured logging with trace IDs that connect the user request to the model decision and the tool execution. This trace chain is essential for debugging authorization gaps and for demonstrating compliance during audits. Finally, maintain the tool-to-sensitivity-tier mapping in a version-controlled configuration file outside the prompt, and include a policy_version field in every audit log entry so that decisions can be traced back to the exact policy that was in effect at the time of the request.