AI Consent Ledger: Stop Voice Agents From Ignoring Revoked Permission

A developer proposes an AI consent ledger to solve the state-management problem when voice agents ignore revoked permissions across channels. The append-only record tracks permission events and provides a fast read model to check consent before any agent action, preventing trust incidents from fragmented consent state.

A voice agent can sound polished, respond instantly, and still create a trust incident in one sentence: “Stop calling me.” If that request only updates the SMS path, your agent may keep dialing tomorrow. If it only updates a call transcript, your follow-up workflow may keep texting. For builders shipping AI callers, inbox agents, scheduling bots, or multi-step outreach workflows, consent is no longer a static checkbox. It is runtime state. That is where an AI consent ledger helps. It gives every agent action a simple rule: before contacting, enriching, recording, or escalating a person, check the latest consent state from one durable place. This guide shows how to design that ledger without turning your product into a compliance maze. This is technical architecture guidance, not legal advice. If your workflow touches regulated outreach, health, finance, employment, or sensitive personal data, involve a qualified legal reviewer. Traditional apps usually ask for permission at predictable moments: signup, newsletter opt-in, cookie banner, phone number capture, or billing consent. AI agents blur that boundary. A production agent may: Each step may be valid by itself. The risk appears when consent changes in one channel and the rest of the workflow does not notice. The common failure shape is simple: That is not an LLM problem. It is a state-management problem. An AI consent ledger is an append-only record of permission events plus a fast read model that answers one question: Is this specific agent allowed to perform this specific action for this person right now? The ledger should track consent and revocation across channels, identities, agents, workflows, tools, and time. It is not just a subscribed: true column. A useful ledger stores: For AI workflows, the most important part is not the log. It is the policy check before action. Start by mapping every place an agent can create, use, or change permission state. A user may say: Do not bury these phrases inside transcripts. Extract them as candidate consent events. Voice revocation is tricky because the agent may hear it during a long conversation. You need a separate classifier or deterministic phrase layer that watches for permission changes, not only a final summary. Most teams handle STOP , UNSUBSCRIBE , and START first. That is necessary, but users do not always speak in exact keywords. You also need to catch natural language: Exact keywords can be deterministic. Natural language can be classified, then routed to confirmation or human review when uncertain. An agent may draft or send email from a workflow that was originally voice-based. If email has a separate consent purpose, the ledger must know that. Consent should not silently expand just because the agent has another tool available. Many AI workflows begin with imported contacts. That import may include old consent flags, partial channel history, or no evidence at all. Treat imported permission as lower-trust until verified. Store the source and timestamp so the agent can choose a safer mode. Humans need override paths, but overrides should be explicit events with reasons, not invisible admin edits. A good override record answers: Keep the write model append-only. Build a separate current-state view from it. Here is a compact TypeScript-style model: type ConsentChannel = "voice" | "sms" | "email" | "push" | "in app"; type ConsentPurpose = | "support followup" | "appointment reminder" | "marketing outreach" | "transactional update" | "recording" | "data enrichment"; type ConsentEventType = | "granted" | "revoked" | "limited" | "confirmed" | "expired" | "human override"; type ConsentEvent = { id: string; tenantId: string; subjectId: string; // person/customer/contact normalizedContact: string; // phone/email/device id hash channel: ConsentChannel; purpose: ConsentPurpose; eventType: ConsentEventType; scope: "single channel" | "all channels" | "all outreach"; source: "voice agent" | "sms keyword" | "web form" | "crm import" | "human"; evidenceRef: string; // transcript span, form id, message id, admin note confidence: number; // 0..1 for AI-extracted events workflowRunId?: string; agentId?: string; createdAt: string; expiresAt?: string; }; A few details matter: scope prevents “stop calling” from accidentally becoming “stop everything” unless policy says so. purpose stops consent for appointment reminders from becoming consent for promotions. evidenceRef lets you explain why the system made the decision. confidence lets uncertain AI-extracted events pause instead of acting blindly.Before any state-changing or contact action, ask the ledger for a decision. type ConsentDecision = { allowed: boolean; reason: string; matchedEventIds: string ; requiresHumanReview?: boolean; safeAlternative?: "do not contact" | "in app only" | "ask for confirmation"; }; async function canAgentAct input: { tenantId: string; subjectId: string; channel: ConsentChannel; purpose: ConsentPurpose; action: "call" | "text" | "email" | "record" | "enrich"; workflowRunId: string; } : Promise<ConsentDecision { const state = await consentStore.currentState input ; if state.hasGlobalRevocation { return { allowed: false, reason: "Subject revoked all outreach", matchedEventIds: state.blockingEvents, safeAlternative: "do not contact", }; } if state.channelRevoked { return { allowed: false, reason: ${input.channel} permission was revoked , matchedEventIds: state.blockingEvents, safeAlternative: "in app only", }; } if state.hasPurposeGrant { return { allowed: false, reason: No active consent for ${input.purpose} , matchedEventIds: , safeAlternative: "ask for confirmation", }; } return { allowed: true, reason: "Active consent found", matchedEventIds: state.grantEvents }; } The agent should never be the final authority. It can request an action. Your backend decides whether that action is allowed. Voice agents need a small pipeline around the transcript. Do not only store a full transcript blob. Store time-coded spans. { "span id": "span 928", "speaker": "user", "text": "Please stop calling this number. Texts too.", "start ms": 184200, "end ms": 188700 } Use deterministic rules for obvious phrases and an LLM classifier for softer language. { "intent": "revocation", "channels": "voice", "sms" , "scope": "all outreach", "confidence": 0.94, "evidence span id": "span 928" } Example policy: = 0.90 : write revocation event immediately 0.65 - 0.89 : pause workflow and request human review < 0.65 : store as signal, do not change state automaticallyFor revocation, prefer false positives over continuing unwanted contact. For new consent grants, be stricter. A ledger write should emit an event that cancels or pauses related workflows. await eventBus.publish "consent.revoked", { tenantId, subjectId, channels: "voice", "sms" , scope: "all outreach", evidenceRef: "call 123:span 928", } ; Then workers should stop future steps: js on "consent.revoked", async event = { await workflowStore.pauseRuns { tenantId: event.tenantId, subjectId: event.subjectId, affectedChannels: event.channels, reason: "consent revoked", } ; } ; If revocation does not cancel scheduled jobs, the ledger becomes a diary, not a control system. Not every permission event means the same thing. Use a policy matrix: | User statement | Suggested scope | Default action | |---|---|---| | “Stop texting me” | SMS only | Block SMS, allow other permitted channels | | “Stop calling me” | Voice only | Block calls, allow other permitted channels | | “Do not contact me” | All outreach | Block voice, SMS, email, push | | “Wrong number” | Contact method | Block that phone number, flag identity quality | | “Email me instead” | Channel preference | Block current channel, require email permission check | | “Do not record this” | Recording purpose | Stop recording, continue only if workflow allows | This matrix should live in code or policy configuration, not in the prompt. A simple production flow looks like this: That order matters. Do not call the tool first and check consent later. For voice agents, put the ledger in both directions: Every consent decision should produce a small receipt. { "decision id": "cd 456", "workflow run id": "run 789", "agent id": "voice followup agent", "subject id": "contact 123", "requested action": "sms.followup", "purpose": "appointment reminder", "allowed": false, "reason": "sms permission revoked", "matched event ids": "ce 111" , "created at": "2026-07-30T06:08:00Z" } This helps with debugging and user trust. When someone asks why the agent did or did not contact them, you have a concrete answer. Track these metrics: The key metric is not “how many messages sent.” It is “how many actions were correctly allowed, blocked, or paused.” A system prompt can tell an agent to respect consent. It cannot enforce consent across retries, workers, queues, and integrations. Policy belongs in backend checks. A single can contact=false flag hides why the decision happened. You need the event history for audits, debugging, and safe restoration. Permission to send a login code is not permission to send a promotional sequence. Tie consent to purpose. Queued jobs should check consent at execution time, not only when scheduled. Consent can change between scheduling and sending. If a user gives a phone number for reminders, do not assume the agent may call, text, enrich, record, and email forever. Make expansion explicit. Use this as a first pass: Create test cases from real failure modes. js it "blocks scheduled SMS after spoken all-channel revocation", async = { await ledger.append { subjectId: "c1", channel: "voice", purpose: "marketing outreach", eventType: "revoked", scope: "all outreach", source: "voice agent", confidence: 0.96, evidenceRef: "call 1:span 9", } ; const decision = await canAgentAct { tenantId: "t1", subjectId: "c1", channel: "sms", purpose: "marketing outreach", action: "text", workflowRunId: "run 1", } ; expect decision.allowed .toBe false ; expect decision.reason .toContain "revoked" ; } ; Also test: STOP blocks future voice when policy says all outreach.A consent ledger works best beside other runtime controls: Consent is one boundary in a larger system. But it is a boundary users understand immediately. If they say stop, the system should stop. An AI consent ledger is an append-only record of consent and revocation events plus a runtime read model that decides whether an AI agent may contact, record, enrich, or act for a person. No. Voice agents make the problem obvious, but the same pattern applies to SMS agents, email agents, support copilots, CRM automation, notification systems, and AI workflows that use personal data. An LLM can help classify messy language like “please leave me alone,” but it should not be the final enforcement layer. Write candidate events, apply confidence rules, and let backend policy decide. It depends on the user statement, product policy, and legal context. “Stop texting me” may be channel-specific. “Do not contact me” should usually stop all outreach. Encode this in a policy matrix. Yes. A job scheduled yesterday may become invalid today. Every queued contact action should check the latest consent state immediately before execution. Start with revocation. Capture SMS keywords, spoken stop phrases, current-state checks before outbound actions, and workflow cancellation. Then add purpose-level grants, review queues, and richer evidence receipts. AI agents make workflows faster, but speed makes consent bugs more expensive. The safest pattern is simple: agents can propose contact, but the ledger decides whether contact is allowed. If a person revokes permission in one place, every related workflow should hear it before the next tool call runs.