THE GOVERNED MCP GATEWAY SELF-HOSTED · METADATA-ONLY · NOTHING SECRET PAST THE BROKER BY DIGITALAPI.AI

Security & trust

Written for your security review.

The answers your reviewers will ask for, stated plainly: where it runs, what it retains, how secrets move, who can call what, and how you shut it down. Including a section on what we don't claim yet.

Book a walkthrough Open the docs

The posture, at a glance

Eight questions, eight answers. Expand the ones your review cares about.

Each row is the one-line answer your reviewers will ask for. The detail underneath is the full position — same content, your pace.

01Deployment & residencyAll required runtime paths run in your infrastructure — no mandatory vendor egress.
  • Durable state and audit metadata live in your PostgreSQL; hot session state in your Valkey — nothing durable outside your infrastructure
  • Telemetry via your OpenTelemetry collector; audit export to your SIEM — you choose the sinks
  • Single-tenant deployment in the current release; self-hosted or hybrid, you pick the mode
02Data handlingMetadata-only: the record is the decision, never the content.
  • Retained: resource and owner IDs, policy versions, credential modes, timestamps, status and reason codes
  • Never retained: secrets, raw tokens, prompts, tool payloads, request/response bodies
  • Payload logging disabled or redacted by default; retention lives in your PostgreSQL under your controls
03Secrets & credentialsAgents hold opaque references — there is no secret on their side to leak.
  • A Vault-compatible broker resolves credentials server-side per call and injects them on the backend leg
  • Four modes matched to the caller: service-account, user-delegated OAuth, agent-scoped, workload-mapped
  • Token-passthrough and confused-deputy abuse addressed at the tool-call boundary; automated no-secret release gates
  • Not a secret manager — the broker works against the one you already run, it doesn't replace it
04Identity & accessYour IdP stays authoritative; every caller resolves to an owned identity; deny always wins.
  • People via your IdP (OIDC, SAML); services via workload identity mapping; agents as first-class identities with required owners
  • No anonymous production access
  • Cedar policy, default deny; explicit deny overrides allow — always; every decision carries a policy version and reason code
  • Discovery itself is access-controlled: what an agent can't call, it can't see
05Audit & monitoringEvery decision on the record, with its policy version — none of the content.
  • Evented: authentication, policy decisions, credential mode, session lifecycle, tool calls, admin changes, revocations
  • Each event carries resource and owner IDs, policy version, credential mode, timestamp, status and reason codes
  • Flows to your SIEM and your OpenTelemetry collector — payloads and secrets never appear in any of it
AUDIT EVENTSAMPLE — ILLUSTRATIVE
event · tool.call.denied
actor · agent:support-bot (owner: team-cx)
resource · tool:crm_update
decision · DENY · reason_code · EXPLICIT_DENY_PROD_MUTATION
policy_version · cedar-v3 · credential_mode · user-delegated
payload · — never logged

SAMPLE — illustrative event shape. Real events carry your IDs; they never carry your content.

06Revocation & incidentsRevocation reaches active sessions — not just the next call.
  • Six revocable objects — tools, credentials, connectors, servers, agents, sessions — each from one place
  • An agent mid-session doesn't get to finish what you just revoked
  • Emergency disable previews its blast radius before it fires, and requires a reason on the record
07Network & backendsOnly registered backends are reachable; SSRF checks run before any upstream attempt.
  • Host allowlists per backend — an unregistered host is unreachable no matter what the request says
  • Method/path mapping, schema validation, timeout and size limits before the upstream call
  • TLS on the gateway, connector, and backend paths
08Supply chainSigned, verifiable releases on a dependency budget small enough to actually review.
  • Helm packaging, checksum manifests, Cosign signatures, SBOM per release
  • Release evidence is independently verifiable before anything reaches your cluster
  • The whole dependency budget: Rust data plane · Cedar policy · Go CLI · PostgreSQL · Valkey · OpenTelemetry

The evidence packet

Don't trust the page. Verify the release.

Every release ships with an evidence packet your team verifies on your own infrastructure — without us in the room. This is the drawing to paste into your review doc.

EVERY CLAIM MAPS TO SOMETHING YOUR TEAM CAN RUN EVIDENCE PACKET SHIPS WITH EVERY RELEASE COSIGN SIGNATURE — verify the build is ours SBOM — every dependency, per release CHECKSUM MANIFEST — bit-for-bit verifiable NO-SECRET RELEASE GATES — enforced in CI HARNESS SCENARIOS — run the claims yourself VERIFIED BY YOUR TEAM — WITHOUT US IN THE ROOM AT YOUR FIREWALL fully self-hosted mode: zero vendor egress IN YOUR CLUSTER one allowed call · one denied call · one revocation IN YOUR SIEM metadata-only events — payloads never appear NOT IN THE PACKET — ROADMAP, NOT CLAIMS: SOC 2 · ISO 27001 · DLP · HASH-CHAINED AUDIT

What we don't claim — yet

Security reviews die on inflated claims. So this page makes none.

Here is the line between what ships today and what's on the roadmap. When something crosses that line, it moves to the left column — not before.

CLAIMED TODAY · EVERYTHING ABOVE

Shipped, and testable in a pilot

Everything above this section is in the current release, and every claim maps to something your team can exercise on your own infrastructure.

  • Self-hosted runtime paths, metadata-only retention
  • Brokered credentials, opaque references only
  • Default-deny Cedar policy, access-controlled discovery
  • Revocation that reaches active sessions
  • Signed, independently verifiable releases
ROADMAP · NOT SHIPPED · NOT CLAIMED

On the roadmap, not on the label

No certification is claimed today. These are planned — and until they ship, you won't find them anywhere on this site as capabilities.

  • Formal certification — e.g. SOC 2, ISO 27001
  • DLP / content inspection
  • ML prompt-injection and tool-poisoning detection
  • Tamper-evident, hash-chained audit
  • Certified air-gapped packaging
  • SCIM provisioning and device posture
  • Managed hosting

WHY WE PUBLISH THIS LIST — honesty is the positioning. If a page like this overstates one thing, your reviewers are right to distrust all of it.

Next step

Put us in front of your reviewers.

Bring this page to your security team — then bring your security team to a walkthrough. Same claims, same roadmap list, stated the same way in person.

Book a walkthrough Talk to the team