What flows through, what gets blocked, what gets logged

If an AI agent inside your company can talk to Jira, Drive, Gmail, BigQuery, Slack, and 15 other services through one endpoint, the security question is no longer "can it do useful work" — it is "what is it actually doing, and how would we know if it started doing the wrong thing?"

This is not a hypothetical concern. Anthropic's own agentic-misalignment research shows leading models, including Claude, choosing data exfiltration over the alternative when their goals are challenged. Not because they are evil — because the cost-benefit lands there in some narrow scenarios. The reasonable response to that is not "do not give agents access to data." The reasonable response is "make sure the agent's access is logged, capped, and observable in real time."

That is what mcpgate's compliance surface is for. Four layers stacked on the same audit trail.

The audit log is not a sidecar — it is the foundation

Every request, every response, every hook firing, every policy decision: one row in the audit log. Actor (pseudonymized), service, action, inbound bytes, outbound bytes, result code, timestamp. No payloads by default — the audit log records that something happened and how big it was, not the contents.

This split matters. An audit log full of payload bodies is itself a privacy hazard — an attacker who exfiltrates the audit log gets a second copy of everything. A byte-count audit log is operationally just as useful for forensic work and structurally safer to keep.

A normal row looks like this:

actor_a7f2b9c1 | google_workspace | drive_files_export |
  in: 2.4 KB | out: 47.2 MB | result: 200 | 2026‑05‑25T03:14:22Z

The actor is a stable pseudonym, the upstream service and action are named, the byte counts are real, and the result code is whatever the upstream returned. That single row is enough to ask "who exported 47 MB out of Drive at 3 am" and start a real investigation, without the row itself containing one byte of the exported content. The Throughput dashboard reads this exact shape, grouped and sorted — the abstraction collapses cleanly because the underlying data was designed for it.

1. Policy hooks: prevent before logging

Hooks run before dispatch. They see the actor, the action, the parameters, the body. They can deny, enrich, or route. They reload on file change — no gateway restart needed.

Two scopes stack: company-wide hooks in config/tool_hooks.yaml apply to everyone; per-user hooks overlay them with per-actor logic. A read-only research intern can list_issues but not delete_project; the engineer working on the same project can. The difference is one YAML rule, not a forked gateway.

A concrete example — deny all destructive actions for the research-interns group:

hook:
  match:
    actor_group: research_interns
    action_pattern: "*_delete | *_archive | *_revoke"
  effect: deny
  message: "Read-only access. Ask your buddy if you need this run."

Six lines, one file edit, hot-reloaded. The same hook would be a forked gateway in most competitor architectures, because their policy lives in code rather than YAML.

Common patterns the hook layer covers:

• Deny destructive actions for a specific group of users (above)
• Require confirmed=true on any action whose path matches /delete, /revoke, /terminate
• Auto-enrich Jira issue descriptions with project templates and Slack-thread back-links
• Block based on PII match — if the outbound payload contains a customer email not in the allowlist, deny before the upstream call

The prevention layer is the cheapest place to enforce policy. A request that is denied here never hits the upstream, never reaches the LLM's view of the response, never costs you a real-world API call. Hooks are also the layer that dynamic action discovery piggybacks on for its risk-tier classification — read actions activate autonomously, write actions emit audit, destructive actions require explicit confirmation.

2. PII sanitization: shape what the LLM is allowed to see

Emails, names, phone numbers, configurable custom patterns — replaced with stable pseudonyms before the payload leaves the gateway toward the LLM. The replacement map is AES-GCM-encrypted with a 24-hour TTL. On the way back, when the LLM's tool call hits the upstream, the rehydration step puts the real values back so the upstream API sees what it expects.

This is what makes the audit log itself safe to keep at byte-count granularity. The audit log writes pseudonyms. An exfiltrated audit dump reveals patterns, not people. That is a meaningful security property and one of the reasons we built the sanitizer as a foundational layer rather than an opt-in filter.

The flip side: the LLM's reasoning operates on pseudonyms. employee_a7f2b9 talks to customer_3d8e1c rather than to real names. For the tool-execution loop this is fine — the rehydration step restores reality before the upstream call. For human-readable summaries, the LLM can be asked to re-render with real names available, with a hook that scopes which actors are allowed to do that.

3. Throughput: a volume-aware lens on the audit log

This is the layer that took us a while to position correctly internally. Throughput is not an ops dashboard, it is a compliance lens.

The dashboard groups the audit log by actor and time window, sorted by outbound byte volume. A sudden 50 MB outbound spike at 3 am from one user is one row at the top of the page. Without this view, that same data is a needle in a 50,000-line audit log haystack — technically findable, operationally invisible.

