Security Gateway

The Security Gateway scans tool arguments against rules you configure. It runs on every call, after the agent issues tools/call and before Agent Handler dispatches the request to the third party. If a rule fires, the matched value is allowed through (and logged), redacted, or the call is blocked entirely.

A bare MCP server hands the model whatever the third party returns. That’s fine for a personal agent on your own GitHub; it isn’t when your agent has access to a customer’s CRM, a hospital’s patient records, or a payments database. The Gateway is where data-handling policy gets enforced - the artifact your security review will read.

Where it runs

The Gateway sits inline on the request path - it scans what the agent sends before that data leaves Agent Handler for the third party.

The agent calls a tool. Your bearer token resolves to an organization, a Tool Pack, and a Registered User.
Scan the request. The Gateway evaluates every active rule against the tool arguments. Matches are allowed, redacted, or blocked according to the rule’s action.
If the call wasn’t blocked, the Connector dispatches the request to the third party with the (possibly redacted) arguments and the Registered User’s credentials.
The third party responds. The result returns to the agent unchanged.

Every detection - whether allowed, redacted, or blocked - is recorded as a violation row in Alerts. A blocked call returns a clean error to the agent and never reaches the third party. A redacted call still reaches the third party, but with matched values replaced by placeholders.

What it scans for

Two rule types, configurable independently.

Standard Entity Rules

Pre-trained detectors for the categories most regulations care about. Configurable per organization, with overrides per Tool Pack. Each entity has one action - applied to tool arguments before they leave Agent Handler.

The supported entity types:

Personal identity. Person name, email address, phone number, location, nationality / religious / political Group affiliation.
Government and financial IDs. US Social Security Number, US ITIN, US Passport, US Driver’s License, US Bank Number, IBAN.
Payment. Credit card number, crypto wallet address.
Health. US medical license number.
Network. IP address, URL.
Other. Date and time.

Detection runs on a Presidio-based stack underneath. Each match comes with a confidence score; you can lift the threshold per rule if you’re seeing false positives, or lower it if you need higher recall. Regional toggles let you scope detectors to the regions you operate in (US-only patterns won’t fire on EU data, and vice versa).

For the full configuration of each entity, see Standard Entity Rules.

Custom Regex Rules

Your patterns. Useful for entities the standard detectors don’t cover - internal customer IDs, project codes, employee numbers, anything proprietary to your business.

Each custom rule has:

A regex pattern.
A confidence score - what to assign each match before threshold comparison.
Optional context keywords - extra signals near the match that confirm sensitivity. A 9-digit number near the word “SSN” is more likely sensitive than the same 9-digit number near “invoice number.”
An action to take when the rule matches in tool arguments.

For three worked examples, see Custom Regex Rules.

The three actions

Each rule has an action per direction. They mean exactly what they sound like.

Action	What happens
Allow	The call goes through unchanged. The detection is logged as a violation but nothing is altered or stopped. Use this for visibility without enforcement.
Redact	The call goes through with the matched value replaced by a placeholder (`[REDACTED:EMAIL]`, for example). The third party never sees the original.
Block	The call is canceled. The third party is never contacted. The agent receives an error indicating that a security rule fired.

Allow is for monitoring. Redact is the right default for most categories - it preserves the agent’s ability to do its job while keeping sensitive data inside Agent Handler. Block is for the categories you absolutely don’t want crossing the boundary in either direction (cardholder data, SSNs in most contexts, anything regulated for your industry).

Per-tool-pack overrides

Rules are defined once at the organization level. That’s the right default for most teams: one consistent policy across the product. When one agent surface legitimately needs different rules, override on the Tool Pack’s Rules tab. The org-level rule still exists; the override changes the action for that pack only.

Common pattern: block SSNs outbound at the org level, override to allow on a payroll Tool Pack that legitimately reads them from your HRIS.

Violations and alerts

Every detection - allow, redact, or block - produces a violation record. The Alerts dashboard shows them with three views: a timeseries of violations over time, a breakdown by rule and entity, and a per-violation table you can drill into.

From an alert you can jump to the underlying tool call, see exactly which arguments or which fields of the result matched, and see the Registered User the call ran for. Useful when you need to investigate “why is this rule firing on legitimate traffic” or “did this user trigger anything unusual today.”

For walking the dashboard end to end, see Violations and alerts.

Testing rules before they go live

Custom rules in particular benefit from being tested before they’re enforced on real traffic. The dashboard’s Rule Tester takes a sample input and shows you which entities and rules match. Use it to confirm a regex matches the patterns you expect, doesn’t match the ones you don’t, and the confidence score lands where you want it.

What it isn’t

The Gateway scans data flowing through tool calls. It doesn’t decide which user can call which tool - that’s what Tool Packs and Registered Users are for. It isn’t a substitute for end-user consent and contracts when handling regulated data; it’s the technical enforcement layer underneath those agreements.

Configure detection per entity in Standard Entity Rules.