💻 computer science

The Custody Envelope Threshold: Authority-Scaled Admission of External Artifacts in Institutional Infrastructure

This paper proposes the "Custody Envelope Threshold," an authority-scaled framework for admitting external infrastructure artifacts that argues institutions should only directly accept objects when their identity, ingress, and revocation capabilities are sufficiently closed relative to their delegated execution authority, otherwise resorting to mediation or rejection to mitigate risk.

Original authors: Amadeus Brandes

Published 2026-06-08

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Amadeus Brandes

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine your company's digital infrastructure as a massive, high-security castle. Inside this castle, developers are constantly bringing in new tools, furniture, and supplies (called "artifacts") to build and maintain their work. These supplies come from the outside world: open-source libraries, pre-made containers, AI models, and code snippets.

The problem is that while it's easy for a developer to grab a tool from the internet, it's incredibly hard for the "castle guards" (the institution) to know if that tool is safe, where it came from, or how to get rid of it if it turns out to be a Trojan horse.

This paper introduces a new rulebook called the Custody Envelope Threshold. It explains why some tools get a "green light" to enter the castle, while others get stopped at the gate, put in a cage, or only allowed in if they are escorted by a guard.

Here is the breakdown using simple analogies:

1. The Core Idea: The "Custody Envelope"

Think of every tool you want to bring into the castle as a package. To let it in, you need to wrap it in a Custody Envelope. This envelope isn't made of paper; it's made of three specific locks:

Identity Lock: Do we know exactly what this is? (Is it the real thing, or a fake?)
Ingress Lock: How did it get here? (Did it walk through the front door with a badge, or did it sneak in through a window?)
Revocation Lock: If we find out it's dangerous later, can we instantly grab it and throw it out?

The Golden Rule: The strength of this envelope must match the power the tool has inside the castle.

Low Power: If the tool is just a decorative sticker (low authority), a flimsy envelope is fine.
High Power: If the tool is a master key that can open every door in the castle (high authority), the envelope must be made of unbreakable steel. If the envelope is weak, the tool cannot enter.

2. Why Some Tools Get Stopped (The "Governance Modes")

The paper argues that institutions don't just say "Yes" or "No." They choose different ways to handle tools that don't have a perfect envelope yet. Think of these as different security checkpoints:

Proxied (The "Buffer Zone"):
- Scenario: You want a popular tool, but it comes from a sketchy public street.
- Solution: You don't let it walk in directly. Instead, you have a trusted courier (an internal feed or mirror) pick it up, check it, and bring it in. The tool is still the same, but the path it took is controlled.
- Example: Downloading a software package through a company's private server instead of the public internet.
Policy-Mediated (The "Strict Contract"):
- Scenario: The tool is from a known place, but it might change its name or version later.
- Solution: You let it in, but only if it signs a strict contract: "You must stay exactly this version, and you must be signed by this specific person." If it changes, it's kicked out.
- Example: Allowing a GitHub Action only if it is pinned to a specific, unchangeable code version.
Vendor-Mediated (The "Escorted Tour"):
- Scenario: The tool is too complex or risky for you to check yourself.
- Solution: You hire a specialized security firm (a cloud provider or marketplace) to check it for you. You trust their envelope.
- Example: Using an AI model only through a managed cloud service that scans it for viruses before letting it run.
Internalized (The "Copy and Paste"):
- Scenario: The tool is so specific to your castle's layout that no outside vendor can understand it.
- Solution: You take the tool, copy it, wrap it in your own packaging, and make it an "internal" product. You own it now.
- Example: Taking a public code module and rewriting it to fit your company's specific security rules.
Quarantined/Rejected (The "No Entry" Sign):
- Scenario: The tool is too dangerous, and no amount of wrapping can make it safe enough.
- Solution: It stays outside. It can be looked at in a sandbox (a playpen), but it never touches the real castle.

3. The "Scrutiny" Factor

The paper notes that not all castles are the same.

Low Scrutiny: A small startup or a hobby project might let almost anything in because no one is watching. They might accept a weak envelope.
High Scrutiny: A bank, a hospital, or a government agency is watched by auditors, regulators, and customers. They must have strong envelopes. If they let a high-power tool in with a weak envelope, they will get in trouble.

