Vendor and Product Reality

OpenAI Custom Actions are the successor to the original ChatGPT plugin architecture and the dispatch substrate beneath the GPTs surface, the Assistants API tools surface, and the Responses API. A developer publishes an OpenAPI document describing the action's endpoints, parameter shapes, and authentication requirements. ChatGPT or the Assistants runtime ingests the specification, presents the user with a consent surface, and, once authorized, exposes the action to the model as a callable tool. The model emits structured tool calls; the runtime translates each call into an HTTP request against the declared endpoint; the response returns to the model context as tool output. This is a clean, widely adopted integration model, and it does the single-action job well.

The authentication model is OpenAI-mediated. API keys are held in OpenAI's credential store, and OAuth flows are completed against the third party while the resulting tokens are held and refreshed by OpenAI on the user's behalf. Authorization for invocation is a function of OpenAI account identity and install state: enterprise administrators gate which actions their tenants may install, individual users gate which actions their personal accounts trust, and the GPTs directory performs a review before listing. The action publisher controls the API contract, OpenAI controls dispatch and the identity binding, and the user controls install-or-don't-install. Each side of that arrangement is well-formed in isolation.

The axis this article examines is not whether Custom Actions authorize invocation, which they plainly do, but what kind of object that authorization is. In Custom Actions, an action is invocable because the account is in a state that permits it: the tenant installed it, the user trusted it, the directory listed it. That is a durable configuration fact. It is not, by design, a time-bounded and evidence-backed attestation that the runtime re-checks against fresh evidence and can withdraw the moment that evidence lapses. This is not a defect in Custom Actions; it is a boundary of the category, and it is the boundary the disclosed primitive is built to cross.

Architectural Gap

Two properties follow from authorization being account state rather than an evidence-backed attestation.

The first concerns the binding between the rules that should govern when an action may fire and the artifact the runtime actually dispatches against. Rules such as "only for users in a given role" or "only inside a given workflow phase" are conventionally encoded either in a GPT's natural-language instructions or in the action's own server-side authorization checks. Natural-language instructions are advisory text and are vulnerable to prompt injection: an instruction embedded in retrieved content can attempt to induce a call the author never intended. Server-side checks operate on identity tokens minted by OpenAI's account system rather than on a verified observation of the calling context's demonstrated authority. Neither location is a structural admission gate that evaluates the requester's actual, evidenced fitness to exercise the capability at call time.

The second concerns revocation. When an authorization to invoke is account state, withdrawing it is an administrative event: an admin uninstalls the action, a user revokes trust, or the directory delists a publisher. Nothing in that model continuously re-evaluates whether the requester still merits the capability, and nothing withdraws the capability automatically when the evidence that once justified it degrades. Capability, once granted, persists until someone deliberately removes it. For casual GPTs that summarize a webpage this is entirely acceptable. For clinical, legal, financial, and operational workflows, where the question is not "did an administrator revoke access" but "is the requester still demonstrably competent to exercise this capability right now," a static grant is the wrong shape.

What the Primitive Provides

The LLM and skill-gating layer disclosed in 19/647,395 replaces the static grant with an evidence-based capability gate and a revocable certification token. The disclosure recites this concretely, and the following describes only what the filing recites.

A capability gate is a governed evaluation point that stands between a requester (a human operator, a semantic agent, or a composite system) and a capability the requester seeks to exercise. The gate does not evaluate credentials that attest to past training, degrees that attest to past education, or role assignments that attest to organizational position. It evaluates demonstrated performance evidence: observations, measurements, and assessments that directly measure the requester's ability to exercise the capability competently in the current context. That evidence is accumulated through a curriculum engine and through continuous operational monitoring that observes performance after the capability has been granted. The gate is therefore a continuous evaluation rather than a one-time check: it opens on progressive unlock as mastery is demonstrated, and it can close again, revoking a previously granted capability, when ongoing evidence indicates competence has degraded below the required threshold.

When the gate opens, the system issues a certification token. As the filing recites it, the token is a cryptographically signed data object attesting to the holder's demonstrated mastery of a capability at a specific time, under specific assessment conditions, evaluated by specific instruments. It is not a role assignment, a permission grant, or a static badge. Its fields include a capability identifier, the holder's identity, an evidence hash (a cryptographic hash of the evidence corpus evaluated at issuance, letting a verifier confirm the token was issued against specific evidence without accessing the evidence itself), issuance and expiration timestamps, the policy scope under which it was issued, the issuing authority, a device entropy binding that ties the attestation to the device from which mastery was demonstrated, and the issuing authority's signature. The token participates in an active, expired, revoked, and revalidated lifecycle. It is active when it may be presented to gates and verification services; it becomes expired when its temporal window elapses; it becomes revoked, regardless of expiration, upon evidence of mastery regression, incident reports, or governance intervention; and it becomes revalidated when the holder completes a re-assessment and a fresh token is issued with new evidence bindings. Each transition is recorded as a governed event in the holder's lineage.

