Customer data

Catch customer data in a message before it’s sent to the wrong person.

Most leaks aren’t attacks. They’re a pasted order from the wrong ticket, an AI reply that pulled the wrong record, or details handed to someone who only says they’re family. Check outgoing content against who is allowed to see it.

Start freeSee an example

A regex can’t tell whose data it is

Pattern matching finds emails and phone numbers. It can’t tell if the email belongs to the person you’re writing to, which is the whole question in support. Blocking every email address breaks normal replies; allowing them all lets the wrong-ticket mistake through.

Enforly evaluates the message with the recipient and the conversation, so “your address”, “someone else’s address”, and “your wife’s address, if she really is your wife” get different answers.

Where the check fits

One call between the step that prepares something and the step that sends, publishes, or runs it. Your code applies the decision.

See it decide

The same policy evaluated on three cases. Pick one and run the check to see which evidence it relies on.

Policy

Content may include personal data (email, phone, address, order history) only about the customer described in data.recipient. Never include details about any other person. If the reply shares someone else’s details because the recipient claims a relationship or permission that is only stated in the conversation, a person verifies it first.

data

{
  "recipient": {
    "name": "Lucía Gómez",
    "email": "lucia@mail.com",
    "address": "Av. Corrientes 1234"
  },
  "conversation": [
    "Can you send it to my usual address?"
  ],
  "content": "Hi Lucía, we’ll ship your order to Av. Corrientes 1234, as you requested."
}

Result

violationProbability—
reviewProbability—

Why: The address in the reply is the recipient’s own.

Your code: Send the message.

Response JSON
{
  "decision": "allow",
  "allowed": true,
  "violationProbability": 0.04,
  "reviewProbability": 0.04,
  "policyId": null,
  "policyVersion": null,
  "requestId": "req_7f3a…"
}

Illustrative example. Real probabilities depend on your policy wording and the evidence you send.

allow · Own data

The address in the reply is the recipient’s own.

deny · Wrong customer

The reply names a different person, with their address and email. It looks like details pulled from another customer’s order.

review · Claimed relationship

The reply shares another person’s order and address. The recipient may be her husband, but that relationship is only claimed in the chat.

Combine it with what you already have

Keep cheap, deterministic checks where they work best, and use Enforly for the judgment calls:

  • Use regex or a library to detect card numbers and secrets before anything else.
  • Use Enforly to decide whether the personal data present is appropriate for this recipient and purpose.
  • Use your DLP or access control tools for enforcement across your whole organization.

Set it up

  1. 1

    Define who may see what

    Write the rule in terms of the recipient: their own data is fine, other people’s is not, claimed permissions get verified.

  2. 2

    Send content with its context

    Include who the recipient is and the recent conversation, not your whole database.

  3. 3

    Block or ask before it leaves

    On deny, block and explain. On review, ask a teammate to verify.

Before sending a support reply
import { Enforly } from '@enforly/sdk'

const guard = new Enforly({ apiKey: process.env.ENFORLY_API_KEY })

const result = await guard.check({
  policyId: CUSTOMER_DATA_POLICY_ID,
  data: {
    recipient: { name: ticket.customerName, email: ticket.email, address: ticket.address },
    conversation: ticket.messages.slice(-5).map(m => m.text),
    content: reply,
  },
})

if (!result.allowed) return showWarning(result.decision, result.requestId)
await helpdesk.reply(ticket.id, reply)

Full request and response fields are in the API reference. Using a coding agent? Point it to Build with AI.

What Enforly doesn’t do

Enforly evaluates the information you send and returns a decision. It doesn’t run operations, and it doesn’t guarantee safety or compliance on its own.

  • Enforly is not a DLP suite. It doesn’t scan your storage, redact text, or enforce access across your organization.
  • It evaluates what you send. If deciding whose data it is depends on a record, include that record.
  • Enforly doesn’t keep check data, but it does send it to TypeSafe AI for evaluation. Review that against your own data obligations.

Questions

Does Enforly store the messages I check?

No. It keeps the decision and request ID in your activity log, not the data. Check content is sent to TypeSafe AI for evaluation.

Can it redact the data instead of blocking?

No. It returns a decision. You can redact with your own code and check the redacted version again.

Related

Outbound messagesCheck AI-written emails and customer replies before they’re sentRead Semantic validationValidate JSON against business rules, not just schemasRead AI agentsAI agent guardrails: validate tool calls before they runRead

Try this policy on your own data.

Copy the policy above, add your real examples, and see the decision. 200 free checks per month, no credit card.

Start freeBrowse policy templates