The design intent is data-exfiltration detection. The fact that an admin can also see "who is the heavy user this month" is a side-effect, not the purpose. We initially wrote the user-facing copy as if it were a generic ops feature; we have since rewritten it because the buyer is security, not finance, and conflating the two diluted both.

What Throughput surfaces, beyond the raw byte count:

• Per-user volume rolled up to hour / day / week (so a steady drip is as visible as a spike)
• Per-service breakdown — was the volume in Drive downloads, Gmail attachments, BigQuery exports, or something narrower?
• Anomaly markers when a user crosses a configurable threshold — the threshold-editor accepts sub-megabyte values, so you can alert on small but unusual volumes (a single 200 KB Slack DM with a CSV attachment, say)

4. Slack alerts: real-time, not post-mortem

Threshold breach posts to the configured Slack channel with a deep-link straight to the audit row. The difference between "we noticed Tuesday" and "the security team got a Slack ping at 3:07 am" is the difference between a leak and a contained incident.

Configure thresholds per user, per service, or org-wide. The same threshold model is used for the inverse case — alerting when traffic is unexpectedly low (a critical workflow that should be firing 100 actions/day and isn't) — though that is more of an ops than compliance use.

How this maps to the compliance frameworks people are actually being audited against

The four layers above were not designed against a specific framework checklist — they were designed against the underlying question "what would we need to detect, prevent, and prove after the fact." The framework alignment falls out of that, but it is worth making the mapping explicit because procurement asks for it.

• EU AI Act, Article 12 (record-keeping). High-risk AI systems must enable "the automatic recording of events ('logs') over the lifetime of the system." The audit log is built precisely for this — every action, every actor, every outcome, retained per your configured window (default 90 days, extensible to multi-year). The byte-count split keeps the log itself from becoming the data-protection liability that bigger payload logs become.
• GDPR, Article 30 (records of processing activities). Controllers must maintain a record of processing categories, recipients, retention periods, and security measures. The audit log plus the pseudonym-mapping decision rows together cover all four columns. Pseudonymization is itself a GDPR Article 32 security measure, and the 24-hour TTL on the mapping bounds the window in which the link can be reconstructed.
• SOC2 CC7.2 (system monitoring). "The entity monitors system components and the operation of those components for anomalies." Per-user Throughput thresholds with Slack alerts on breach is the canonical pattern for satisfying this control on an AI-tool surface — auditors look for documented thresholds, evidence of alert firing, and timestamps of response.
• NIST AI Risk Management Framework. The four-layer surface lines up with the Govern-Map-Measure-Manage loop: policy hooks are Govern, audit captures are Map, throughput rollups are Measure, threshold-driven alerts plus the deny effect close the Manage loop.

This mapping is not a certification — mcpgate is not SOC2-certified, the EU AI Act has not been enforcement-tested, and the GDPR mapping is your DPO's responsibility, not ours. What we can offer is a substrate that maps cleanly to the structures auditors expect to see, so the compliance conversation is "here is how our architecture answers your control" rather than "we will get back to you."

The thing nobody else does this way

Plenty of gateways have audit logs. Plenty have PII redaction. Some have policy hooks. A few have throughput dashboards. The combination of all four built on the same audit trail, with the throughput dashboard explicitly designed as a DLP lens rather than an ops metric, is what we have not seen elsewhere.

The structural property that makes this work: the audit log writes byte counts, not payloads, and uses the same pseudonym layer as the LLM. That means the throughput dashboard can be fully informative without the audit log being a second copy of every payload. PII risk and exfiltration visibility do not have to trade off against each other.

What is open

Two things we are honest about.

PII sanitization config is still narrow. The built-in pattern set (email, phone, person-name) plus custom regex covers the common cases, but enterprise buyers regularly ask for per-field policies (e.g., "redact the salary field on this specific Jira project but not on others") and per-user opt-outs. That work is on the roadmap.

The Throughput dashboard is single-tenant by design. A SaaS-style aggregation across customers, with anonymized benchmarks for "is this volume normal for a team your size", would be a useful future surface but is not what we ship today. The reason: it would require sharing telemetry off-host, which is the exact thing self-hosted compliance buyers reject by reflex.

Where to go next

The Compliance admin reference walks through every screen with screenshots and configuration examples. If you want to skip ahead to playing with it, the public demo shows the gateway from the end-user side, and the two-minute install gives you a self-hosted instance you can actually log into as admin.

If you have a specific compliance case the four layers above do not cover — tell us. The harder cases are the most useful inputs to the roadmap.