THE GOVERNED MCP GATEWAY THREE JOBS · ONE BOUNDARY · NO TESTIMONIALS ON THIS PAGE, ON PURPOSE BY DIGITALAPI.AI

Who it's for

Built for the people who get paged.

Three jobs share the agent-to-tool boundary: the security team that has to approve it, the platform team that has to run it, and the leadership that has to answer for it. Here's what each actually gets — described operationally, not aspirationally.

PERSONA 01 · SECURITY / CISO ORG

You have to say yes without becoming the bottleneck.

"Every team wants an MCP server in prod by Friday. I can approve a pattern. I cannot review thirteen hand-rolled boundaries a quarter."

ONE GATE TO APPROVE — NOT THIRTEEN EVERY AGENT policy · default deny denied · no upstream APPROVED TOOLS EVERY DECISION → YOUR SIEM
Your vantage point: the whole estate through one archApprove the pattern once

You're on the hook for

  • Approving agent access to internal tools without slowing every team down
  • Knowing which agent can reach which tool, with whose credentials
  • Answering "what happened?" during an incident — with evidence
  • Shutting things down fast, and proving the shutdown worked

Day one with the gateway

  • Default deny becomes the estate posture; explicit deny overrides any allow
  • Unauthorized tools are hidden at discovery, not refused after the fact
  • Policy changes are simulated before rollout — see what a rule would do, not what it did
  • Every decision streams to your SIEM as metadata-only events

What you can prove

  • Every allow and deny with its policy version and stable machine reason
  • Secrets never enter logs, traces, or audit — structurally, not by policy memo
  • A revocation drill: disable a tool, watch live sessions react, export the record
  • Signed releases with Cosign + SBOM for supply-chain review
DAY ONE — WHAT LANDS IN YOUR SIEMSAMPLE
tool.call.allowedagent: support-bot (owner: team-cx) · policy cedar-v3 · user-delegated metadata only ALLOW
tool.call.deniedagent: sales-agent · reason: EXPLICIT_DENY_PROD_MUTATION · policy cedar-v3 no upstream attempt DENY
session.revokedactor: sec-oncall · reason on record · reached the live session confirmed REVOKED

The sentence for upstairs"Every agent call goes through one gate we control, with an audit record we can export."

STILL YOURS: your IdP, your secret manager, your SIEM, your review standards. The gateway plugs in; it doesn't replace.

WON'T DO: content inspection / DLP, tamper-evident audit chains, or a compliance certificate — SOC 2 / ISO 27001 are roadmap, not claims.

PERSONA 02 · PLATFORM / AI INFRA ENGINEERING

You have to run what everyone else is about to build on.

"'Just add MCP support' is a one-line ask that lands on my team as auth, routing, sessions, audit, and on-call. I want one deployment, not a pattern I babysit."

YOUR CLUSTER $ HELM INSTALL GATEWAY RUST DATA PLANE your idp your secret manager your postgres your valkey your otel → your siem NOTHING NEW TO BABYSIT — BORING DEPENDENCIES, YOUR SINKS
Your vantage point: one deployment on the stack you already rungatewayctl gates policy in CI

You're on the hook for

  • Standing up agent infrastructure other teams depend on
  • Keeping credentials, private endpoints, and sessions from becoming tickets
  • Upgrades and drains that don't drop live agent sessions
  • Being on call for whatever gets deployed

Day one with the gateway

  • Helm into your cluster against your PostgreSQL, Valkey, IdP, and secret manager
  • One registry for MCP servers and API sources — owner, risk, environment on every entry
  • gatewayctl in CI: validate-manifest and simulate-policy as pipeline gates
  • Sessions with affinity, reconnect, drain, terminate — revocation reaches live traffic

What you can prove

  • Reproducible deploys: spec-first contracts, no UI-only actions
  • No required vendor egress in fully self-hosted mode — verifiable at the firewall
  • Harness scenarios you can run before and after every upgrade
  • OpenTelemetry to your stack — the gateway is observable like your own services
