Consent Withdrawal Handling Prompt Template

This prompt template is designed for a specific job-to-be-done: enforcing an immediate, model-level behavioral contract when a user revokes consent mid-session. The ideal user is a product engineer or AI platform architect building a user-facing application (such as a personal assistant, a health coach, or a financial advisor) where the user can toggle a consent setting in the UI and expects the AI to stop all dependent processing instantly. The required context is a live session where the model has been operating under a previously granted consent scope, and a system event—typically a tool call or a metadata update—signals that this scope has been narrowed or fully revoked. The prompt acts as a first line of defense, ensuring the model itself refuses to continue processing, purges session-scoped data, and declines any previously allowed actions, all before your backend enforcement catches up.

You should use this prompt when the latency of backend policy propagation creates a window of risk. For example, if a user revokes consent for calendar access, the model must immediately stop reading, referencing, or summarizing calendar data, even if the API key invalidation takes several seconds. The prompt enforces three non-negotiable actions: (1) immediate cessation of all processing dependent on the withdrawn consent, (2) purging of any session-scoped data derived under that consent, and (3) a hard refusal of any follow-up user request that relies on the revoked permission. This is not a replacement for backend consent management, access control lists, or legal review. It is a behavioral enforcement layer that fails safely when backend systems lag. Implement this alongside—not instead of—proper authorization checks in your tool execution layer.

Do not use this prompt as your sole consent enforcement mechanism, as a substitute for deleting user data from persistent stores, or in scenarios where the model has no ability to distinguish between data scopes. It is also inappropriate for asynchronous or batch processing where no live user session exists. Before deploying, you must test the prompt against partial withdrawal scenarios (e.g., revoking calendar consent but retaining email consent) and delayed propagation edge cases where the consent signal arrives mid-task. The next step is to copy the template, map the [CONSENT_SCOPES] and [REVOCATION_SIGNAL] placeholders to your application's specific consent taxonomy, and integrate it into your system prompt stack with a clear priority above task-level instructions.

This system prompt is designed to be the single source of truth for how your AI assistant handles consent withdrawal mid-session. It defines the immediate behavioral contract: what data must be purged from active context, which previously-allowed actions become forbidden, how the assistant must communicate the state change to the user, and what happens to in-flight tool calls or multi-step workflows. The prompt uses square-bracket placeholders that you must replace with your application's specific consent scopes, data categories, gated actions, and escalation paths before deployment.

textCopy
# SYSTEM INSTRUCTION: CONSENT WITHDRAWAL HANDLING

You are an AI assistant operating in a regulated environment where users may revoke consent for specific data processing activities at any time. Your behavior must change immediately and verifiably upon receiving a consent state update.

## CONSENT STATE TRACKING
- Active consent grants are provided in [CONSENT_STATE_OBJECT] at the start of each turn.
- [CONSENT_STATE_OBJECT] contains: consent_id, scope, status (granted|withdrawn|expired), granted_at, withdrawn_at, data_categories_covered, permitted_actions.
- A consent withdrawal is indicated by status="withdrawn" with a non-null withdrawn_at timestamp.
- Consent withdrawal is effective immediately upon receipt. Do not complete in-flight actions that depend on withdrawn consent.

## IMMEDIATE ACTIONS UPON CONSENT WITHDRAWAL
When you detect a consent withdrawal for any scope in [CONSENT_STATE_OBJECT]:

1. **Purge Active Context**: Remove all user data, conversation history, tool outputs, and retrieved documents that fall under the withdrawn consent's data_categories_covered from your working memory. Do not reference purged data in any subsequent response.

2. **Halt Dependent Actions**: Immediately stop any multi-step workflow, tool call, or reasoning chain that requires the withdrawn consent. Do not complete partial work. Do not save intermediate results that contain affected data.

3. **Refuse Gated Actions**: For the remainder of the session, refuse any user request that requires the withdrawn consent scope. Your refusal must be explicit: "I cannot perform [REQUESTED_ACTION] because consent for [SCOPE] was withdrawn at [TIMESTAMP]. [ALTERNATIVE_IF_AVAILABLE]"

4. **Session Reset Notification**: Inform the user clearly: "Consent for [SCOPE] has been withdrawn. I have removed [DATA_CATEGORIES] from active context. I can no longer perform [GATED_ACTIONS]. [REMAINING_CAPABILITIES]"

## PARTIAL WITHDRAWAL HANDLING
- If only some consent scopes are withdrawn, continue operating within remaining active scopes.
- Do not allow remaining scopes to indirectly access data covered by withdrawn scopes.
- If a user request spans both active and withdrawn scopes, refuse the entire request if the scopes cannot be cleanly separated.

## DELAYED PROPAGATION RULES
- If [CONSENT_STATE_OBJECT] indicates a propagation delay (propagation_deadline field), apply the withdrawal by that deadline.
- Before the deadline, continue operating under the prior consent state but do not initiate new long-running actions that would span the deadline.
- Log the pending withdrawal and deadline for audit purposes.

## PROHIBITED BEHAVIORS
- Do not suggest the user re-grant consent unless explicitly asked.
- Do not retain purged data in summaries, notes, or reasoning artifacts.
- Do not complete tool calls that were initiated before withdrawal if the tool response would contain affected data.
- Do not treat consent withdrawal as a user error or argue against it.

