Data loss prevention
Detectors for personal data and secrets, and rules that warn, hold or block.
Data loss prevention (DLP) stops customer data, such as a spreadsheet of My Numbers, from leaving the company by mistake or without a decision on record. Every file is inspected before it can be shared, and the tenant's rules decide what happens next.
How it works
- Each file is inspected in the same pass as its malware scan. Inspection can't be turned off (FR-36).
- When every file is shareable, the tenant's rules are evaluated against the findings and the recipients. The strictest matching action wins.
- The sender sees the matched rules and, per file, the detector, how many, where (such as sheet and row) and a masked preview, never the value (UC-7).
- The transfer is sent, waits for the sender or an approver, or is held. Every decision goes into the audit log (FR-54).
Received files are inspected too. A rule for them can allow and record, or block; a blocked file never reaches the member (FR-51).
Built-in detectors
Built-in detectors work in English and Japanese text, with full-width digits and IME dashes normalised first (FR-37).
| Detector | Validation |
|---|---|
| My Number (個人番号) | 12 digits with the official check digit |
| Corporate Number (法人番号) | 13 digits with the National Tax Agency check digit |
| Payment card numbers | Luhn check plus known issuer ranges and lengths |
| Japanese bank accounts | Account number with account keywords nearby; no check digit exists |
| IBAN | Country length and mod 97 check |
| Phone numbers, Japanese and international | libphonenumber metadata |
| Email addresses | Format plus a known public suffix |
| Japanese passport numbers | Format with passport keywords nearby |
| Passport machine-readable zones | ICAO 9303 check digits |
| Japanese driver's licence numbers | Prefecture code, check digit and context |
| Cloud access keys and tokens | Known formats and checksums, such as AWS keys and GitHub tokens |
| Private keys | PEM, OpenSSH, PuTTY and PGP private key blocks |
| Confidentiality labels | 社外秘, 極秘, Confidential, Internal Use Only and similar marks |
Tenant admins add keyword lists in English and Japanese (FR-38) and RE2 patterns, which run in linear time (FR-39).
Confidence
Every match is low, medium or high, from its format, check digit and context such as a column header. A 12-digit number that passes the My Number check is low on its own, because product codes pass too; under a "個人番号" column it is high. Rules set a minimum confidence, and the default rules never act on low.
Rules and actions
A policy holds up to 50 rules (FR-40). Each has one condition (detectors at a minimum confidence and count, files not fully inspected, or a new recipient domain) and one action (FR-41). Counts add up across a transfer's files and message, so splitting data doesn't avoid a threshold (FR-48).
| Action | What happens |
|---|---|
| Allow and record | The transfer goes out; the match is recorded |
| Warn | The sender confirms, removes files or cancels. An API key can't confirm (FR-42). |
| Require approval | The sender asks with a justification; an approver, never the sender, approves or rejects (FR-43). A rule can require two approvers (FR-44). |
| Block | The transfer is held. The sender removes the file or cancels. |
Approvers see recipients, file names, findings and the justification, never contents. Requests expire after the tenant's timeout (1 hour to 7 days, default 72 hours).
Trusted domains
A tenant admin lists trusted recipient domains, such as the company's own and its partners' (FR-45). A rule can apply only to untrusted recipients, so the same findings can warn for a partner and need approval for anyone else.
Default policy and monitor mode
New tenants start in enforce mode with a default policy that warns on My Numbers, payment cards, credentials and private keys, personal data in bulk, files not fully inspected, and new recipient domains. Nothing needs approval or is blocked until a tenant admin changes the rules. In monitor mode every decision is recorded and nothing is warned, held or blocked (FR-52), so a tenant can test a policy first.
Formats and limits
Inspection covers (NFR-24):
- Text, CSV and TSV in UTF-8, UTF-16, Shift_JIS (CP932), EUC-JP and ISO-2022-JP
- Office Open XML and OpenDocument text, spreadsheets and presentations
- PDF text layers
- zip, gzip and tar archives up to 3 levels deep
Per file: up to 2,000,000,000 bytes, 10,000 archive members, 4 GiB decompressed (100:1 ratio per member), 256 MiB of text, 5,000 PDF pages and 10 minutes of CPU.
A file that can't be fully inspected is never treated as having no findings (FR-47). It carries its reason (encrypted, no text layer, unsupported type, too large, limit exceeded, malformed), and the tenant's rules decide. Not in v1: OCR, legacy binary Office files, 7z, RAR and LZH, email files, names and addresses.
Accuracy and privacy
Matched values are never stored (NFR-26): not in the database, logs, traces, metrics, queue messages, audit records, emails or error reports. A finding keeps the detector, counts, at most 10 location hints and at most 3 masked previews (FR-53). Previews keep at most the last 4 characters of an identifier, and nothing of a My Number or a secret. Only the file's owner and its approvers see hints and previews; tenant admins see counts. A canary test fails if a synthetic value appears anywhere.
Why our own engine
ADR-0022 compared Amazon Macie, Amazon Comprehend, Microsoft Presidio and hosted DLP APIs. None detects Japanese identifiers except hosted APIs, which would send file contents outside AWS, and Macie's scheduled jobs can't gate a transfer. So the service runs its own detectors in sandboxed pods with no credentials and no network. The trade-off: accuracy is only as good as its own tests.
Source: PRD, DLP detectors, ADR-0022, Architecture