Vendor and product reality
Anthropic Skills entered the Claude product surface as part of the broader push to make Claude more useful to enterprise developers without compromising the trust posture that has been central to Anthropic's commercial positioning. A skill is a folder: a required instruction file with metadata that the Claude runtime uses to decide when the skill is relevant to a request, together with optional scripts the model can execute and reference resources it can load as needed. Skills work across Claude.ai, Claude Code, and the API. Where a skill is distributed through Anthropic's official plugin marketplace, the unit can carry integrity verification for enterprise deployments and, on stricter review, an Anthropic-verified designation. Claude consumers, whether individual developers using the API, teams using Claude for Work, or enterprises deploying through a cloud surface, activate skills by installing them and making them available to Claude in their tenancy.
The architecture is publisher-side. The publisher authors the skill; where it is distributed through the official marketplace, Anthropic curates the directory and can attach integrity verification and a verified designation. That verification is meaningful as far as it goes: a consumer can confirm that the unit is the one the publisher shipped and has not been altered, and that it passed whatever review the directory applied. The consumer's role in admission is approval, not certification. The consumer says yes or no; the consumer does not produce an artifact that records, against the consumer's own policy, that this skill is admissible inside this deployment for these reasons.
For individual developers, this is the right shape of trust mechanism. The publisher's attestation is the authority that matters, and the consumer's policy is whatever the developer holds in their own head. For enterprises, the shape is mismatched. The enterprise has policy that is not in anyone's head: regulatory regimes, data residency commitments, internal segregation rules, customer contractual obligations, and audit retention requirements. The publisher attestation does not, and structurally cannot, attest to whether a skill is admissible inside that policy.
The architectural gap
Every operator-mediated marketplace eventually runs into the same structural problem at enterprise scale. The marketplace operator can certify what a publisher said about a unit of capability and that the unit has not been altered since publication. The operator cannot certify that the unit fits the consumer's specific deployment, because the consumer's deployment is governed by a policy regime the operator has no privileged knowledge of and no contractual mandate to enforce. The classic operator response is to publish guidelines, ask publishers to declare data-handling properties, and offer the consumer a longer activation prompt. The result is that admission decisions get made anyway, but they get made outside the architecture: in procurement workflows, in security review tickets, in spreadsheets that map skills to compliance frameworks, in approval signoffs that live in a different system from the activation event itself. The admission decision happens; it just happens outside the architecture.
The audit consequences are predictable. When the enterprise's compliance function asks why a particular skill is active in a particular deployment, the answer is reconstructed from artifacts that are external to the activation: an email approval here, a Jira ticket there, a security review document in a third place. The activation event itself records only that a user with admission rights installed a publisher-attested bundle. The chain from policy to admission is not architecturally captured. It is operationally reconstructed, with the gaps that reconstruction always has.
The gap is sharper still where the skill carries non-trivial authority. A skill that integrates with internal tooling, queries proprietary retrieval indexes, or invokes systems with side effects in the enterprise environment is, from a governance standpoint, a substantial extension of Claude's capability surface. The publisher attestation speaks to what the skill is and who shipped it. It does not attest to whether this enterprise should let Claude have this capability inside this tenancy under this policy. There is no built-in skill-authority binding between the skill and the enterprise's governance regime, only a binding to the publisher's identity.
What the consumer-side sandbox certification primitive provides
The LLM and Skill Gating inventive step of 19/647,395 treats every language-model-adjacent capability as untrusted until an evidence-backed gate opens. Applied to skill admission, the primitive places a sandbox evaluation between admission and activation. The deploying enterprise runs the candidate skill through a sandbox that exercises it against representative inference patterns drawn from the enterprise's own deployment. The sandbox observes the skill's tool invocations, retrieval queries, instruction-following behavior, and any other surface the enterprise's policy cares about. This is the multimodal evaluation and capability-gate pattern the specification describes: accumulated evidence of competence, evaluated against a policy, rather than a static credential or a one-time yes.
The enterprise's admissibility policy, encoded as a structured, governed artifact rather than as a procurement spreadsheet, evaluates the observations. If the policy admits, the enterprise's certification authority issues a certification token, which the specification defines as a cryptographically signed, time-bounded, evidence-backed attestation. The disclosed token carries a capability identifier, the holder identity, an evidence hash over the evaluated evidence corpus, an issuance timestamp, an expiration timestamp, the policy scope under which it was issued, the issuing authority identity, and the issuer's cryptographic signature. Mapped to skill admission, that token binds the specific skill version to the specific deployment under the specific policy at the specific evaluation time. The skill activates only on presentation of that token to the runtime.
Two structural properties follow. First, the activation event is cryptographically tied to the enterprise's policy authority, not just to the publisher's authoring authority. Publisher and marketplace attestation continues to establish that the bundle is what the publisher shipped; the enterprise's certification token attests that the bundle is admissible inside this deployment. Audit reconstruction is no longer required, because the policy-to-admission chain is captured in the token itself.
Second, the locus of activation authority moves to where the policy authority lives. The enterprise no longer relies on Anthropic to anticipate the enterprise's policy, an anticipation that is structurally impossible at scale across regulatory regimes and customer contracts. The enterprise produces the admission artifact on its own authority, against its own policy, with its own evidence. The architecture becomes one in which the publisher and marketplace attest to publication and the enterprise signs admission, and Claude's runtime enforces both.
Composition pathway with the Anthropic Skills surface
The primitive composes with, rather than displaces, Anthropic's existing Skills architecture. Anthropic's marketplace continues to publish and verify skills as it does today. The runtime gains an additional verification step that, for enterprise tenancies, requires a valid enterprise certification token alongside the publisher attestation. The sandbox evaluation runs in the enterprise's environment, against the enterprise's representative workload, under the enterprise's policy. The token produced is bound to the skill version, the deployment identity, and the policy version, and it participates in the disclosed token lifecycle: an active token can expire when its temporal window elapses, or be revoked on mastery regression, incident, or governance intervention regardless of expiration, and it returns to service only through revalidation against fresh evidence. A skill update or a policy change therefore invalidates the admission and triggers a fresh evaluation rather than silently extending the prior admission.
For Claude for Work and Bedrock-mediated deployments, the certification authority is the enterprise's own identity infrastructure. For developer-tier consumers, the primitive can be configured down to a permissive default that retains today's user experience while remaining available for tenants that opt into stricter admission. The composition keeps the developer experience for individual users while giving enterprise compliance functions the architectural primitive they have otherwise had to reconstruct out of approval workflows.
The integration is also operationally tractable. The sandbox is a runtime feature, not a model change. The token format is a small, signed credential. The enforcement step at activation is a verification, not a re-evaluation. The cost on the activation path is negligible; the cost saved on the audit path is substantial.
Embodiments and variations
The approach is not tied to a single deployment shape, and a skilled implementer can build it in several ways. The sandbox evaluation can draw representative inference patterns from recorded production traffic, from a synthetic workload generator seeded by the enterprise's policy, or from a red-team corpus targeting the skill's declared tool scope. The admissibility policy can be expressed as declarative constraints, as an executable policy agent, or as a composite of both, and it can gate on tool invocation targets, retrieval index boundaries, data-residency of side effects, output content, or any combination. The certification token can bind to a device or hardware entropy source, to a deployment identity anchor, or to a platform identity, and its expiration can be fixed, usage-metered, or tied to the validity of the policy version it was issued under. The evaluation evidence can be single-modality, such as transcripts of tool calls, or multimodal, fusing independent signals before the gate opens. Enforcement can sit in the model runtime, in a co-resident sidecar, or in a hardware-assisted admissibility gate. The capability gate can operate as a one-shot admission or as continuous evaluation that regresses or revokes a previously admitted skill when operational monitoring shows drift. These variations are illustrative rather than exhaustive; the common structure is that a skill's activation authority is an evidence-backed, policy-scoped, revocable token issued by the consuming party, not solely a publisher-side attestation.
Disclosure scope
The invention described here, including the structurally untrusted proposal generator, the evidence-based capability gate, the curriculum engine and progressive unlock, and the certification token and its lifecycle, is disclosed in United States Patent Application 19/647,395. This article is a dated public disclosure of that inventive step. All statements about Anthropic, Claude, Claude Skills, and any other named product or platform are external context describing the surrounding market and are provided for comparison only; they are not claims of the filing and are believed accurate at the time of writing based on publicly available information. Anthropic Skills is a product of Anthropic; references to it are nominative and describe its architecture at a general level. Nothing here should be read as attributing to 19/647,395 any feature of a third-party product, or as attributing to any third-party product a feature of 19/647,395.