DAY ONE — YOUR TERMINALSAMPLE
$ helm install amelfi ./charts/gateway --values prod.yaml
✓ deployed · db=your-postgres · cache=your-valkey · idp=your-oidc
$ gatewayctl validate-manifest crm-tools.yaml
✓ manifest valid · owner=revops · risk=medium
$ gatewayctl simulate-policy --agent support-bot --tool tickets_create --env prod
ALLOW · cedar-policy-v3 · rule=allow-support-write

The sentence for upstairs"One deployment governs every team's agents — and it runs on our stack, not a vendor's."

STILL YOURS: your cluster, your databases, your telemetry, your deploy pipeline. Boring dependencies by design — Rust, Cedar, PostgreSQL, Valkey.

WON'T DO: host your MCP servers, manage your models, or replace your API gateway. It governs the boundary; it doesn't absorb your platform.

PERSONA 03 · ENGINEERING LEADERSHIP

You have to ship agent capability without inheriting one-off risk.

"I'm asked for agent features and asked to guarantee nothing leaks. Both, quarterly. I need the second one to be a property of the platform, not of heroics."

team a team b team c SHIPPED · ONE REVIEW EVERY CALL AUDITED THE QUARTER YOU'RE AVOIDING: REVIEW ×1 REVIEW ×2 REVIEW ×3 …× EVERY QUARTER
Your vantage point: one path to answer for — not one per teamRisk as a platform property

You're on the hook for

  • Agent capability on the roadmap — with risk that doesn't compound per team
  • Not paying the 13-subsystem adoption tax in every quarter's headcount
  • A story security, platform, and product all sign

Day one with the gateway

  • Teams onboard to one approved path instead of building their own boundary
  • The 13 rebuilt subsystems become shared infrastructure, reviewed once
  • New tools ship through registry + approval, not through exceptions

What you can prove

  • A scoped pilot in 4–6 weeks: one boundary, allowed/denied/revoked, end to end
  • An evidence packet your security team verifies themselves — not vendor claims
  • Cost of the ungoverned path, measured against your own teams during the pilot
PILOT — WEEK 6 EVIDENCESAMPLE
One allowed call, on the recorddecision + policy version in the audit trailwitnessedDONE
One denied call, with its reasonfails closed · no upstream attemptwitnessedDONE
One revocation reaching a live sessionno redeploy, no rotation scramblewitnessedDONE
Audit export in your SIEMmetadata only — verified by your teamwitnessedDONE
Sign-offsecurity · platform · sponsorweek 6YOURS

The sentence for upstairs"One review covers every team's agents, and revocation is one click."

STILL YOURS: the governance decisions. The gateway enforces your policy; it doesn't decide it.

WON'T DO: hand you ROI numbers we invented. There are none on this site — pilots measure against your baseline, and that's the number you take to the board.

Also in the room

The people on either side of the boundary.

Not the buyers — the users. The gateway only works if it's less friction than the ungoverned path for both of them.

TOOL / API OWNERS

Expose exactly what you mean to.

Register a server or import an OpenAPI spec, then select the specific operations that become tools. Nothing else is exposed, ever.

  • Per-tool risk, owner, credential mode, and timeout
  • Approval flow instead of a security-review queue
  • Spec drift is flagged before it becomes an incident
AGENT BUILDERS

A clean tool list and denies you can act on.

Your agent sees only what it may call — no filtering logic on your side, no surprise 403s mid-run.

  • Policy-filtered discovery: the tool list is the permission list
  • Stable machine reasons on every deny, with suggested fixes
  • Credentials handled for you — nothing to store, nothing to leak

Read before applying

Not for you — yet.

If any of these are hard requirements today, we'd rather tell you now: full DLP and content inspection, tamper-evident audit hash chains, certified air-gapped packaging, managed MCP hosting, and formal compliance attestations are roadmap, not current capability. If they're on your must-have list, talk to us about Enterprise timelines before committing a pilot.

Read the full security posture See what Enterprise does include

Next step

Bring all three stakeholders. One boundary.

The best pilots have a security reviewer, a platform owner, and a sponsor in the room. 4–6 weeks, your infrastructure, evidence at the end.

Book a walkthrough Talk to the team