Security Gateway

Scans the tool calls your employees' AI makes against your data rules, then logs, redacts, or blocks

The Security Gateway reads every tool call an employee’s AI client makes and compares it against rules you configure. It runs inline: after the client issues tools/call and before Workforce dispatches the request to Slack, Jira, Salesforce, or whatever the Connector talks to. On a match the call is logged and allowed, the matched value is replaced, or the call is stopped.

This is the answer to the question your security review will ask about employee AI: an employee can paste a customer list into a prompt and have their agent write it into a third-party ticket, and nothing in the client stops them. The Security Gateway is where that policy lives.

It governs tool traffic. Rules on model traffic, what employees send a model and what comes back, are configured separately in Model guardrails, so look there rather than here for prompt and completion scanning.

Where it runs

  1. The employee’s client calls a tool. Its token resolves to your organization, the employee, and the tools their Group grants.
  2. Scan the request. Every active entity and regex rule is evaluated against the tool arguments, and any AI Guardrail that screens requests gets a verdict on those same arguments. Matches are logged, redacted, or blocked according to the rule’s action.
  3. If the call was not blocked, the Connector dispatches it to the third party with the (possibly redacted) arguments and the employee’s own credentials.
  4. The third party responds. If an AI Guardrail screens responses, the result is judged before it reaches the client. Otherwise it comes back unchanged.

Every detection, whatever the action, is recorded as a violation in Alerts. A blocked call returns a clean error to the client and never reaches the third party. A redacted call does reach the third party, with matched values replaced by placeholders.

What it scans for

Three rule types, configured independently.

Standard Entity Rules

Pre-trained detectors for the categories most regulations care about: names and emails, government and financial IDs, payment data, health identifiers, network identifiers. Configured per organization, with overrides per Tool Pack, and applied to tool arguments before they leave Workforce.

See Standard Entity Rules for the entity catalog.

Custom Regex Rules

Your patterns, for the things no general detector knows about: internal customer IDs, project codes, employee numbers. Each rule carries a name, a pattern, optional context keywords that confirm sensitivity, and an action.

See Custom Regex Rules for three worked examples.

AI Guardrails

An instruction in plain English instead of a pattern, judged by an evaluator on each call it applies to. Reach for one when what you want stopped is a topic or a judgment call, an unannounced project or credentials showing up in a tool result, rather than something with a recognizable shape. Guardrails are the only rule type that can screen a tool’s result as well as its arguments, and they can be scoped to Tool Packs and to Groups from your identity provider.

See AI Guardrails for how to write an instruction the evaluator can act on.

Log, redact, or block

Entity and regex rules take one of three actions. AI Guardrails use the narrower pair, Block or Log, because redaction needs a matched span to replace and a guardrail verdict is a judgment about the call as a whole.

ActionWhat happens
LogThe call goes through unchanged. The detection is recorded as a violation but nothing is altered or stopped. Use it for visibility without enforcement.
RedactThe call goes through with the matched value replaced by a placeholder, [REDACTED:EMAIL] for example. The third party never sees the original.
BlockThe call is canceled. The third party is never contacted, and the employee’s client receives an error saying a security rule fired.

Log is how you size a rule before you enforce it: turn it on, watch a week of real traffic, then decide. Redact is the right default for most categories, because it keeps the AI useful while keeping the data inside Workforce. Block is for the categories you do not want crossing the boundary at all.

Per-Tool-Pack overrides

Rules are defined once at the organization level, which is the right default: one consistent policy for everyone. When one Tool Pack legitimately needs something different, override it on that pack’s Rules tab.

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

The common pattern: block government IDs organization-wide, and override to redact on the payroll pack that legitimately reads them out of your HRIS.

What it isn’t

The Security Gateway scans data flowing through tool calls. It does not decide which employee can call which tool, which is what Groups and Tool Packs do in Groups and access. And it is the technical enforcement layer under your data-handling agreements, not a substitute for them.

Next steps