PrivAgent

Customer conversations pass through outsourced agents, interpreters and AI agents. PrivAgent gives each of them exactly what the task needs - and nothing more.

Comment

Inspiration

In May 2025 Coinbase disclosed that criminals had bribed overseas customer-support contractors to pull customer data, at an estimated cost of $180-400 million. A month earlier, attackers impersonated staff to get a password reset from a help desk at Marks & Spencer - an attack its chairman said involved a third party - and the company estimated a hit of around £300 million to profit. Verizon's 2026 Data Breach Investigations Report puts third-party involvement at 48% of breaches, up from 30% a year earlier.

None of this is exotic. It is how customer service works today: a customer writes on WhatsApp, an outsourced agent opens the ticket and sees the card number, the home address and the date of birth, because the whole conversation travels with the work. An interpreter on a call hears the caller's full identity to translate a warranty question. A contractor gets a customer's home address the day a job is assigned, and keeps it. And now AI agents are joining those desks - agents that, in the PrivacyLens benchmark (NeurIPS 2024), leaked sensitive information in roughly a quarter to a third of tasks even when told to protect privacy.

We asked a simple question. Most of these people need a fraction of what they see: "is this the same person?" needs a yes or no, not an address. Could a system find that fraction for them - in the middle of a real conversation, on the channels customers already use?

What it does

PrivAgent sits between customers and every third party that handles their conversation.

  • Customers write on their own channel - WhatsApp (AWS End User Messaging Social), SMS (AWS End User Messaging SMS), email (Amazon SES) or a hosted web chat. Inbound messages arrive through Amazon SNS.
  • Sensitive values are tokenised before anyone sees them. Card numbers, addresses, phone numbers, IDs and names - and the business's own registered secrets, such as unit costs and supplier names - become tokens like {{ADDRESS_1}}, encrypted in a vault. The outsourced agent, interpreter or contractor works with tokens.
  • When someone needs more, PrivAgent negotiates. The third party states a purpose ("confirm it's the same person"). PrivAgent proposes the least revealing way to finish the task: keep the placeholder, relay a message, an attestation, verify (type what the caller said, get match / no match), a partial value (card ending 1111, postcode district), or - only if nothing else works - the full value for two hours, after the customer approves on their own phone.
  • An independent policy decides. Every option, view and reply is decided by a Cedar policy - the same policy language as Amazon Verified Permissions and Amazon Bedrock AgentCore Policy. Amazon Bedrock helps understand the purpose and word the proposal, but it only ever sees tokens, and it can propose, never grant.
  • Replies are checked before they leave. Agents write Hi {{PERSON_NAME_1}}, we refunded {{PAYMENT_CARD_1}}; the customer receives "Hi Alice Chen, we refunded card ending 1111". A reply that contains a supplier name, someone else's card number or a forged token is blocked, with a safe rewrite.
  • It watches for manipulation. Messages that impersonate head office, probe for costs or suppliers, ask for one-time codes, try to redirect refunds or override the rules are flagged, with a safe reply.
  • Delegation is not authorisation. Access belongs to one person, one field and one purpose. Reassigning or closing the case ends it.
  • Everything is auditable. A hash-chained audit trail records every request, decision and disclosure - with token keys only, never values.
  • AI agents plug in through MCP. A third-party AI agent connects with its own key and gets exactly the rights of the vendor it works for.

