ZitPit: Consumer-Side Admission Control for Agentic Software Intake

Abstract: AI IDEs and coding agents compress discovery, fetch, workspace open, installation, and execution into one low-observability loop. Existing defenses such as provenance frameworks, package and repository firewalls, runtime protection, and tool-approval prompts each cover part of that path, but they often leave the final consumer-side execution decision implicit. ZitPit is a 100% open-source Rust system that argues for a stricter boundary: first-seen external artifacts should become durable policy events before they gain execution rights on protected developer or CI hosts. The current public evidence is intentionally narrow and explicit. It includes repeated Git smart-HTTP intake measurements showing that approved artifacts can remain faster than unmanaged public fetch, plus implemented protected-session and governed-egress proof families. The broader contribution is architectural rather than universal-coverage-by-assertion: ZitPit unifies artifact admission, repo-open state, capability-scoped execution, and durable policy records at the consumer execution boundary for agentic workflows.

• The paper introduces a consumer-side admission control architecture that enforces execution rights via durable policy events.
• It details a four-stage pipeline with capability-scoped verdicts to mediate artifact intake and reduce ambient trust.
• Preliminary benchmarks demonstrate that managed artifact admission maintains lower fetch latency compared to unmanaged retrieval.

ZitPit: Consumer-Side Admission Control for Agentic Software Intake

Motivation and Problem Formulation

Agentic development environments have driven a compression of the software intake process, collapsing discovery, fetch, workspace open, install, and execution into a near-seamless loop with minimal human intervention or review. This new paradigm, exemplified by AI IDEs and coding agents, introduces pronounced supply chain risk. Existing defenses—provenance frameworks, package firewalls, runtime protection, and manual approval—tend to address only fragments of the broader intake-to-execution lifecycle and rarely anchor on the ultimate consumer-side execution decision. The core issue is the lack of a robust, consumer-enforced boundary where each first-seen external artifact must explicitly earn execution rights through durable, auditable policy records before impacting a protected environment.

ZitPit System Architecture and Policy Enforcement

ZitPit proposes and implements a consumer-side admission control system tailored for agentic workflows. The architecture introduces a four-stage controlled pipeline: acquisition, build, execution, and (optionally) release. Crucially, each artifact transiting this pipeline creates an immutable, recallable policy event recording selector, resolved identity, provenance status, policy verdict, contextual evidence, and revocation or expiry state.

This fine-grained mediation is capability-scoped, supporting verdicts such as FETCH_ONLY, UNPACK_ONLY, BUILD_NO_NETWORK, TEST_NO_SECRETS, RUN_DEV, and RUN_CI, allowing distinct permissions at each escalation level. Admission events are not binary: fetch, unpack, build, and execution are each separately authorized, reducing ambient trust by default.

For practical enforcement, ZitPit’s implementation is mature on the Git smart-HTTP intake (repository mediation), brokered protected sessions (pre-execution broker), and governed outbound egress (DLP/brokered uploads). The demonstration covers automated denial of secret reads, egress attempts, persistence, and a range of destructive or evasion primitives. However, full-path closure (especially for native package managers, submodules, LFS, raw installers, etc.) and universal host enforcement remain as future engineering targets.

Threat Model and Coverage Analysis

ZitPit’s operational threat model recognizes explicit coverage boundaries and openly addresses residual risk:

• Mandatory mediation: Only monitored/redirected paths are protected; out-of-band fetches or alternate trust channels weaken guarantees.
• Transitive closure and delayed resolution: Supply-chain risk can propagate through dynamic or deferred fetches (submodules, reusable workflows, post-install hooks).
• Repo-open and workspace surfaces: State changes or code activation can happen outside of normal package manager workflows, including opening devcontainers, memory files, and startup tasks.
• Trust plane and control-plane risks: Admission control is only as strong as the integrity of its policy/event store, key management, and evidence pipeline.
• Operator and system availability: Excessive latency, failure, or operational brittleness in the admission system incentivizes bypass.