The paper predicts that as an organization gets more "scrutinized" (more audited, more regulated), they will naturally start using stricter methods (like Proxies or Vendor Mediation) for powerful tools.

4. Real-World Examples from the Paper

The authors tested their rulebook on six types of tools:

Software Packages: Usually allowed, but only if they come through a company "proxy" (internal feed).
GitHub Actions (Automation Scripts): These are very powerful (they can change your code). They are often blocked unless they are "Policy-Mediated" (strictly pinned to one version).
Container Images (Pre-built software boxes): If they are random public boxes, they are risky. They are usually "Proxied" through a curated list of trusted images.
Terraform Providers (Infrastructure tools): These are powerful but have good "Identity Locks" (signatures), so they are often allowed directly.
Terraform Modules (Design templates): These are often "Internalized" because they need to be customized to fit your specific company layout.
AI Models: These are tricky. If they run code, they are high power. They are often "Vendor-Mediated" (run through a safe cloud service) or "Quarantined" until better safety tools exist.

5. The "Curl | Bash" Test

The paper mentions a common developer habit: curl | bash (downloading a script from the internet and running it immediately).

The Verdict: This is the ultimate "weak envelope." It has no identity check, no controlled path, and no way to revoke it.
The Prediction: In a serious, high-scrutiny company, this should be banned or heavily modified. If a bank is letting developers run random scripts from the internet on their production servers, the paper says that institution is failing its "Custody Envelope" test.

Summary

The paper isn't just saying "be careful." It provides a math-like formula for decision-making:

If the Tool's Power > The Envelope's Strength, then you must change the Envelope (Proxy, Mediate, or Internalize) or Ban the Tool.

It explains why different tools get treated differently: it's not about whether they are "open source" or "popular," but about how much power they have inside your system and how well you can control them.

Technical Summary: The Custody Envelope Threshold

Problem Statement

Modern institutional infrastructure relies heavily on externally maintained artifacts (e.g., package dependencies, container images, CI/CD actions, Terraform modules, model weights). While these artifacts are trivial for individual developers to fetch and compose, institutions struggle to admit, govern, revoke, or defend them after failure. Existing frameworks like SLSA, NIST SSDF, and Microsoft's S2C2F focus on producer integrity, secure development practices, or secure consumption maturity. However, they fail to explain a critical empirical puzzle: why comparable artifact classes produce divergent institutional outcomes. Some artifacts are admitted directly, others are proxied, policy-mediated, vendor-mediated, internalized, or rejected. The paper argues that current literature lacks a descriptive-predictive model explaining why different artifact classes bind on different custody conditions and how institutions select governance modes in response.

Methodology

The paper proposes the Custody Envelope Threshold, an authority-scaled model of artifact admission. The methodology is structured as follows:

Theoretical Lineage: The model synthesizes the reference-monitor tradition (least privilege, complete mediation) and transaction cost economics (governance modes as comparative institutional choices).
The Instrument: A four-condition ordinal instrument scores artifacts in a specific use context:
- Execution Authority ( $A$ ): The level of privilege the artifact receives (0: non-executing to 3: privileged production/infrastructure).
- Object Identity ( $I$ ): The stability and verifiability of the artifact's identity (0: unstable/implicit to 3: verifiable/policy-bound).
- Ingress Path ( $G$ ): The control over how the artifact enters the institution (0: direct public fetch to 3: policy-enforced boundary).
- Revocation Capacity ( $R$ ): The ability to block, remove, or replace the artifact post-admission (0: no path to 3: auditable rapid revocation).
The Closure Rule: Direct institutional admission is defensible only if the weakest link in custody meets the authority threshold:
$\min(I, G, R) \ge A$
If this condition fails ( $D = A - \min(I, G, R) > 0$ ), a "custody deficit" exists.
Governance Selection Heuristic: When direct admission fails, the institution selects the lowest-burden governance mode capable of closing the deficit. This selection depends on:
- Local Custody Specificity ( $S$ ): How much institution-specific knowledge is required for safe use (0: commodity to 3: institution-specific).
- External Closure Availability: Whether an external provider can supply the missing boundary.
- Institutional Scrutiny ( $Q$ ): The level of external/internal review pressure.
Derivation and Validation: The model is applied to six derivation cases (package dependencies, GitHub Actions, container images, Terraform providers/modules, developer extensions, and open model artifacts). It is stress-tested against curl | bash flows and evaluated against held-out evidence from Model Context Protocol (MCP) servers. A validation design is proposed involving independent coding of inputs and outcomes to test four hypotheses regarding authority scaling, binding deficits, context dependence, and scrutiny interaction.

