Enterprise · AI Data Firewall
The AI data firewall between your data and every model
PortEden sits between AI agents and your providers — Gmail, Calendar, Drive, Outlook, Slack — and strips PII, secrets, and HIPAA identifiers before any prompt reaches Claude, ChatGPT, Copilot, or Gemini. Context hygiene cuts token usage roughly 80%.
Three pillars of enterprise AI governance
Redacted at egress
All 18 HIPAA Safe Harbor identifiers, PCI-DSS payment data, GDPR personal data, and secrets (API keys, JWTs, OAuth tokens, AWS keys, GitHub PATs, private keys) are masked before any prompt leaves your perimeter. ~120 deterministic patterns plus tunable NER. Custom rules supported.
Context hygiene
Clean, minimal data delivered to agents — flat structures, no metadata noise, no nested junk the model doesn't need. Result: ~80% reduction in tokens-in, fewer hallucinations on the way out, lower bills.
Re-hydrated in the user's browser
Structure-preserving placeholders are swapped back to real values client-side, so the user sees the original data. The model never does. Defense in depth — even a leaked transcript carries placeholders, not PHI.
Compliance map
How a data firewall helps you satisfy the controls your auditors read
| Requirement | What PortEden does | Evidence |
|---|---|---|
| HIPAA Safe Harbor — 45 CFR §164.514(b)(2) — 18 identifiers | All 18 identifiers (names, geographic subdivisions, dates, phone, fax, email, SSN, MRN, beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers, device identifiers, URLs, IPs, biometric identifiers, full-face photos, other unique identifiers) masked at egress. | Per-request redaction log · 18-identifier coverage report |
| PCI-DSS — Cardholder data protection | PAN, CVV, and track data detected via Luhn-validated patterns and replaced with structure-preserving placeholders before any model sees the prompt. | Pre-egress masking · structure-preserving placeholders |
| GDPR Art. 4 / Art. 5(1)(f) — Personal data definition & integrity | Pseudonymization at the AI/data boundary. Custom rules for EU-specific identifiers (national ID, VAT, IBAN, NHS number). | DPA · pseudonymization at the AI/data boundary |
| GDPR Art. 32 — Security of processing (pseudonymization) | Pseudonymization with structure preservation: the model sees "PERSON_A1" and "EMAIL_B3" rather than the values. Re-hydration happens in the user's browser, not the model context. | Browser-side re-hydration · model never sees real values |
| CCPA §1798.140 — Sale & sharing limits | Personal data is masked before egress, eliminating model-vendor exposure. Audit trail shows zero personal data in any inference call. | Per-inference audit log · zero-PII assertion exportable |
| NIST 800-53 SC-7 / SC-28 — Boundary protection & data at rest | Egress filtering at the AI boundary. Encrypted in transit (TLS 1.3) and at rest (AES-256). Tenant-isolated key material. | AI-boundary egress filter · TLS 1.3 + AES-256 · tenant-isolated keys |
| EU AI Act Art. 10 — Data and data governance (high-risk systems) | Documented data preparation pipeline: redaction rules, pattern definitions, NER models, and version history are auditable artifacts. | Versioned redaction rules · pattern + NER definitions exportable |
Built for procurement
DPA available
Subprocessor list
SIG / CAIQ pre-filled
Pen-test report on request
Book a demo
Talk to our enterprise team
30-minute discovery call. Bring your security questionnaire.
Frequently Asked Questions
What is an AI data firewall?
An AI data firewall is a control layer that sits between your AI clients and your data providers, inspecting every request and stripping data the model shouldn't see. Unlike network firewalls (which look at packets) or DLP (which scans files), an AI data firewall is content-aware at the request level — it knows which fields the model is asking for, masks the sensitive ones, and re-hydrates them on the way back so users see the real values without the model ever doing so.
Does redaction break the AI's usefulness?
No — the model still sees structure ("EMAIL_A1 sent meeting invite to PERSON_B3 about MEDICATION_C2"), so summaries, action items, and routing decisions all still work. Re-hydration happens in the user's browser, so the user sees the real names, emails, and medications. In production, content hygiene improves answer quality by removing metadata noise the model doesn't need.
What gets redacted out of the box?
All 18 HIPAA Safe Harbor identifiers; PCI-DSS payment card data (Luhn-validated); GDPR Art. 4 personal data (names, IDs, contact details, location); secrets (API keys, JWTs, OAuth tokens, AWS access keys, GitHub PATs, SSH private keys); and ~120 deterministic patterns with tunable NER overlays. Custom rules — for case numbers, internal project codes, contract IDs — are added per-tenant.
Can I add custom redaction rules?
Yes. Custom rules can be expressed as regex patterns, named-entity types, or tagged fields. They run as additional layers on top of the deterministic patterns, with per-rule audit so you can prove which rules fired on which requests during an audit.
Does this work for both inbound and outbound AI traffic?
Yes. Outbound: prompts and tool inputs are redacted before they reach Claude / ChatGPT / Copilot / Gemini. Inbound: model responses are scanned for prompt injection and unexpected data exfiltration before they're returned to the user. The audit trail captures both directions.
Where does redaction run — your servers or ours?
By default, redaction runs in PortEden's tenant-isolated infrastructure. For regulated deployments, redaction can run in your VPC (Compliance and Enterprise tiers) or as an on-prem appliance. Re-hydration always runs in the user's browser, so neither PortEden nor the model vendor ever sees the unredacted values together.
Ready to govern AI across your organization?
Book a discovery call. Bring your security questionnaire — DPA, subprocessor list, and pen-test summary available on request.