What did the agent do on my behalf?
Agents stopped just talking and started doing: reading records, filing tickets, moving money. Every one of those actions travels through an MCP tool call, and most teams cannot answer the question above with evidence. Scrutari puts a governed gateway between your agents and their tools, so every call is allow-listed, redacted, and signed on the way through.
POST /v1/mcp/{server_id}works with Claude Desktop, IDEs, agent frameworksstreaming passthrough, zero bufferingWhat one tool call passes through
Caller identity
The agent authenticates with a scoped Scrutari API key (mcp:invoke). One key per agent means every action attributes to exactly one identity, and an inference key can never invoke tools.
Per-server allow-list
Each registered MCP server carries its own tool allow-list. A call to a tool outside the list never reaches the upstream; the refusal itself is recorded.
Redaction at the boundary
PHI detection runs on the call before it leaves your perimeter, with the same detectors and modes as the AI gateway: audit, redact, or refuse.
Signed record
Every tools/call writes a signed, Merkle-anchored audit row, off the hot path so it costs the call nothing. The record is tamper-evident and exportable; the offline verifier proves nobody rewrote it.
Governed upstream auth
Downstream credentials live KV-enveloped in the gateway, never in the agent. Upstreams that speak OAuth get RFC 8693 on-behalf-of token exchange, so the tool sees a properly scoped identity instead of a shared secret.
Post-quantum transport
The whole path rides hybrid X25519 + ML-KEM-768 TLS, the same edge as everything else Scrutari carries.
Why this exists
The industry consensus is that agent tool use is where the risk concentrates; it is why the big security platforms are buying AI gateways. Our answer is narrower and verifiable: govern the tool boundary, sign what happened, and let anyone check the record offline. We run our own outreach fleet through it in early access.