The agent authenticates through Auth0 and presents a short lived OIDC JWT to the Gatekeeper gateway over standard MCP transport.
The agent calls a tool by name. The gateway canonicalizes the payload (JCS, RFC 8785) and computes a SHA 256 commitment hash that binds any approval to these exact parameters.
Four policy layers evaluate the call in a sandboxed isolate: org wide, org plus service, user wide, and user plus service. All must allow; lower layers can only narrow.
On allow, the enclave requests the data key from KMS with a fresh attestation document. KMS verifies the PCR measurement before releasing anything.
The credential is decrypted inside the enclave and injected into the outbound HTTPS request. Plaintext exists in enclave memory for microseconds.
The downstream service responds and the agent receives the result.
Managed MCP endpoint. Terminates TLS 1.3, computes commitment hashes, and runs the policy chain.
The trusted execution boundary. Decryption and enforcement happen inside; plaintext never crosses to the host process.
The key policy gates decryption on PCR attestation. Each tenant can bring its own customer master key.
Keys are derived in KMS and bound to tenant info. No long lived gateway API keys.
Every decision, decryption, and approval, hash chained and exportable to customer controlled storage.
Prompt injection cannot exfiltrate credentials; the agent never holds them.
In hybrid or on premises deployments, tenant isolation is structural. Cross tenant decryption fails at the KMS policy layer, not in application code.
Bearer tokens leave the enclave only inside TLS to the downstream service, which is the recipient by definition.
Fail closed semantics apply everywhere: a policy error, timeout, or KMS outage denies the call. The system never allows on inability to check.
Walk through the trust model, policy design, and rollout with our security and solutions team.