pith. sign in

arxiv: 2604.06241 · v1 · submitted 2026-04-05 · 💻 cs.CR

ZitPit: Consumer-Side Admission Control for Agentic Software Intake

Jepson Taylor (VEOX Research Group) , Chris Brousseau (VEOX Research Group) , Jordan Hildebrandt (VEOX Research Group) , Kelli Quinn (VEOX Research Group) This is my paper

Pith reviewed 2026-05-13 17:32 UTC · model grok-4.3

classification 💻 cs.CR
keywords admission controlagentic workflowsconsumer-side securitysoftware intakepolicy enforcementartifact admissionRust system
0
0 comments X

The pith

ZitPit requires first-seen external artifacts to pass durable policy events before execution on developer or CI hosts.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces ZitPit as an open-source system that tightens control at the exact point where AI coding agents and IDEs bring in external code. It treats the consumer execution boundary as the place where artifact admission, repository state, execution capabilities, and policy records must all converge into explicit, durable events. A sympathetic reader would see this as closing an implicit gap left by existing tools like provenance checks and runtime guards. The work shows that such enforcement need not slow intake, based on measurements of Git smart-HTTP flows where approved artifacts stayed faster than unmanaged ones.

Core claim

ZitPit is a Rust system that unifies artifact admission, repo-open state, capability-scoped execution, and durable policy records at the consumer execution boundary for agentic workflows, so that first-seen external artifacts become policy events before they receive execution rights on protected hosts.

What carries the argument

ZitPit, a 100% open-source Rust system that forces first-seen artifacts through durable policy events while preserving intake speed via Git smart-HTTP measurements and implemented protected-session and governed-egress controls.

If this is right

  • Approved artifacts remain faster than unmanaged public fetches in repeated Git smart-HTTP measurements.
  • Protected-session and governed-egress controls become concrete, implemented proof families at the consumer boundary.
  • The compressed discovery-to-execution loop in AI IDEs gains explicit observability through unified admission and policy records.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same boundary could be applied to non-coding agentic systems that fetch and run external code at runtime.
  • Policy records created at intake could later support automated audits or rollback decisions when new vulnerabilities appear.
  • Integration with existing package firewalls might shift some checks from upstream to this final consumer gate without duplication.

Load-bearing premise

First-seen external artifacts can and should be forced through durable policy events before execution without breaking the speed or usability of agentic workflows.

What would settle it

A direct comparison showing that ZitPit-protected Git smart-HTTP intake adds measurable latency or breaks common agentic workflows on real developer or CI hosts.

Figures

Figures reproduced from arXiv: 2604.06241 by Chris Brousseau (VEOX Research Group), Jepson Taylor (VEOX Research Group), Jordan Hildebrandt (VEOX Research Group), Kelli Quinn (VEOX Research Group).

