The capability gateway is the mandatory enforcement and revalidation point before any governed business action executes. Role Assistants and MCP clients request enterprise capability keys; Operational Trust and Enterprise Runtime determine the authorised continuation, and the gateway enforces and revalidates that decision for the current authority and context before execution.
Why it matters
Without a single enforcement gate, permissions leak through ad hoc API calls. The gateway applies Operational Trust decisions at the capability boundary so enforcement is consistent, explainable, and auditable — the same outcome whether the caller is a Role Assistant or an MCP client.
Capabilities are compiled from certified, exposed datasources at upload time — not ad hoc per request.
What the gateway validates
Before execution:
- user identity and active role
- business context and datasource scope
- dimension and protection rules
- certification / readiness state
- policy and approval requirements
- rate limits and risk controls where configured
- evidence capture requirements
Role Assistant / MCP client → Runtime-admitted capability request → gateway revalidation → enforce | deny → execution → evidence
A deny response should be interpretable by operators — which role, dimension, certification gap, or policy blocked the action.
Relationship to Enterprise MCP
Enterprise MCP exposes tools named by capability keys (e.g. customer.search). MCP does not bypass the gateway — tool invocation is a capability request subject to the same checks as Role Assistant execution.
Integrators publish tools via upload; architects ensure only certified keys are exposed to production AI clients.
What the gateway is not
- Not a replacement for enterprise IAM — it consumes role and policy context from Operational Trust.
- Not optional for governed capabilities — raw connector access bypasses the product model.
- Not the owner of continuation or organisational authority — it enforces the Runtime-admitted capability under current Operational Trust decisions.
- Not a prompt filter — structural enforcement, not LLM instruction.
Failure modes integrators should expect
| Symptom | Likely cause |
|---|---|
| Capability not found | Upload missing or datasource not exposed |
| Deny despite “API works” | Governance dimensions or certification gap |
| Intermittent allow | Role or context switching on worker session |
Debug with certification reports, governance tests, and dataplane logs — not by granting broader API keys.
Limits
Gateway enforcement details and error surfaces evolve with platform releases. Treat deny-reason completeness and MCP tool routing as deployment-dependent until your integrator confirms certification for the target environment.