Crittora Agent Authority Broker (CAAB)
CAAB is Crittora's control plane and enforcement layer for scoped AI-agent authority. It turns API and MCP operations into explicit permissions, assigns only the permitted operations to a subject, protects the resulting policy with Crittora Secure, and enforces that policy when tools are discovered and invoked.
Why CAAB exists
Giving an agent a credential usually gives it every permission carried by that credential. CAAB separates credential ownership from operation authority. A partner can connect an upstream API once, then issue a different least-privilege boundary to each user, agent, or API client.
Reduce blast radius
Expose only approved API methods and paths instead of an entire vendor account.
Make authority reviewable
Represent each allowed operation with a stable permission ID that can be inspected and audited.
Protect policy integrity
Sign and encrypt compiled policy JSON before persistence, then decrypt and verify it before enforcement.
Control returned data
Remove or mask selected response fields before an MCP result reaches the caller.
Core model
| Concept | Meaning | Example |
|---|---|---|
| Partner | The tenant and administrative scope that owns users, imported APIs, boundaries, and runtime configuration. | A customer organization or integration partner |
| Subject | The authenticated principal to which authority is assigned. A legacy subject has a CAAB-managed identity; an external subject is derived from a binding and partner OIDC identity and has no Crittora credential. | agent-order-support |
| Capability | A normalized catalog of callable operations imported from OpenAPI or discovered from a remote Streamable HTTP MCP server. A capability is partner-scoped. | Acme Orders API v2 or Account MCP |
| Operation | One reviewed API method/path or MCP tool contract within a capability. | POST /orders/{orderId}/refund or get_invoice |
| Permission ID | The stable operation identifier used in policy allowlists. API IDs use the API, method, and path; remote MCP tool IDs also include a name-derived hash to avoid normalization collisions. | orders-api:post:/orders/{orderId}/refund |
| Auth profile | A named reference to the upstream authentication configuration and secret material used at runtime. | auth-profile:orders-api:production |
| Permission boundary | The user-bound administrative record describing allowed tools or API policies. Tool-based and API-based boundary forms are mutually exclusive. | Support agent — read and refund only |
| Compiled policy | A canonical v1 legacy or v2 external-subject document containing independently verifiable subject and authority context, operation snapshots, expiry/revocation, and response rules. | Signed and encrypted policy blob |
Architecture and trust boundaries
Admin portal. A React administration experience lets authorized operators manage partners, users, capabilities, auth profiles, policies, audit records, usage, and diagnostics.
Authority API. An authenticated API validates tenancy and role, normalizes OpenAPI documents, compiles policy, and provides explicit authorization decisions.
Persistence. DynamoDB stores tenant records, capability catalogs, encrypted policies, audit events, and metering data. Secret values are handled separately from public profile metadata.
Crittora Secure. Managed sign-encrypt and decrypt-verify operations provide confidentiality, integrity, and signature verification for policy artifacts. V2 uses one CAAB-owned policy-crypto identity per environment; partner workloads never receive it.
CAAB runtime. The hosted MCP runtime and binding-scoped Partner API derive authority from verified policy, inject the referenced upstream authentication, execute the operation, redact the response, and record the call.
OAuth-protected MCP management. The same CAAB MCP endpoint can expose onboarding, tenant-management, personal OAuth, and governed runtime tools. Tool discovery is recalculated for the authenticated principal: partner administrators receive management tools, while runtime members receive only their permitted API operations.
Policy lifecycle
| Stage | What CAAB does | Security control |
|---|---|---|
| Discover | Imports an OpenAPI document or initializes a remote Streamable HTTP MCP server and maps its reviewed operations into the CAAB common data model. | Every operation receives a deterministic permission ID and remote MCPs retain an immutable catalog version. |
| Configure | Stores a named upstream auth profile and selects operations for a subject. | Policies refer to an auth profile; public responses expose metadata, not raw secrets. |
| Compile | Builds immutable operation snapshots, canonicalizes the policy JSON, and computes a SHA-256 hash. | Unknown permission IDs and invalid auth-profile references are rejected. |
| Protect | Calls Crittora Secure /sign-encrypt. Legacy v1 uses subject credentials; external-subject v2 uses the per-environment CAAB policy-crypto identity. | The policy is persisted as an encrypted, signed artifact without exposing crypto credentials to partners. |
| Verify | Loads the policy blob and calls /decrypt-verify before making a runtime decision. | An invalid signature fails closed. |
| Enforce | Checks subject, capability, operation, expiry, revocation, allowed permission ID, and any signed parameter constraints. | Only an explicit match returns allow; constraints deny before secrets are loaded or downstream calls begin. |
| Observe | Records policy changes, allow/deny decisions, MCP calls, duration, status, and metering counters. | Sensitive fields and response headers are redacted from runtime output and logs. |
Shared responsibility
Crittora operates policy protection and the CAAB control/runtime services. Partner administrators remain responsible for selecting the correct upstream API, granting the minimum set of operations, choosing safe auth credentials, reviewing audit events, and promptly revoking access when a subject's role changes.
Application developers should treat permission IDs as durable policy identifiers, avoid embedding secret values in policy or OpenAPI documents, and design upstream endpoints with narrow operations that can be granted independently.
Partner-hosted applications additionally own their end-user identity, MCP authentication, OpenAPI definitions, downstream OAuth clients, branded experience, webhook recipient key, and secure storage of the binding-scoped workload secret. See the headless Partner API guide for the complete responsibility and compatibility boundaries.
Next: configure a partner, capability, auth profile, and boundary
Crittora CAAB
Govern which operations an AI agent, user, or API client can invoke, with signed policy integrity and runtime enforcement.