Applied to an action-invocation surface, this is what changes. The right to invoke a capability is not the account's install state; it is a live certification token whose validity the gate re-checks at call time against expiration, revocation status, and policy scope. Because revocation is triggered by evidence of regression and not only by administrative action, withdrawing a capability is a structural consequence of the evidence changing, not a manual cleanup step. And because a token carries a policy scope and a signature, the filing recites cross-platform deployment gating: a receiving system outside the originating platform verifies the token's signature against the issuing authority's public key, validates its expiration status, and evaluates its policy scope against the receiving system's own governance requirements before honoring it. Authority travels with a verifiable attestation rather than with account configuration.

Underneath the gate sits the same untrusted-proposal architecture that governs the rest of the layer. Every language-model output in the disclosed platform occupies the structural role of an untrusted proposal generator: no model output is authoritative, and no proposal reaches any agent field, governance decision, certification token, or capability gate without first passing through a validation engine, and, where multiple models produce competing proposals, a trust-weighted arbitration engine. There is no bypass path and no trusted-model exception. This is why an injected instruction cannot promote itself into an invocation: the gate evaluates a verified observation of the requester's evidenced authority, not the model's narrative about it. A class of prompt-injection risk becomes a closed authorization-decision problem, which is the form security teams already reason about.

Composition Pathway

Composition with an existing Custom-Actions-style surface is incremental, and each stage is independently shippable. A skilled implementer would proceed roughly as follows.

Stage one attaches an evidence-gated capability gate in front of an action's dispatch path without changing the OpenAPI contract. At registration, the action declares the capability identifier it exercises and the policy scope under which it may fire. Existing ungated actions continue to operate unchanged; gated actions gain a call-time admission check. Stage two stands up the curriculum engine and the continuous monitoring stream that accumulate the performance evidence the gate consumes, so that "may this requester invoke this action" is answered against demonstrated competence rather than against install state alone. Stage three issues certification tokens on gate opening and threads token verification (signature, expiration, revocation status, policy scope) into the runtime's tool-dispatch path, so every gated call re-checks a live attestation. Stage four wires the revocation and revalidation lifecycle to the monitoring stream, so a token is withdrawn automatically on evidence of regression and reissued on successful re-assessment, with each transition recorded in the holder's lineage.

An implementer has latitude in each stage. The evidence streams the curriculum engine and monitor consume can be text, audio, video, sensor-telemetry, or biometric, singly or in combination, per the multimodal evaluation pipeline the filing describes. The gate's competency thresholds, the token's temporal window, and the policy-scope vocabulary are all embodiment choices. The identity anchor bound into the token can be a platform identity anchor or the biological identity system the filing cross-references. A deployment may run gate-only as a permissive default for non-regulated workflows and refuse-by-default for workflows that opt into gated-only operation. Backwards compatibility is preserved throughout: an action without a gate operates under the pre-existing authorization model, and a tenant flips from permissive to gated-only as a single policy lever, which is the lever regulated industries already operate for file-share permissions, database grants, and network-egress allowlists.

Commercial and Licensing

The evidence-gated capability gate and the certification-token lifecycle are the primitives that convert an action-invocation surface from static, account-scoped authorization into a continuously re-evaluated, evidence-backed, revocable one. The commercial pathway is non-exclusive licensing of the capability-gate admission logic, the certification-token format and lifecycle, and the curriculum-and-monitoring evidence pipeline into existing Actions, Assistants, and Responses runtimes, aligned with the broader Adaptive Query stack and the lineage record the primitives share. Value anchors to the enterprise tier, where the deployable difference is whether an action's authority can be withdrawn automatically when the evidence for it lapses, rather than only when an administrator remembers to withdraw it. The primitive answers "is the requester still demonstrably fit to exercise this capability, right now" with a verifiable attestation, not with a durable install flag.

Disclosure Scope

The evidence-gated capability gate and certification-token mechanism, comprising a governed capability gate that evaluates demonstrated performance evidence accumulated through a curriculum engine and continuous operational monitoring, progressive unlock and evidence-based revocation on competency regression, the certification token field set (capability identifier, holder identity, evidence hash, issuance and expiration timestamps, policy scope, issuing authority, device entropy binding, and issuing authority signature), the active, expired, revoked, and revalidated lifecycle with each transition recorded in the holder's lineage, cross-platform deployment gating by signature, expiration, and policy scope, and the untrusted-proposal, mutation, validation, and trust-weighted arbitration architecture beneath it, is disclosed in United States Patent Application 19/647,395.

The characterization of OpenAI Custom Actions, the GPTs, Assistants, and Responses surfaces, and the surrounding market is external context provided for comparison only. It is not a claim of the filing, and it describes those products at the architectural level as third-party systems. This article describes the disclosed mechanism and does not introduce dependency-graph edges, per-action gating manifests, directory compatibility metadata, marketplace cross-recognition, tiers, or federation beyond what the filing recites.