When Is It Safe to Just Let the Artifact In

A June 2026 framework proposes a threshold test for when institutions can directly admit an externally maintained package, model, or tool server, and what they should do instead when the test fails.

On June 4, 2026, a single-author paper posted to arXiv, The Custody Envelope Threshold: Authority-Scaled Admission of External Artifacts in Institutional Infrastructure, opens with a description of a problem most institutions have normalized rather than solved: dependence on "externally maintained artifacts such as package-registry dependencies, CI/CD actions, container images, Terraform providers and modules, developer extensions, model artifacts, and AI tool servers." These artifacts, the paper observes, are "easy to fetch but difficult for institutions to admit, govern, and revoke." The asymmetry between ease of acquisition and difficulty of governance is the paper's starting condition, not its conclusion.

The paper's proposed instrument, the Custody Envelope Threshold, is explicitly framed as an authority-scaled model. Its central claim is precise: "direct institutional admission is defensible only when object identity, ingress path, and revocation capacity are sufficiently closed relative to the execution authority delegated to the artifact." Three conditions, weighed against a fourth variable, the amount of execution authority an artifact is being granted, determine whether an institution should simply let an artifact run directly inside its infrastructure.

Reading the three conditions

Object identity, in this framing, asks whether the artifact being admitted can be reliably distinguished from a similar or maliciously substituted artifact, a question that has taken on new urgency across the software supply chain given repeated incidents of typosquatted packages and compromised registries. Ingress path asks how the artifact enters institutional infrastructure, whether through a vetted, controlled channel or through an open, minimally scrutinized one. Revocation capacity asks whether, once admitted, the artifact can actually be removed or disabled if it is later found to be compromised, which is a meaningfully different question from whether an institution has the contractual right to remove it.

The paper's framing treats these three properties as needing to be "closed," meaning resolved with confidence, in proportion to how much execution authority the artifact is being delegated. An artifact granted broad execution authority, one that can read sensitive data, make network calls, or modify infrastructure state, demands a correspondingly higher bar on identity, ingress, and revocation before direct admission is defensible. An artifact granted narrow, sandboxed authority can tolerate more uncertainty on those three conditions without direct admission becoming reckless.

What happens when the threshold is not met

The paper does not treat "reject" as the only alternative to direct admission. It names a spectrum: when the threshold is not met, institutions "tend to proxy, policy-mediate, vendor-mediate, internalize, quarantine, or reject the artifact." Each of these represents a different way of accepting the artifact's functional value while compensating for the unresolved identity, ingress, or revocation gap. Proxying interposes a controlled intermediary between the artifact and the institution's core infrastructure. Policy-mediation wraps the artifact's execution in enforced constraints rather than trusting it directly. Vendor-mediation shifts custody responsibility to a vetted third party rather than the institution itself. Internalizing means the institution takes on the burden of maintaining a forked or rebuilt version under its own control. Quarantine isolates the artifact's execution from sensitive systems entirely. Rejection is the only option that forecloses the artifact's use altogether.

An ordinal instrument, not a binary gate

The paper operationalizes this reasoning as "a four-condition ordinal instrument" connected explicitly to "reference-monitor reasoning, least privilege, and transaction cost economics." The reference to reference-monitor reasoning ties the framework to a long-standing concept in computer security, the idea of a trusted component that mediates every access request and cannot itself be bypassed. Tying that concept to transaction cost economics is a less conventional move: it frames the choice between proxying, internalizing, or rejecting an artifact as fundamentally an economic decision about where the cost of managing uncertainty is cheapest to absorb, not purely a technical security decision.

The paper applies this instrument across a specific set of artifact categories, "package dependencies, GitHub Actions, container images, Terraform providers and modules, developer extensions, and open model artifacts, with Model Context Protocol (MCP) servers treated as held-out evidence." Treating MCP servers as held-out evidence is a methodologically deliberate choice: rather than fitting the framework to MCP servers directly, the paper tests whether a framework built from other artifact categories generalizes to a category, agentic tool servers, that did not inform its construction.

The validation the paper stops short of

Notably, the paper is explicit that its empirical validation is not yet complete. It specifies "a validation design, deterministic prediction function, and OSF replication package for testing whether high-scrutiny institutions converge toward stronger custody closure for high-authority artifacts," and separately describes itself as a "preregistered framework and protocol paper" with the "empirical pilot" identified as "a separate planned study." The framework, in other words, is a testable hypothesis about institutional behavior, not yet a confirmed empirical pattern. Whether high-scrutiny institutions actually converge toward the predicted custody-closure behavior as artifact authority increases remains an open question the paper's own design acknowledges it has not yet answered.

Why MCP servers as held-out evidence matters for agent identity

AI tool servers built on the Model Context Protocol represent a category of artifact where execution authority can be difficult to bound precisely, an MCP server may expose a wide or narrow set of callable functions depending on configuration, and that configuration can itself be a vector for the kind of ambiguity the framework is trying to formalize. Applying a custody framework built from more conventional software supply chain categories to MCP servers as a genuinely held-out test is a meaningful methodological choice, but it is still a test performed on paper against historical reasoning, not yet against institutions actually making these admission decisions under the framework's guidance.

Open Questions

• Does the deterministic prediction function actually distinguish institutions that will converge toward stronger custody closure from those that will not, once the planned empirical pilot is conducted?
• How does an institution measure "revocation capacity" for an artifact in practice, given that contractual removal rights and actual technical ability to disable a compromised artifact are not the same thing?
• When an MCP server's exposed function set changes dynamically based on configuration, does the custody envelope threshold need to be reevaluated continuously, or only at initial admission?
• What happens when an institution's assessment of ingress path closure is itself based on vendor claims that cannot be independently verified?
• Does treating the admission decision as a transaction cost problem risk institutions choosing the cheapest compensating mechanism, such as policy-mediation, over the most protective one, such as quarantine, when the two diverge?
• If high-scrutiny institutions do not converge toward the predicted custody-closure behavior once tested empirically, what does that finding imply about the reference-monitor and least-privilege reasoning the framework is built on?

The governance artifact is retained. The governance function is not.