How we built it

  • Channels: Amazon SES v2 SendEmail with per-case reply addresses (case+PA-1234@...) so customer replies thread back to the case; AWS End User Messaging Social SendWhatsAppMessage; AWS End User Messaging SMS SendTextMessage. Inbound for all three goes through Amazon SNS HTTPS subscriptions; PrivAgent verifies every SNS signature and confirms the subscriptions itself. A channel router delivers on the customer's preferred channel and falls back to the next one on failure - for example outside WhatsApp's 24-hour window. Consent requests go out on the customer's channel and the confirmation on a second one.
  • AI: the Amazon Bedrock Converse API for purpose classification, negotiation wording and manipulation detection, on redacted text only. A deterministic rule core keeps every answer correct and reproducible when the model is unavailable; the model may raise a risk level but never lower it. Model-written wording is checked before anyone sees it: text that mentions data outside the request, documents, passwords or codes is discarded and replaced by the rule-based wording. A daily call cap keeps model use bounded.
  • Policy and enforcement: Cedar evaluated in WebAssembly, deny by default, fail closed. An enforcement gateway is the only component that decrypts (AES-256-GCM, bound to the case and the token).
  • Product: TypeScript, Fastify and React - REST API, MCP server (Streamable HTTP plus a stdio bridge), landing page, console, customer consent page and customer web chat.
  • Infrastructure: one container image, and an AWS CloudFormation template for the inbound SNS topics and their publish policy, HTTPS subscriptions, SES receipt rule, a least-privilege IAM role, Secrets Manager, Amazon ECR and an EC2 host with automatic HTTPS.
  • Evidence: 92 automated tests, including end-to-end flows for each acceptance scenario, and a reproducible evaluation (npm run evaluate) that runs the same synthetic workload with and without PrivAgent.

Challenges we ran into

  • "No" is not a product. Our early designs centred on detecting and blocking sensitive data. Looking at what already exists - contact-centre redaction, model guardrails, tool-level authorisation - showed that blocking alone was neither new nor enough: a masked field often stops the task. The turning point was treating disclosure as a ladder (relay, attest, verify, partial, consented access) and checking every rung against policy before offering it.
  • Keeping the model out of the trust boundary. It is tempting to let an LLM decide what to share. We kept raw values out of every prompt and made Cedar the only thing that can grant access, so a manipulated model has nothing to leak and no power to release it. Wording was the last gap: in a live test the model, asked to explain an address check, suggested a government ID instead - more sensitive than what was asked. Now the policy picks the option first, the model only words that option, and its text is checked before display.
  • Honest numbers. Our first manipulation-detection test scored 100% - because we were testing on the sentences we had written the rules from. Rephrased attempts exposed how weak the rules were. We rebuilt the test with separate tuning and held-out message sets, kept one held-out set unseen until the rules were final, and report that figure.
  • Consent that proves something. A "reply YES" over SMS does not prove who answered, so approvals happen on a signed, single-use page that names who is asking, for what, why and for how long.

Accomplishments that we're proud of

  • On a seeded synthetic workload of 60 cases (three seeds), raw sensitive values reaching third parties fell from about 310 to 14-19 - a 94-96% reduction - and card numbers from 60 to 0, with no legitimate work stopped by the system. Every task that did not finish was one the customer declined.
  • Known abuse paths - raw card requests, access after reassignment or closure, secrets and other people's card numbers in replies - are blocked by policy, not by a prompt.
  • Rule-only manipulation detection catches 11 of 12 attempts in a held-out set, with 1 false alarm in 12 ordinary messages; the Bedrock layer is there to improve both.
  • One case can span channels: a conversation that starts on WhatsApp can ask for consent by SMS and confirm by email.

What we learned

  • Most requests for personal data are really requests for a fact: a match, a district, the last four digits.
  • Policy languages like Cedar make privacy rules readable to the people who must sign them off, not only to engineers.
  • Agentic systems need the same separation of duties as people: whoever negotiates should not be whoever authorises.

What's next for PrivAgent

  • Design-partner pilots with a BPO vendor and a language-service provider to measure handling time and exposure on real, consented traffic.
  • An AWS Marketplace SaaS listing; our pricing hypothesis is per protected conversation plus a platform fee.
  • Amazon DynamoDB storage for multi-node scale, Amazon Bedrock AgentCore Runtime hosting for the MCP server, and Cedar policies managed in Amazon Verified Permissions.
  • RCS through AWS End User Messaging, and approved WhatsApp templates for consent requests outside the 24-hour window.
  • Federated deployment: each organisation in a subcontracting chain runs its own PrivAgent node and exchanges only negotiated proposals.

Built With

Share this project:

Updates