## AUDIT AND LOGGING
- For every consent withdrawal event, emit a structured audit record: [AUDIT_LOG_FORMAT]
- Include: withdrawal_timestamp, scopes_affected, data_purged (categories only, not content), actions_halted, user_notification_delivered (boolean).
- Do not include purged data content in audit records.

## ESCALATION
- If consent withdrawal creates an unsafe state (e.g., incomplete medical workflow, financial transaction in progress), escalate to [HUMAN_ESCALATION_PATH] with a summary of halted actions and affected scopes.
- If you cannot determine whether specific data falls under a withdrawn scope, escalate rather than guess.

## TEST ASSERTIONS (for evaluation)
- [EVAL_CONSENT_WITHDRAWAL_IMMEDIATE]: After withdrawal, assistant must refuse previously-allowed action within the same turn.
- [EVAL_PARTIAL_WITHDRAWAL_SCOPE_ISOLATION]: After partial withdrawal, assistant must not use remaining scopes to access withdrawn-scope data.
- [EVAL_DELAYED_PROPAGATION]: Assistant must honor propagation_deadline and not start long-running actions that cross it.
- [EVAL_AUDIT_RECORD_EMISSION]: Every withdrawal must produce a valid audit record in [AUDIT_LOG_FORMAT].
- [EVAL_NO_REGRANT_SUGGESTION]: Assistant must not proactively suggest re-granting consent.

Adapt this template by replacing each square-bracket placeholder with your application's concrete values. [CONSENT_STATE_OBJECT] should match the JSON schema your consent service provides. [DATA_CATEGORIES] should map to your data classification taxonomy. [GATED_ACTIONS] should list the specific tool calls, API endpoints, or response types that require consent. [AUDIT_LOG_FORMAT] should match your logging pipeline's expected schema. [HUMAN_ESCALATION_PATH] should point to a real queue, Slack channel, or on-call rotation. The eval placeholders at the bottom are designed to be replaced with your test framework's assertion references. Before shipping, run the prompt against the eval scenarios described in the Testing and Evaluation section of this playbook, paying particular attention to partial withdrawal isolation and delayed propagation edge cases where most production failures occur.

The consent withdrawal prompt template is not a standalone solution—it is a behavioral contract that must be enforced by the application layer. When a user revokes consent mid-session, the prompt instructs the model to immediately stop processing, purge referenced data, and refuse previously allowed actions. However, the model cannot actually delete data from your databases, invalidate cached context, or reset tool permissions on its own. The application harness must detect the consent withdrawal event, inject the updated system prompt with the withdrawal directive, clear the conversation history that contains now-unconsented data, and revoke any tool access tokens or data scopes that were granted under the prior consent. Without this application-layer enforcement, the prompt becomes a polite suggestion that the model may or may not follow consistently.

Implement the harness as a state machine with at least three states: consent-active, consent-withdrawn, and consent-expired. On transition to consent-withdrawn, execute these steps atomically: (1) replace the active system prompt with the withdrawal variant that includes the [WITHDRAWAL_TIMESTAMP] and [DATA_CATEGORIES_TO_PURGE] variables; (2) truncate the conversation to remove all turns that occurred under the previous consent scope—do not rely on the model to ignore them; (3) revoke or rotate any API keys, database cursors, or tool sessions that were scoped to the withdrawn consent; (4) log the withdrawal event with a structured record containing user_id, session_id, consent_id, withdrawal_timestamp, and data_categories_affected. For model choice, prefer models with strong instruction-following and low prompt-ignoring rates under context pressure—Claude 3.5 Sonnet and GPT-4o have shown reliable adherence to mid-session policy changes in testing, but always validate with your specific prompt variant. Implement a retry gate: if the model's next response after withdrawal references data it should no longer have access to, do not retry with the same prompt—escalate to a human reviewer and quarantine the session.

Validation must happen at two levels. First, validate the model's output against the withdrawal constraints using a structured eval: check that the response contains no references to purged data categories, no offers to perform now-forbidden actions, and an explicit acknowledgment of the consent change. Use an LLM-as-judge eval with a rubric that scores compliance, data_leakage, and refusal_clarity on a pass/fail basis. Second, validate the application state: confirm that the conversation history in your database no longer contains the purged turns, that tool access tokens have been invalidated, and that the audit log entry is complete. For high-risk domains such as healthcare or finance, add a human approval step before the model can respond to any request made within 5 minutes of a consent withdrawal—this catches edge cases where the model partially complies but still leaks through implication or summary. Do not rely on the model's self-report of compliance; always verify independently.

Common failure modes in the harness layer include: race conditions where a user message is processed with the old prompt before the withdrawal takes effect; incomplete conversation truncation that leaves stale context in the model's attention window; tool calls that execute with cached credentials after consent revocation; and logging gaps that make it impossible to prove what data was processed post-withdrawal. Mitigate these by using a session-level mutex during consent state transitions, clearing the model's context window entirely rather than editing individual turns, implementing tool gateways that check consent state before every execution, and writing audit events synchronously before any model response is returned to the user. Test the harness with adversarial scenarios: rapid consent toggle (withdraw, re-consent, withdraw again within seconds), partial withdrawal where only some data categories are revoked, and delayed propagation where the withdrawal event arrives mid-tool-call. Each scenario should have a defined expected behavior and an automated integration test that validates the full stack, not just the prompt.