OpenAI Custom Actions Lack Cascade-Deactivation Dependencies

Vendor and Product Reality

OpenAI Custom Actions are the successor to the original ChatGPT plugin architecture and the dispatch substrate beneath the GPTs marketplace, the Assistants API tools surface, and the newer Responses API. A developer publishes an OpenAPI 3.x document describing the action's endpoints, parameter shapes, and authentication requirements. ChatGPT or the Assistants runtime ingests the spec, 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 to an HTTP request against the declared endpoint; the response returns to the model context as tool output.

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

The composition surface is where the architecture thins. Real GPTs combine multiple actions: a sales-research GPT calls a CRM action, a market-data action, and a calendar action; a clinical-decision GPT calls a vocabulary action, a coding action, and an EHR-lookup action; a developer-productivity GPT calls a source-control action, an issue-tracker action, and a CI action. Each action is a separately licensed, separately authorized, separately revocable resource, and the GPT's behavior is the joint property of all of them. None of that joint structure is represented in the OpenAPI specs themselves, in OpenAI's directory metadata, or in the runtime's dispatch logic.

Architectural Gap

Two structural problems follow. The first is authority binding. The rules that govern when an action may fire — only for users in a given role, only inside a given workflow phase, only when an upstream action has produced a valid context, only when a downstream action remains available — are conventionally encoded in the GPT's natural-language instructions or in the action's server-side authorization checks. Neither location is cryptographically bound to the OpenAPI spec the runtime dispatches against. The instructions are advisory text vulnerable to prompt injection; the server-side checks operate on identity tokens minted by OpenAI's IAM rather than on a credentialed observation of the calling context's full authority chain. An action that should fire only after a clinical-vocabulary lookup has succeeded has no structural way to know whether the lookup actually succeeded, was synthesized by a hallucinating model, or was returned by a stale cached response.

The second problem is cascade deactivation. When OpenAI removes an action from the directory — for policy violation, for a security incident at the publisher, for a license dispute — every GPT that depended on that action continues to operate. Its instructions still reference the action's behaviors, its prompt scaffolding still expects the action's outputs, but the dispatch silently fails or, worse, the model hallucinates plausible substitute output. Downstream actions that consumed the removed action's results now operate under invalid assumptions. The composition fails not loudly, with an error the user can act on, but quietly, with degraded output the user cannot easily distinguish from a healthy run. The directory has no dependency graph; revocation cannot cascade because there is no edge to walk.

The cost of these gaps is paid by the workflows that matter most. Casual GPTs that summarize a webpage tolerate silent failure; clinical, legal, financial, and operational GPTs do not. The Custom Actions architecture is therefore stuck in a market position where it can scale to consumer breadth or to enterprise depth but not, structurally, to both at the same time.

What the Primitive Provides

Adaptive Query's LLM skill-gating primitive ships behavioral rules with the action and resolves dependencies through a credentialed admissibility gate. Each registered action carries, alongside its OpenAPI document, a signed gating manifest declaring (a) the authority taxonomy classes whose credentials may invoke it, (b) the upstream actions whose successful completion is a precondition, (c) the downstream actions for which it is itself a precondition, and (d) the scope envelope outside which its outputs must not be acted upon. The manifest is bound to the OpenAPI spec by content hash; tampering with either invalidates the binding. The runtime's tool-dispatch path consumes the manifest before issuing the HTTP call, evaluating the calling context's authority chain against the declared classes and verifying the precondition state through the credentialed observation ledger that other Adaptive Query primitives also produce.

Cascade deactivation is the natural consequence of representing dependencies structurally. When an action is revoked at the directory, the gate walks the outbound dependency edges and emits deactivation observations for every dependent action; each dependent action's gate consumes the observation on its next admissibility evaluation and refuses to fire, surfacing a structured deactivation reason rather than degrading silently. Users and operators see, at the GPT or workflow level, that the clinical-vocabulary action's revocation has deactivated the specialty-coding action that consumed it, with named alternatives surfaced from the directory's compatibility metadata. The same machinery handles transient unavailability, scope contraction, and policy-class downgrades — each is just a different observation type on the same dependency graph.

The gating manifest is also the structural answer to prompt-injection escalation. A natural-language instruction embedded in retrieved content cannot induce an action to fire outside its declared authority taxonomy, because the gate evaluates the calling context's actual credentials, not the model's narrative about them. An action whose manifest restricts invocation to authenticated enterprise users in a specific role does not fire when an injected instruction claims that role; the claim is text in a token stream, while the gate evaluates a credentialed observation produced by the runtime's own session state. This converts a class of prompt-injection vulnerability from an open-ended adversarial-language problem into a closed authorization-decision problem, which is the form security teams already know how to reason about.

Composition Pathway

Composition with OpenAI's existing Custom Actions surface is incremental. Stage one introduces the gating manifest as an optional sidecar to the OpenAPI document at registration time; existing actions continue to operate unchanged, while gated actions gain the authority and dependency declarations. Stage two extends the directory's metadata to include dependency edges and exposes them to the GPT-builder UI, so authors can compose actions with explicit upstream and downstream relationships rather than implicit prompt scaffolding. Stage three wires the runtime's tool-dispatch path through the admissibility gate, evaluating manifests on every call and producing the credentialed observation ledger that downstream primitives consume. Stage four exposes the cascade machinery to the marketplace, so revocations propagate through dependent GPTs and Assistants automatically rather than requiring per-tenant reinstallation.

Each stage is independently shippable. Stage one alone is enough to give enterprise customers an audit-grade record of which authority classes invoked which actions in which workflows, addressable to ChatGPT Enterprise's compliance and legal review needs. Stages two and three deepen the developer experience without breaking the consumer surface. Stage four is the structural transition from a directory of independent actions to an ecosystem of composing actions whose joint behavior is verifiable.

Backwards compatibility is preserved throughout. Actions that ship without a gating manifest continue to operate under the existing authorization model; the gate treats the absence of a manifest as a permissive default for non-regulated workflows and as an automatic refusal for workflows that have opted into gated-only mode. Enterprise admins gain a single setting that flips the tenant from permissive to gated-only, which is the policy lever compliance teams need and which is currently absent from the Custom Actions surface entirely. The lever is the same one regulated industries already operate around tool-use in other software categories — file-share permissions, database-grant levels, network-egress allowlists — and aligning the GPT and Assistants surface to that mental model is itself a meaningful enterprise-acquisition argument.

Commercial and Licensing

LLM skill-gating is the architectural primitive that converts Custom Actions from a single-action authorization model into a composition-grade dependency-aware substrate. The commercial pathway is licensing of the gating-manifest format, the admissibility-gate dispatch logic, and the cascade-deactivation machinery into OpenAI's existing Actions, Assistants, and Responses runtimes. The license is non-exclusive and aligns with the broader Adaptive Query stack, in particular the credentialed observation ledger that is shared across primitives. Pricing is anchored to the enterprise tier, where audit-grade cascade behavior is the difference between a GPT that may be deployed in regulated workflows and one that may not. The primitive is the structural answer to "what happens to my workflow when one of its actions is revoked," and the answer the market increasingly demands is "the workflow notices, names the cause, and offers alternatives" — not "the workflow continues, silently wrong."