Guard Models

PII & DLP model

Detects personal data and secrets in text and tool arguments, and can redact them in place — reversibly — so sensitive values never reach the model, your logs, or a downstream tool.

The PII/DLP model locates sensitive entities and returns precise character offsets for each match. Beyond detection, it powers Guardion's data-loss-prevention flow: matched spans can be replaced with stable tokens before content leaves your boundary, and restored later for authorized recipients.

Data types detected

Each detector group is a check you enable per policy. Every group and the entity types it detects:

Detectors	Types
Person name	person, full name, first name, middle name, last name, date of birth, name
Contact	email, phone number, phone
Address	address, street address, street, city, state or region, state, postal code, cep, country
Government ID	government id, national id number, passport number, driver license, license number, tax id, tax number, ssn, social security number, cpf, cnpj, rg
Payment	bank account, account number, routing number, iban, payment card, credit card, card number, card expiry, card cvv
Digital ID	username, ip address, account id, sensitive account id, uuid identifier, guid, public key, private key, bitcoin address
Password	password, secret, api key, access token, recovery code
Date	sensitive date, document date, expiration date, transaction date
Company	company name, organization
Credentials	aws access key, aws secret key, github token, google api key, slack token, stripe key, private key, jwt, npm token, seed phrase, generic api key / secret / token / password

Detection, then redaction

On POST /v1/guard, matches are reported in the detector breakdown and as redaction_spans — { index, start, end, label, token } — pinpointing exactly what was found and where.

When a redact action applies, the content is rewritten with placeholder tokens and the response is marked redacted. The original values are kept in an account-scoped vault keyed by a redaction_vault_id, so authorized callers can reverse the redaction later.

Standalone redaction endpoints

For DLP outside of policy evaluation, use the dedicated endpoints: Redact PII to tokenize, and Restore PII to reverse it.

Secret detection benchmark

How Guardion detects secrets and credentials, evaluated on verified secret samples from public datasets.

Secret detection

Recall

0.96

Precision

0.98

0.97

FPR

0.004

Binary secret/credential detection over public secret corpora (secretbench, secrets-patterns-db). Deterministic pattern rules combine with a model-based entropy/token signal to catch novel, provider-agnostic secrets alongside known formats — high recall at near-zero false positives.

PII entity detection benchmark

Span-level entity detection performance on a public privacy corpus, broken down by entity group.

Entity detection performance

Recall

0.95

Precision

1.00

0.97

FPR

0.004

Span-level detection of personal-data entities on public PII benchmarks — SPY (legal + medical, LogicZMaksimka), ai4privacy/pii-masking-300k, and guardion/BR-Agentic-PII-Benchmark — matched at IoU ≥ 0.5, at the default sensitivity. Deterministic categories (contact, payment, government IDs) run alongside the model for a model-independent baseline, with the model covering free-form entities.

Sensitivity levels

PII/DLP runs at four sensitivity levels — lower levels flag only the highest-confidence matches; higher levels widen coverage. L2 is the default. Precision stays at or near 1.00 across every level, so tuning trades a little recall against an essentially zero false-positive rate.

Level	Recall	Precision	FPR
L1Lenient	0.86	1.00	0.000
L2Default	0.87	1.00	0.000
L3Broad	0.93	1.00	0.000
L4Strict	0.94	1.00	0.004

curl https://api.guardion.ai/v1/guard \
  -H "Authorization: Bearer $GUARDION_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      { "role": "user", "content": "My email is jane@acme.com and SSN 123-45-6789" }
    ]
  }'

Response

{
  "flagged": true,
  "redacted": true,
  "redaction_spans": [
    { "index": 0, "start": 12, "end": 25, "label": "EMAIL", "token": "[EMAIL_1]" },
    { "index": 0, "start": 34, "end": 45, "label": "SSN", "token": "[SSN_1]" }
  ]
}