Git-Verified Agents: Closing the Supply Chain Gap
If you can't verify what code your agent is running, you can't trust it. Here's how version control and cryptographic signing create a chain of custody for agent definitions.
The Supply Chain Problem
OWASP A08 asks a simple question: Where does your agent definition come from? For most systems, the answer is troubling.
An attacker who can modify your agent's prompt has effectively compromised the agent—without touching any "code."
What Can Go Wrong
Prompt Tampering
An attacker modifies the system prompt to include malicious instructions. The agent looks the same but behaves differently—exfiltrating data, ignoring safety rules, or executing hidden commands.
Model Swapping
The configuration specifies one model, but a different model is actually used. This could be a cheaper model (cost savings fraud) or a compromised model (security attack).
Dependency Confusion
Malicious packages in the agent's toolchain. A compromised npm package or Python library that modifies agent behavior at runtime.
👻 Shadow Agents
Unauthorized agent definitions deployed alongside legitimate ones. Without a registry, you can't know what agents are actually running.
Git as Source of Truth
Git provides the primitives we need for supply chain security: immutable commits, cryptographic hashes, and signed authorship.
The Verification Chain
With this chain, you can answer: "Is this agent definition exactly what was approved, by whom, and when?"
Implementation Approaches
1. Fetch from Git at Runtime
Instead of deploying prompt files, fetch them directly from Git using a specific commit SHA. The agent always gets the exact version you specified—no drift possible.
git show abc123:agents/database/prompt.md
2. Verify File Hash at Load
If you deploy prompt files, compute their SHA-256 hash at runtime and compare against the expected hash stored in your registry. Any modification fails verification.
expected: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
actual: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ✓
3. Signed Manifests
Create a manifest file listing all agent files with their hashes, then sign the manifest with a deployment key. Verify the signature before loading any agent.
{ "agents": {
"database-v1": { "hash": "...", "path": "..." },
"auth-v1": { "hash": "...", "path": "..." }
}, "signature": "Ed25519..." }
Registry Trust Models
A registry adds a layer of trust between Git and runtime. Here's how registries can verify and attest to agent integrity:
Enrollment Verification
- • Agent submitted with Git repo + commit
- • Registry fetches and hashes files
- • Author identity verified via signed commit
- • Entry created with immutable reference
Runtime Attestation
- • Runtime queries registry for agent
- • Registry returns hash + public key
- • Runtime verifies loaded code matches
- • Usage logged with verified agent ID
The key insight: The registry becomes an independent witness. It attests that "this agent, at this commit, was enrolled by this author." Even if the Git repo is later modified, the registry's attestation remains.
The Verification Flow
Here's a complete verification flow from request to execution:
Request Arrives
Orchestrator receives task requiring "database-v1" agent
Registry Lookup
Fetch agent metadata: Git repo, commit SHA, file path, expected hash
Fetch Agent Definition
Retrieve prompt file from Git at exact commit (or verify cached copy)
Hash Verification
Compute SHA-256 of loaded content, compare to registry's expected hash
Execute with Confidence
Agent runs with verified identity; actions logged to audit trail
Next in the Series
Building Auditable Agents: Receipts, Rankings, and Runtime Monitoring
The final piece: how to prove what happened after the agent ran, and build trust signals over time.
Read Post 6