Key Contributions

Descriptive-Predictive Model: Unlike prescriptive maturity frameworks (e.g., S2C2F), this paper offers a model that predicts why institutions choose specific governance modes (proxied, policy-mediated, vendor-mediated, internalized, quarantined) based on the interaction between artifact authority and custody closure.
Authority-Scaled Custody: The paper establishes that custody requirements are not static; they scale with the execution authority delegated to the artifact. A low-authority artifact requires modest controls, while high-authority artifacts demand strong identity, controlled ingress, and fast revocation.
Governance Mode Taxonomy: It defines six distinct governance outcomes not as arbitrary labels but as economic responses to custody deficits under delegated authority.
Operational Instrument: It provides a deterministic scoring rubric (0–3) for identity, ingress, revocation, and specificity, allowing for the mechanical prediction of primary governance modes.
Held-Out Evidence (MCP): The paper introduces Model Context Protocol (MCP) servers as a held-out artifact class, demonstrating that emerging governance surfaces (registries, gateways, scoped authorization) are materializing exactly as the model predicts for high-authority AI tools.

Results and Observations

The application of the framework to the six derivation cases yields the following patterns:

Package Dependencies: Typically exhibit ingress and namespace resolution deficits. The predicted and observed mode is Proxied (internal feeds, mirrors).
GitHub Actions: Often face mutable identity and high authority deficits. The predicted mode is Policy-Mediated (full-SHA pinning, allowlists) or Quarantined.
Container Images: Frequently suffer from revocation and ingress deficits. The mode is Proxied with curated runtime controls.
Terraform Providers: Despite high authority, strong identity (signing) and ingress (mirrors) allow for Admission with signed/locked distribution.
Terraform Modules: Bind on local custody specificity (architectural knowledge). The mode is Internalized (copied/wrapped internally).
Developer Extensions: Face endpoint authority and update control deficits. The mode is Policy-Mediated or Catalog-Mediated.
Open Model Artifacts: Often lack safe loading mechanisms and revocation paths for high-authority contexts. The mode is Vendor-Mediated (managed catalogs) or Quarantined.
MCP Servers (Held-Out): Early evidence suggests high-authority MCP servers are moving toward Vendor-Mediated governance (gateways, catalogs) as the ecosystem matures.

The paper notes that "curl | bash" persists in low-scrutiny contexts but is transformed or blocked in high-scrutiny environments, confirming the model's prediction that scrutiny drives convergence toward stronger custody.

Significance and Claims

The paper claims to shift the unit of analysis from "open-source approval" to "artifact-class admission." Its central significance lies in providing a falsifiable framework that explains institutional divergence:

Falsifiability: The model is weakened if high-scrutiny institutions routinely admit high-authority artifacts with weak custody closure without mediation. Conversely, it is weakened if strong custody closure does not correlate with admission.
Governance Economics: It reframes security decisions as economic choices where institutions select governance modes to minimize the burden of closing custody deficits relative to risk tolerance.
Predictive Power: The framework predicts that direct public fetching will decline in serious production paths, replaced by proxies, curated registries, and gateways, even as public artifact usage increases.
Distinction from Prior Work: It distinguishes itself from SLSA and NIST SSDF by focusing on the admission decision and the divergence of outcomes across artifact classes, rather than just producer integrity or secure development practices.

The paper concludes that institutions do not admit external artifacts simply because they are useful; they admit them only when usefulness can be converted into authority-scaled custody at an acceptable governance burden.