The coverage evaluation is explicit: ZitPit’s implemented guarantees focus on selected intake and execution-prevention families. Ecosystem-complete mediation (especially across npm, PyPI, all GitHub Actions permutations, and complex workspace startup scenarios) is treated as a future deliverable, not an implicit or asserted property.

Empirical Evaluation

Deployability—rather than theoretical coverage—is emphasized as a hard constraint. In the preliminary benchmarks, ZitPit demonstrates that admitted, immutable artifacts accessed via a managed admission path (disk and in-memory cache) can offer lower median fetch latency than unmanaged public fetch, even across large public repositories.

Figure 1: Preliminary deployability result for the Git smart-HTTP intake path. Repository-level web fetch medians were 433–1062 ms, cache medians 32–44 ms, and hot cache medians 13–16 ms per repository ($N=5$ samples), demonstrating that managed intake does not inherently degrade performance.

This performance result is foundational for practical adoption; controls that introduce friction or slow down common operations are routinely circumvented. ZitPit’s architecture maintains rapid intake for previously admitted artifacts, reinforcing its deployability claim.

Related Work

ZitPit’s architectural stance contrasts with adjacent solutions:

• Provenance and Attestation Frameworks: TUF, Sigstore, In-Toto, SLSA, and ecosystem-native attestation/verification systems offer improved artifact lineage, immutability, and publisher accountability. ZitPit consumes these signals but positions enforcement at the consumer execution boundary.
• Workspace Trust and Application Control: Prior approaches (e.g., VS Code Workspace Trust, Windows Application Control, Apple Notarization) mediate execution at the application or workspace open boundary, but do not offer durable, capability-scoped policy events across arbitrary agentic artifacts.
• Hermetic/Reproducible Builds & Firewalls: Build-system isolation, checksum-backed module systems (e.g., Go modules), and package firewalls (Sonatype, Datadog, Socket) focus on source integrity and ingress screening; ZitPit extends this to repo-open state and arbitrary execution surfaces.
• Runtime Protection: Process monitoring post-execution (StepSecurity Harden-Runner) operates downstream of the ideal enforcement boundary, unable to prevent first-activation risk.
• Behavioral Analysis: Corpus-driven detection (OpenSSF Package Analysis) serves as evidence input for the admission system, not as a replacement for policy-anchored gating.

Limitations and Future Work

ZitPit’s public proof is intentionally limited and openly documented: it does not offer general agent or supply-chain safety, nor does it claim to neutralize trusted-publisher compromise, benign-by-proof-of-absence, or universal coverage of unmanaged paths. Areas for post-publication development include complete package-manager-native enforcement, low-level transport closure (including submodules and LFS), deeper workspace enforcement, and robust revocation/expiry mechanisms tied to provenance.

Operational viability remains a practical concern. Control planes must minimize false positives, approval burden, and break-glass exceptions without sacrificing coverage. Dynamic analysis (e.g., Mirage Lab integration) supplements—rather than replaces—durable policy gating.

Implications for the AI and Secure Development Landscape

The architectural contribution is a shift from source-focused enforcement to consumer-side explicit execution boundaries anchored by durable, auditable, capability-scoped policy events. As agentic development environments proliferate and the gap between external code discovery and host authorization vanishes, the need for explicit, rapid, and fine-grained admission control becomes central.

Broader adoption of consumer-side admission systems could reshape supply-chain security frameworks and align multiple existing paradigms (provenance, firewalls, workspace trust, runtime analysis, and agent governance) around a common execution boundary. Open standards and transparent policy/event schema will be imperative to prevent centralization or non-portable trust roots.

Conclusion

ZitPit introduces and justifies a consumer-side admission control boundary for agentic software intake, implementing artifact- and capability-scoped policy events to anchor execution rights in protected environments. The system’s public proof emphasizes operational viability—admitting that managed intake must perform as well as public fetch—while transparently publishing its coverage boundary and residual risks. ZitPit’s design marks a convergence for supply chain, provenance, and runtime security domains, highlighting the necessity of explicit, fine-grained execution gating as agentic development further compresses the software intake/execution interval.