Sensitive Data Access Boundary Prompt Template

This prompt is for privacy engineers and platform teams who need to bind an AI role's data interaction to explicit field-level access rules. Use it when a model, agent, or assistant must handle PII, PHI, or confidential data and you need enforceable, auditable boundaries that prevent unauthorized disclosure, cross-purpose use, or retention beyond a declared scope. The primary job-to-be-done is translating a data classification policy into a machine-readable instruction that constrains what the model can do with data it can technically see. Ideal users are teams operating in regulated environments (HIPAA, GDPR, SOC 2) or any product where data misuse by an AI assistant carries legal, reputational, or customer trust risk.

This prompt produces a structured data access policy that maps data classifications to permitted operations, purpose limitations, and handling requirements. It is not a replacement for application-layer access control, encryption, or data redaction pipelines. It is the instruction layer that tells the model what it is allowed to do with data it can already technically see. If your system has not already enforced column-level security at the database layer, row-level filtering at the API layer, or PII redaction before the prompt is assembled, deploy those controls first. This prompt adds defense-in-depth for the model's reasoning behavior, but it cannot prevent a determined adversary from extracting data if the underlying retrieval system returns raw fields the model should not see.

Do not use this prompt when the data access rules are simple enough to enforce entirely through retrieval filtering. If you can solve the problem by never sending restricted fields to the model in the first place, that is always the stronger control. This prompt is appropriate when the model must reason over sensitive data to produce useful output—for example, summarizing a patient record while omitting specific identifiers, or analyzing transaction patterns without exposing individual account numbers in the response. Before deploying, pair this prompt with output validation that scans for disallowed data patterns, and implement logging that captures boundary violation attempts for audit review.

The following prompt template defines a strict data access boundary for an AI role. It binds the model to specific data classifications, field-level permissions, and purpose limitations. Before using this template, map your data catalog to the placeholder fields: identify which data classes (e.g., PII, PHI, PCI, internal-confidential) exist in your system, which roles may access them, and under what processing purposes. This template is designed to sit in the system instruction layer with higher priority than user or tool messages. It should be combined with a separate output validation step that checks whether the model's response contains data outside its declared access scope.

textCopy
## DATA ACCESS BOUNDARY
You are assigned the role [ROLE_NAME] with data access level [ACCESS_LEVEL].

### PERMITTED DATA CLASSES
You may access and reference only the following data classes:
[DATA_CLASS_LIST]

### FIELD-LEVEL ACCESS RULES
For each permitted data class, you may access only these fields:
[DATA_CLASS]: [ALLOWED_FIELD_1], [ALLOWED_FIELD_2], [ALLOWED_FIELD_3]

### FORBIDDEN DATA
You must never access, reference, infer, or reconstruct:
- [FORBIDDEN_DATA_CLASS_1]
- [FORBIDDEN_DATA_CLASS_2]
- Any field not explicitly listed in FIELD-LEVEL ACCESS RULES
- Any data attribute that could be used to re-identify an individual when combined with permitted fields

### PURPOSE RESTRICTIONS
You may process permitted data only for these purposes:
[ALLOWED_PURPOSE_1]
[ALLOWED_PURPOSE_2]

You must refuse any request to use data for purposes outside this list.

### HANDLING REQUIREMENTS
- Never output raw values from [RESTRICTED_FIELD_CATEGORIES] in your response
- When summarizing, aggregate at minimum [AGGREGATION_THRESHOLD] records
- Apply [MASKING_RULE] to [MASKED_FIELDS] before including in any output
- Do not confirm or deny the existence of individual records from [SENSITIVE_DATA_CLASS]

### VIOLATION RESPONSE
If a request requires accessing data outside your boundary, respond with:
"I cannot process this request because it requires access to data outside my authorized scope. [ESCALATION_INSTRUCTION]"

### SOURCE GROUNDING
All data references must be traceable to [AUTHORIZED_SOURCE]. Do not fabricate or infer data values.

