CAAB downstream MCP

Audience: CAAB administrators and security operators

Transport: Remote Streamable HTTP MCP

Last updated: August 11, 2026

CAAB can govern a remote MCP server as a partner-scoped capability. Discovery creates an immutable catalog; a signed permission boundary then determines which discovered tools can be advertised and invoked.

Disabled by default

Downstream MCP and automatic MCP OAuth client registration are separate rollout controls. Both require an environment flag and an matching partner allowlist entry before they are available. The wildcard entry is available only for an intentional broad release.

Availability and rollout controls

Control	Purpose	Default
EnableDownstreamMcp	Allows remote MCP registration, catalog operations, policy compilation, tool discovery, and invocation.	false
DownstreamMcpPartnerAllowlist	Limits downstream MCP to named partners. A wildcard is an intentional broad release only.	empty
EnableMcpOAuthClientRegistration	Allows automatic OAuth client registration for downstream MCP.	false
McpOAuthClientRegistrationPartnerAllowlist	Limits automatic OAuth registration to named partners.	empty

A partner must be enabled by the relevant environment flag and its matching allowlist. These controls do not affect ordinary OpenAPI capabilities. Disabling downstream MCP hides its tools and blocks new downstream operations without deleting existing registrations, catalogs, policies, audit events, or meter records.

OAuth onboarding and connection lifecycle

When an administrator supplies a downstream MCP endpoint, CAAB first attempts credential-free OAuth discovery. It checks the endpoint'sWWW-Authenticate challenge, then the derived protected- resource metadata location, verifies the exact resource binding, and resolves the advertised authorization server metadata.

Review the discovered issuer, resource, authorization endpoint, token endpoint, scopes, and client-authentication method.
CAAB uses an explicitly configured client first, then its public client-metadata document, then allowlisted dynamic client registration when supported.
If no automatic strategy is safe, configure a manually pre-registered client instead.
Complete the authorization-code + PKCE flow. The connection is partner-shared, rather than silently creating a provider client per user.

CAAB accepts only safe HTTPS metadata, registration, token, revocation, and MCP endpoints. It rejects unsafe network destinations, redirects, oversized or malformed responses, issuer/resource mismatches, and ambiguous authorization-server selection. A missing metadata response leaves the manual OAuth form available.

Connection states are registration pending, authorization pending, connected, refresh required, expired, revoked, and error. Refresh is serialized and version-checked; reconnect begins a fresh PKCE transaction without silently replacing the provider registration.

Catalog review, policy, and execution

Safe activation sequence

Register a controlled downstream server and complete discovery.
Review the immutable catalog and activate only the intended tool operations.
Assign the reviewed operations in a permission boundary and compile the signed policy.
Run one read-only invocation and confirm audit and metering evidence.
Attempt an unadvertised or unassigned tool and confirm it fails before downstream authentication or transport.

CAAB never expands authority when a server's catalog changes. New tools remain unauthorized. If an assigned tool is removed or materially changed, CAAB blocks execution until an administrator reviews the new catalog and recompiles affected policies.

Operate, rotate, and roll back

Event	Required response
Credential rotation	Update the tenant-qualified auth-profile secret, validate discovery and a read-only call, then revoke the old provider credential.
Catalog drift	Disable the affected partner if impact is unclear, re-run discovery, review changes, activate the reviewed catalog, recompile policy, and smoke-test before re-enabling.
Tenant rollback	Remove the partner from the downstream MCP allowlist. Existing records remain intact.
Environment rollback	Set EnableDownstreamMcp to false. Downstream calls fail closed while OpenAPI capabilities remain available.

Never place client secrets, access tokens, refresh tokens, authorization codes, PKCE verifiers, or registration tokens in an MCP argument, catalog, policy, log, screenshot, or ticket.

Audit evidence and release gate

OAuth lifecycle actions—registration, authorization start and callback, refresh, reconnect, and revoke—produce best-effort caab.mcp-oauth.audit.v1 evidence. It records allowlisted lifecycle metadata and hashed issuer/resource bindings with a deterministic evidence hash; it does not retain tokens, codes, states, client secrets, or provider error payloads.

Runtime calls use the separate Crittora-sealed audit trail. For each release, retain request IDs, deployment version, partner and capability IDs, catalog and policy hashes, lifecycle evidence hashes, connection and registration versions, timestamps, outcomes, and rollback results.

Production enablement requires automated tests, a controlled non-production activation and rollback, deployment health checks, and independently assessed security findings that are closed or explicitly risk-accepted. Tenant isolation, secret disclosure, callback replay, SSRF, or signed-authority expansion findings block release.

Next: review the verified policy and runtime enforcement model

Crittora CAAB

Govern which operations an AI agent, user, or API client can invoke, with signed policy integrity and runtime enforcement.

Least privilege

Runtime enforced

Auditable