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 — never raw vendor APIs or credentials; Operational Trust and the Role Assistant Runtime (Enterprise Runtime — the boundary that verifies current authority) determine the authorised continuation, and the gateway enforces and revalidates that decision for the current authority and context before execution. This is step 5 of the section's define-once, verify-every-time pattern — see Architecture overview.
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. See Governed capabilities for how a datasource becomes a capability key.
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). A single business request can call capability keys spanning more than one connected system — each system stays its own system of record, so composing multi-system business context this way never moves that authority into AI Fabrix. 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.
Debugging a deny
A deny is expected, explainable behavior when role, certification, or policy does not allow the action — not a platform defect (see Trust boundaries). Common causes are an unpublished capability, a certification gap, or a role/context mismatch on the calling session — not a broken connection. For symptom-to-fix guidance and the certification/governance tooling to debug with, see Governed capabilities.
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.