To adapt this template, start by replacing [ROLE_NAME] and [ACCESS_LEVEL] with identifiers from your IAM or data governance system. The [DATA_CLASS_LIST] should map directly to your data classification taxonomy—use the exact labels your compliance team recognizes. For field-level rules, list every field the role may touch; anything omitted is implicitly forbidden. The purpose restrictions should align with your data processing agreements or privacy policies. The handling requirements section is where you encode operational rules: aggregation thresholds prevent singling out individuals, masking rules define redaction patterns, and source grounding prevents hallucinated data. Test the boundary by crafting adversarial requests that ask for forbidden fields, attempt re-identification, or request processing for disallowed purposes. Each should trigger the violation response.

After deploying this prompt, implement a validation layer that scans model outputs for patterns matching forbidden data classes. Common failure modes include the model paraphrasing restricted data instead of quoting it directly, inferring forbidden fields from permitted ones, or complying with a user request that reframes a disallowed purpose as an allowed one. Run boundary violation evals weekly and log every refusal for audit review. If your data classification taxonomy changes, update [DATA_CLASS_LIST] and [FORBIDDEN_DATA_CLASS] immediately and increment the prompt version. Never rely on this prompt alone for compliance—it is one layer in a defense-in-depth strategy that must include application-level access controls, output scanning, and human review for high-risk data operations.

The Sensitive Data Access Boundary prompt is not a standalone chat interaction—it is a policy enforcement layer that should sit between your application's data access logic and the model's reasoning. In a typical implementation, the prompt is invoked whenever a user or agent role requests access to a data field, record, or dataset that has been classified as sensitive. The application layer must first resolve the requesting role's identity, the target data classification, and the purpose of access before assembling the prompt with the [ROLE_DEFINITION], [DATA_CLASSIFICATION], [ACCESS_PURPOSE], and [REQUESTED_FIELDS] placeholders populated from your policy store and data catalog. The model's output—a structured access decision with field-level allow/deny rules, purpose restrictions, and handling requirements—should be parsed and enforced by the application, not merely displayed to the user. This means your application must be capable of intercepting data access attempts, pausing execution, calling the model with this prompt, and then applying the returned constraints before any data is released to the requesting role or downstream system.

For production wiring, implement a policy decision point (PDP) pattern: a dedicated service or middleware that receives access requests, assembles the prompt, calls the model, validates the structured output against a strict schema, and returns an enforceable decision. The output schema should include allowed_fields (array of field paths), denied_fields (array with denial reasons), purpose_restrictions (string describing permitted uses), handling_requirements (array of strings like 'do not persist', 'mask in logs', 'require audit entry'), and violation_indicators (array of detected risks). Validate this output programmatically before enforcement: check that no field appears in both allowed and denied lists, that all requested fields are accounted for, and that handling requirements map to actions your system can actually execute. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_OUTPUT_ERRORS]. If the retry also fails, block access by default and escalate to a human reviewer—never default to permissive when the policy decision is unparseable. Log every decision with the prompt version, model, timestamp, requesting role, data classification, and full decision payload for audit trails.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent—because the prompt requires precise field-level reasoning and refusal to speculate about data the role should not see. Avoid smaller or older models that may hallucinate field names or default to permissive answers under ambiguity. For high-throughput scenarios where latency is critical, consider caching decisions for identical (role, data_classification, purpose) tuples with a short TTL, but invalidate the cache immediately if the role definition, data classification, or policy version changes. Never cache decisions that involve PII, PHI, or other regulated data unless your compliance framework explicitly permits it. If your system uses retrieval-augmented generation (RAG) to supply the [DATA_CLASSIFICATION] or [POLICY_CONTEXT] fields, ensure the retrieval step is completed and its output validated before the prompt is assembled—do not let the model retrieve policy documents at runtime, as this creates a circular dependency where the model could access policy information beyond its authorized scope. Finally, integrate the prompt's violation_indicators output into your monitoring stack: if the model flags a potential violation, generate an alert, log the full context, and consider whether the requesting role or upstream system should be temporarily restricted pending review.