Governance: RBAC, redaction, and per-tool config

The gateway only ever narrows what the downstream already permits - it never widens access. You layer controls at the connector, the access key, and the per-member level.

What you can control

• RBAC/ABAC: scope each access key to specific servers, tools, and a read-only or allow/deny policy.
• Tool exposure: hide whole connectors or individual tools from the catalog.
• PHI/PII redaction: mask sensitive fields in results by name or detected category before they reach the agent.
• Per-tool config: override a tool's description (prompt) and block or redact individual input/output fields.
• Audit: every tool call, connect, disconnect, and config change is recorded in a tamper-evident log.

Per-tool field rules

For any tool you can remove input fields from the schema agents see (and strip them from calls) and remove output fields from results - matched by name. This lets you expose a tool while keeping sensitive parameters and columns out of the agent's reach.

Content-aware treatment (PHI/PII/PCI/secrets)

Beyond field names, the gateway detects sensitive values by content category - secret (API keys, tokens, private keys), PCI (card numbers), PII (SSN, email, IP), and PHI - and treats them automatically. On reads it masks matching values in results; on writes it blocks calls whose arguments contain a blocked category. This works even on MCP tools with no schema.

Reusable policy templates

Define a policy once and apply it to many members and agent keys. Built-in presets include Read-only, Read-only (no PII), HIPAA PHI-safe, PCI (no card data), No secrets, and GDPR PII minimization.

Members vs agents

• Members: an admin sets a per-member ceiling; it intersects with the member's own tool selection so the ceiling can only restrict, never widen.
• Agent keys: each key carries a scope (which connectors), a role, and an attached or referenced policy.