Figure 1
Figure 1. Figure 1: Without mediation, human and agent requests can move newly encountered external software directly toward host execution; with ZitPit, first-seen artifacts are held behind policy check, capability grant, and quarantine when required. I. Introduction Agentic development has changed the tempo of software intake. A developer can ask an AI IDE to “set up this repo,” and the tool may immediately clone a reposito… view at source ↗
Figure 1
Figure 1. Figure 1: Preliminary deployability result for the Git smart-HTTP intake path. Repository-level web medians ranged from 433–1062 ms, cache medians from [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
read the original 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The paper presents ZitPit, a 100% open-source Rust system for consumer-side admission control in agentic software intake. It claims that first-seen external artifacts must be turned into durable policy events before gaining execution rights on protected hosts, unifying artifact admission, repo-open state, capability-scoped execution, and durable policy records at the consumer boundary. The narrow evidence consists of repeated Git smart-HTTP intake measurements showing that approved artifacts remain faster than unmanaged public fetches, together with implemented protected-session and governed-egress proof families.

Significance. If the architecture and measurements hold, ZitPit offers a concrete, enforceable boundary that closes the final implicit execution decision in AI IDE and coding-agent workflows. The open-source Rust implementation, the explicit narrow scope of the claims, and the provision of machine-checked proof families are positive contributions that could be extended to broader provenance and runtime-protection settings.

major comments (1)
  1. [Git smart-HTTP intake measurements] Git smart-HTTP intake measurements: the reported timings cover only already-approved artifacts and show post-approval speed relative to unmanaged fetch. The manuscript does not quantify the added latency, storage, or synchronization cost of creating and persisting the initial durable policy event on the first-seen path, which is the exact scenario the central unification claim must protect without breaking usability.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback and the recommendation for major revision. We address the single major comment below by committing to additional measurements that directly respond to the concern.

read point-by-point responses

  1. Referee: Git smart-HTTP intake measurements: the reported timings cover only already-approved artifacts and show post-approval speed relative to unmanaged fetch. The manuscript does not quantify the added latency, storage, or synchronization cost of creating and persisting the initial durable policy event on the first-seen path, which is the exact scenario the central unification claim must protect without breaking usability.

    Authors: We agree that the first-seen path costs are central to validating the usability of the unification claim. In the revised manuscript we will add explicit benchmarks measuring the latency, storage overhead, and synchronization cost of creating and persisting the initial durable policy event for first-seen artifacts. These new results will be presented together with the existing post-approval timings so that readers can assess the one-time admission cost relative to the subsequent speed advantage. The original measurements intentionally focused on the steady-state benefit; the revision will close the gap identified by the referee without changing the narrow scope of the claims. revision: yes

Circularity Check

0 steps flagged

No circularity: architectural claim rests on implementation, not derivation

full rationale

The paper presents ZitPit as an architectural unification of artifact admission, repo-open state, capability-scoped execution, and durable policy records at the consumer boundary. No equations, fitted parameters, predictions, or derivation chains appear in the provided text. The central claim is supported by system implementation details and Git smart-HTTP measurements on already-approved artifacts; the first-seen durable policy path is described but not quantified in the evidence. No self-citations of uniqueness theorems, ansatzes, or prior results by the same authors are invoked to force the architecture. The unification is therefore self-contained as a design proposal rather than a mathematical reduction to its own inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

Abstract-only view yields no explicit free parameters or invented entities; the central claim rests on the domain assumption that consumer-side policy events are feasible and desirable.

axioms (1)
  • domain assumption Approved artifacts can remain faster than unmanaged public fetch
    Stated as current public evidence in the abstract

pith-pipeline@v0.9.0 · 5495 in / 1094 out tokens · 54127 ms · 2026-05-13T17:32:15.722831+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

42 extracted references · 42 canonical work pages

  1. [1]

    Claude code: Getting started,

    Anthropic, “Claude code: Getting started,” https://docs.anthropic.com/ en/docs/claude-code/getting-started, 2026, accessed 2026-04-02

    work page 2026

  2. [2]

    Claude code: Model context protocol (MCP),

    ——, “Claude code: Model context protocol (MCP),” https://docs. anthropic.com/en/docs/claude-code/mcp, 2026, accessed 2026-04-02

    work page 2026

  3. [3]

    Claude code: Hooks reference,

    ——, “Claude code: Hooks reference,” https://docs.anthropic.com/en/ docs/claude-code/hooks, 2026, accessed 2026-04-02

    work page 2026

  4. [4]

    Claude code: Manage claude’s memory,

    ——, “Claude code: Manage claude’s memory,” https://docs.anthropic. com/en/docs/claude-code/memory, 2026, accessed 2026-04-02

    work page 2026

  5. [5]

    Claude code: Devcontainer reference,

    ——, “Claude code: Devcontainer reference,” https://docs.anthropic.com/ en/docs/claude-code/devcontainer, 2026, accessed 2026-04-02

    work page 2026

  6. [6]

    Claude code: Settings,

    ——, “Claude code: Settings,” https://docs.anthropic.com/en/docs/ claude-code/settings, 2026, accessed 2026-04-02

    work page 2026

  7. [7]

    Security hardening for GitHub Ac- tions,

    GitHub Docs, “Security hardening for GitHub Ac- tions,” https://docs.github.com/en/actions/security-guides/ security-hardening-for-github-actions, 2026, accessed 2026-04-02

    work page 2026

  8. [8]

    Reuse workflows,

    ——, “Reuse workflows,” https://docs.github.com/en/actions/ sharing-automations/reusing-workflows, 2026, accessed 2026-04- 03

    work page 2026

  9. [9]

    Visual studio code: Workspace trust,

    Microsoft, “Visual studio code: Workspace trust,” https://code. visualstudio.com/docs/editing/workspaces/workspace-trust, 2026, ac- cessed 2026-04-03

    work page 2026

  10. [10]

    Visual studio code: Copilot security,

    ——, “Visual studio code: Copilot security,” https://code.visualstudio. com/docs/copilot/security, 2026, accessed 2026-04-03

    work page 2026

  11. [11]

    The update framework documentation,

    The Update Framework, “The update framework documentation,” https: //theupdateframework.io/, 2026, accessed 2026-04-02

    work page 2026

  12. [12]

    Sigstore documentation,

    Sigstore Project, “Sigstore documentation,” https://docs.sigstore.dev/, 2026, accessed 2026-04-02

    work page 2026

  13. [13]

    in-toto,

    in-toto Project, “in-toto,” https://in-toto.io/, 2026, accessed 2026-04-02

    work page 2026

  14. [14]

    Supply-chain levels for software artifacts,

    SLSA, “Supply-chain levels for software artifacts,” https://slsa.dev/, 2026, accessed 2026-04-02

    work page 2026

  15. [15]

    Repository firewall,

    Sonatype, “Repository firewall,” https://help.sonatype.com/en/ repository-firewall.html, 2026, accessed 2026-04-02

    work page 2026

  16. [16]

    Supply-chain firewall,

    Datadog, “Supply-chain firewall,” https://github.com/DataDog/ supply-chain-firewall, 2026, accessed 2026-04-02

    work page 2026

  17. [17]

    Socket firewall,

    Socket, “Socket firewall,” https://socket.dev/firewall, 2026, accessed 2026- 04-02

    work page 2026

  18. [18]

    Harden-runner,

    StepSecurity, “Harden-runner,” https://www.stepsecurity.io/ harden-runner, 2026, accessed 2026-04-02

    work page 2026

  19. [19]

    Security-focused guide for AI code assis- tants,

    OpenSSF, “Security-focused guide for AI code assis- tants,” https://openssf.org/wp-content/uploads/2025/07/ Security-Focused-Guide-for-AI-Code-Assistants.pdf, 2025, accessed 2026-04-02

    work page 2025

  20. [20]

    Zitpit benchmark snapshot: Five public git reposito- ries,

    ZitPit, “Zitpit benchmark snapshot: Five public git reposito- ries,” Repository artifact, 2026, frozen benchmark snapshot under docs/benchmarks/snapshots/, accessed 2026-04-04

    work page 2026

  21. [21]

    Zitpit benchmark matrix,

    ——, “Zitpit benchmark matrix,” Repository artifact, 2026, source file: BENCHMARKS.md, accessed 2026-04-02

    work page 2026

  22. [22]

    gitsubmodules documentation,

    Git, “gitsubmodules documentation,” https://git-scm.com/docs/ gitsubmodules, 2026, accessed 2026-04-03

    work page 2026

  23. [23]

    partial-clone documentation,

    ——, “partial-clone documentation,” https://git-scm.com/docs/ partial-clone, 2026, accessed 2026-04-03

    work page 2026

  24. [24]

    Git large file storage,

    Git LFS, “Git large file storage,” https://git-lfs.com/, 2026, accessed 2026-04-03

    work page 2026

  25. [25]

    Vcs support,

    PyPA, “Vcs support,” https://pip.pypa.io/en/stable/topics/vcs-support/, 2026, accessed 2026-04-03

    work page 2026

  26. [26]

    The cargo book: Source replacement,

    The Rust Project, “The cargo book: Source replacement,” https://doc. rust-lang.org/cargo/reference/source-replacement.html, 2026, accessed 2026-04-03

    work page 2026

  27. [27]

    package.json,

    npm, Inc., “package.json,” https://docs.npmjs.com/cli/v11/ configuring-npm/package-json, 2026, accessed 2026-04-02

    work page 2026

  28. [28]

    Secure installs,

    PyPA, “Secure installs,” https://pip.pypa.io/en/stable/topics/ secure-installs/, 2026, accessed 2026-04-03

    work page 2026

  29. [29]

    The cargo book: Build scripts,

    The Rust Project, “The cargo book: Build scripts,” https://doc.rust-lang. org/cargo/reference/build-scripts.html, 2026, accessed 2026-04-02

    work page 2026

  30. [30]

    devcontainer.json reference,

    Dev Containers, “devcontainer.json reference,” https://devcontainers. github.io/implementors/json_schema/, 2026, accessed 2026-04-03

    work page 2026

  31. [31]

    Diplomat: Using delegations to protect community repositories,

    J. Cappos, J. Samuel, S. Bakeret al., “Diplomat: Using delegations to protect community repositories,” in13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), 2016, pp. 567–581. [Online]. Available: https://www.usenix.org/conference/nsdi16/ technical-sessions/presentation/kaptchuk

    work page 2016

  32. [32]

    in-toto: Providing farm-to-table guarantees for bits and bytes,

    S. Torres-Arias, A. Ammula, R. Curtmola, and J. Cappos, “in-toto: Providing farm-to-table guarantees for bits and bytes,” in28th USENIX Security Symposium (USENIX Security 19), 2019, pp. 1393–1410. [Online]. Available: https://www.usenix.org/conference/usenixsecurity19/ presentation/torres-arias

    work page 2019

  33. [33]

    Use artifact attestations,

    GitHub Docs, “Use artifact attestations,” https://docs.github.com/en/ actions/security-guides/use-artifact-attestations, 2026, accessed 2026-04- 02

    work page 2026

  34. [34]

    Trusted publishing with OIDC,

    npm, Inc., “Trusted publishing with OIDC,” https://docs.npmjs.com/ trusted-publishers, 2026, accessed 2026-04-02

    work page 2026

  35. [35]

    Publishing to pypi with a trusted publisher,

    PyPI Docs, “Publishing to pypi with a trusted publisher,” https://docs. pypi.org/trusted-publishers/, 2026, accessed 2026-04-02

    work page 2026

  36. [36]

    Pypi publish attestation (v1),

    ——, “Pypi publish attestation (v1),” https://docs.pypi.org/attestations/ publish/v1/, 2026, accessed 2026-04-02

    work page 2026

  37. [37]

    The go checksum database,

    The Go Authors, “The go checksum database,” https://go.dev/ref/mod# checksum-database, 2026, accessed 2026-04-02

    work page 2026

  38. [38]

    Application control for windows,

    Microsoft Learn, “Application control for windows,” https: //learn.microsoft.com/en-us/windows/security/application-security/ application-control/app-control-for-business/appcontrol, 2026, accessed 2026-04-03

    work page 2026

  39. [39]

    Safely open apps on your mac,

    Apple Developer, “Safely open apps on your mac,” https://support.apple.com/guide/mac-help/ open-a-mac-app-from-an-unidentified-developer-mh40616/mac, 2026, accessed 2026-04-03

    work page 2026

  40. [40]

    Hermeticity,

    Bazel, “Hermeticity,” https://bazel.build/basics/hermeticity, 2026, ac- cessed 2026-04-03

    work page 2026

  41. [41]

    Package analysis,

    OpenSSF, “Package analysis,” https://package-analysis.com/, 2026, ac- cessed 2026-04-03

    work page 2026

  42. [42]

    Malicious packages repository,

    ——, “Malicious packages repository,” https://github.com/ossf/ malicious-packages, 2026, accessed 2026-04-03

    work page 2026