Status: mixed — the invocation foundations and exposure architecture are stable baselines; the full Controlled Exposure authorization model is canonical but evolving (per-hop wire credentials, multi-stage approvals, and service-to-service delegation are deferred design intent, not shipped behavior).

Authorization, Audit, Evidence

Controlled Exposure: governance, not a feature

Controlled Exposure is the platform-wide governance mechanism that decides what can be reached, by whom, through which path, under what controls. Its founding asymmetry:

A Service declares what it can do; the Platform decides whether anyone may see or do it.

A Service does not know which access surfaces exist and cannot broaden its own reach. Three states are kept strictly separate:

• Published — a Service has registered a versioned operation.
• Exposed — platform policy permits some access path to project it.
• Authorized — this caller, on this path, against this target, right now, may execute it.

The default is deny: absent an explicit exposure rule, nothing is exposed. And visibility is never the security boundary — hiding an operation reduces information disclosure, but every concrete invocation is authorized again on its own merits.

Checkpoint + Resource: the identity of a governed operation

A Checkpoint is a versioned, schema-bound, policy-governed operation published by a Service — the smallest named boundary that can be authorized. Published versions are immutable: changing schemas, side-effect classification, risk metadata, or execution semantics requires a new version; re-registering a version with different content fails closed. Authorization identity is always the triple (service, checkpoint, version); tool names, UI labels, and routes are projections, never authority. Version resolution is exact — there is no implicit "latest".

A Resource is the canonical target an operation acts on. Authorization is evaluated against Checkpoint + Resource together, never on an operation name alone. Resource extraction is deterministic and schema-bound, performed by the Platform before authorization — a caller-supplied resource string is never authority.

How invocation authorization works

Every governed invocation is expressed as: A, through B, performs D on C — an originator, a complete ordered access path, a Checkpoint, and a Resource. The account supplies the rights ceiling and accountability; the originator records what actually caused the behavior. A declared-but-unverified originator can trigger stricter policy but can never expand authority. The type of access surface never implies whether a human or an AI is acting.

The decision is an intersection of every applicable scope — platform baseline, organizational policy, account entitlement, device and delegation policy, path participants, checkpoint-and-resource policy, target admission, data-flow rules, runtime state — combined with the strictest applicable controls. Lower layers may only narrow: remove operations, narrow resources, shorten lifetimes, demand stronger authentication or stricter audit.

Authorization is bidirectional: the Platform must also admit the specific target (version, artifact, instance) and authorize data crossing each boundary in both directions. A caller may be allowed to run an operation yet forbidden to disclose a particular input to it, or to receive a sensitive result over the current path.

Five execution authorization modes compose conjunctively: automatic, time-bound, session-bound, single-use, and deny. A grant that is both time-bound and session-bound expires at whichever limit comes first. Single-use grants are consumed atomically when execution begins, so a failed attempt does not silently restore authority. Deny is absolute — no approval or authentication overrides it; emergency access is a separately designed break-glass process.

Authentication strength is an independent axis from authorization duration: policy can require fresh reauthentication or multi-factor confirmation, separately for requester and approver, each with its own freshness window. An unattended AI must not satisfy a human confirmation requirement using a stored human factor.

Evidence: challenge, approval, grant

Three durable objects are deliberately distinct:

Object	Proves
Authentication Challenge	an identity confirmation happened
Approval	a decision about an exact reviewed scope
Authorization Grant	execution authority, produced once policy + authentication + approval are all satisfied

Each has an explicit lifecycle with absolute deadlines, bound scope, and revocation. Changing the reviewed payload, version, resource, path, or classification invalidates the approval and its grant. Because these are durable objects, authorization can pause and resume: an asynchronous caller receives a structured "approval required" continuation — explicitly not a denial — rather than a held connection.

Audit guarantees

All managed execution is attributable and auditable. An audit decision record preserves the full identity and policy snapshot: account, originator and verification status, complete access path, service/version/instance, checkpoint version, resolved policy revisions, normalized resource and ancestry, parameter digest, data classifications, effective authorization mode, references to challenge/approval/grant, and the outcome. Historical decisions are immutable.

Supporting guarantees: deterministic policy combination with explanation; full trace reconstruction across hops; safe redaction of secrets; bounded revocation propagation; policy-revision-aware caching so a stale cache cannot outlive its policy. Reads are governed too — retrieving a prior result is re-authorized at read time under current permissions and redaction rules. Recovery restores delivery, never authority.

Reliable execution rests on frozen identifiers — a client-supplied request key, a platform-issued command handle, a trace identifier — plus a canonical payload digest. The same request key with a different payload fails closed. After an indeterminate outcome, a client queries recovery status rather than blind-retrying.

Xtrape Exposure vs Controlled Exposure

Controlled Exposure is platform-wide governance applied to every surface equally. Xtrape Exposure is one product: the AI-facing disclosure layer owning Exposure Tasks, tool naming, and discovery catalogs — with MCP as its first protocol projection. Exposure holds no policy, entitlement, or audit authority; its bindings pin exact immutable operation versions, and every invocation is submitted to the Platform for a fresh authorization decision. A projection snapshot freezes identity resolution, never entitlement.