AI & agent access

Cortex exposes a north-facing MCP gateway (Model Context Protocol) so AI agents and partner systems can act on the platform under the same governance as every other caller. It is a peer of the REST edge: it owns no business logic, has no privileged identity of its own, and money still moves only through the ledger.

Where: /api/v1/mcp (JSON-RPC over streamable HTTP / SSE / stdio).

Primitives & discovery

The gateway offers three kinds of thing, discovered with tools/list, resources/list and prompts/list:

Primitive	Is	Example
Tool	A command (a write, or a read)	transfers.preview, accounts.open
Resource	A read model, addressed cortex://…	cortex://approvals/{id}
Prompt	A guided workflow	None

Discovery is entitlement-filtered. A session whose token lacks account:open never even sees accounts.open in tools/list. Tools are addressed by business identifiers ({accountNo}, {customerNo}), which are resolved to internal ids and re-checked against entitlements.

Quote, then commit

Every value-bearing tool is a preview / commit pair:

1. *.preview has no side effects. It returns a short-lived previewId with the computed charges, tax, FX, draft ledger legs and any approvals that will be required.
2. *.commit takes the previewId plus an idempotencyKey (and an approvalToken if one is needed), re-validates, and executes.

If the world moved between the two steps, commit fails with PREVIEW_EXPIRED or PREVIEW_DIVERGED rather than surprising the caller. This is distinct from, and composes with, maker-checker.

The same guarantees as REST, and a few more

• Idempotency: every mutating tool requires an idempotencyKey; same key replays the recorded outcome, same key with different arguments raises IDEMPOTENCY_CONFLICT.
• Maker-checker: a parked action returns { status: PENDING_APPROVAL, approvalId, pollUri } as a first-class result, not an error. Agents cannot escape four-eyes by using MCP.
• Step-up: sensitive tools (reversals, loan approval, high-value transfers) can demand a fresh authentication challenge. The first call returns STEP_UP_REQUIRED, and the resulting approvalToken is presented on commit.
• Transaction signing: commits carry Ed25519 detached signatures over the canonical tool arguments, verified per-tenant and stored on the invocation for non-repudiation.
• Identity is token-derived: initiatedBy, channel = MCP, tenantId come from the token, never from what the caller asserts. Partner access adds mTLS and resource-indicator binding so a token minted for another audience cannot be replayed here.

Autonomy tiers

How much an agent may do is governed by which OAuth scopes its identity holds, not per tool:

Tier	Behaviour
PROPOSE_ONLY	Read and propose. The AI plane connects this way: read/propose scopes only, so write tools never appear in its tools/list.
AUTO_WITH_GUARDRAILS	Acts within limits and maker-checker.
AUTO	Acts within limits and maker-checker.

A human-delegated, partner or service identity that carries write scopes gets the full transactional surface, still subject to limits and four-eyes. Acting on a proposal emits an immutable Decision Record: the outcome, the autonomy tier, the guardrail checks, a reference to the committed action (domainCommandId, idempotencyKey, resultEventId) and, for a proposal, the human approver.

Scope of the gateway today

Around 30 tools, resources and prompts ship today, growing toward full coverage of the REST surface. The gateway emits governance events only (McpToolInvoked, McpToolDenied, consent grants and revocations); banking domain events still come from the contexts, per Events & integration.