How does Enforgate stop tool responses from leaking secrets and PII?
A connected tool can hand back more than the agent asked for: a stack trace with an API key in it, a database row with a customer's SSN. Enforgate's DLP scanner checks every tool response for known-sensitive patterns before it reaches the agent, and can block or redact it on the spot.
What it scans for
The scanner runs a fixed set of deterministic regex rules against every text item in a tool's response: no model inference, so it's fast and has no external dependency. Built in:
- Credentials: Enforgate API keys (
sk-,bwb_,bws_), AWS access keys, GitHub tokens, Slack tokens, and genericBearerheaders. - PII: credit card numbers (Luhn-candidate), US Social Security numbers, and email addresses.
Non-text content (images, embedded resources/blobs) is left untouched. The scanner only inspects text. Each string is capped at 50,000 characters scanned, so a huge response can't be used to stall the gateway.
Block or redact
Turn the scanner on under Settings → Features → Response DLP scan (off by default; opt in once you've checked it against your connected tools' real responses). Once on, pick the org-wide action:
- Block: the agent gets an error instead of the real response. Use this when a match should never reach the agent under any circumstance.
- Redact: matched substrings are replaced with
[REDACTED:<pattern>]and the scrubbed response is passed through, so the agent still gets the rest of the data.
Bring your own patterns
The built-in ruleset won't know about your internal token formats or other org-specific sensitive strings. Add custom regex patterns under the same Features tab (“Custom DLP patterns”); they're merged with the built-in rules at scan time. An invalid regex is rejected when you save it, but if one somehow gets saved anyway, the scanner skips it silently rather than disabling DLP entirely.
Per-connected-tool override
DLP is an org-wide setting by default, but a specific connected tool can override it: open its entry on Connected Tools and edit the DLP override to force the scanner on or off (with its own action) for just that tool, regardless of the org default. Useful when one upstream is known to only ever return synthetic test data, or the opposite: one upstream handles real customer PII and should always redact even if the org default is off.
The scanner fails open: if it hits an internal error, the response passes through unmodified rather than silently blocking a valid result. The policy engine and your connected-tool choices remain the real security boundary. DLP is a second layer that catches accidental data exposure in responses, not a substitute for not connecting untrusted tools.
Related
DLP scans what comes back from a tool. For scanning what an agent sends into a tool call, see prompt injection scanning.