> This page is for Workforce.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.merge.dev/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server.

# Security Gateway

> How the Workforce Security Gateway works: where it sits in the tool call path, the three rule types, what log, redact, and block do, and per-Tool-Pack overrides.

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](/merge-workforce/models/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](https://wf-develop.merge.dev/security/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](/merge-workforce/security/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](/merge-workforce/security/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](/merge-workforce/security/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.

| Action     | What happens                                                                                                                                            |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Log**    | The call goes through unchanged. The detection is recorded as a violation but nothing is altered or stopped. Use it 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, 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](/merge-workforce/provisioning/groups). And it is the technical enforcement layer under your data-handling agreements, not a substitute for them.

## Next steps

#### [Standard Entity Rules](/merge-workforce/security/standard-entity-rules)

The entity catalog, what each detector matches, and how to set its action

#### [Custom Regex Rules](/merge-workforce/security/custom-regex-rules)

Detect the identifiers only your business uses, with context keywords to keep them precise

#### [AI Guardrails](/merge-workforce/security/ai-guardrails)

Catch a topic or a judgment call by describing it in a sentence

#### [Violations and alerts](/merge-workforce/security/violations-and-alerts)

Investigate what your rules are catching and find the false positives

#### [Guardrail tester](/merge-workforce/security/rule-tester)

Run a sample through the whole Gateway before a rule sees real traffic