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, and any AI Guardrail that screens requests gets a verdict on the same arguments.
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. If an AI Guardrail screens responses, the result is evaluated before tool code reads it; otherwise it 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

Three 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.

AI Guardrails

An instruction in plain English instead of a pattern, judged by an evaluator on each call it applies to. Use one when what you want stopped is a topic or a judgment call, such as an unannounced project or credentials showing up in a tool result, rather than something with a recognizable shape.

Each guardrail has:

An instruction, one or two sentences describing what to catch
An action, Block or Log. Redaction needs a matched span, so it isn’t offered.
The passes it screens, requests before the call runs, responses after the third party answers, or both
Optional scoping to specific Tool Packs and to user Groups synced from your identity provider

Guardrails are the one rule type that screens responses, so they are what catches a secret or an unreleased detail arriving from the third party rather than leaving for it. They also fail open: when the evaluator errors or is unsure, the call proceeds.

Guardrails are available to every organization and screen nothing until you write one. For the instruction-writing guidance and three worked examples, see AI Guardrails.

The three actions

Each entity rule and custom regex rule has an action per direction. They mean exactly what they sound like. AI Guardrails use a narrower pair, Block or Log.

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 something different, override on the Tool Pack’s Rules tab.

A pack’s overrides are authoritative for that pack. An override can change the action of an org-level rule, scan for an entity on one pack that no org-level rule covers, or switch an entity off for one pack while the org-level rule keeps applying everywhere else. What the pack’s Rules tab shows is what runs for that pack.

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 Guardrail tester takes a sample input and streams back what every rule type decided, entity and regex matches with their confidence scores plus each guardrail’s verdict in both directions. 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.