What the gate does with missing or untrusted evidence
Compare an accepted check with missing evidence and a record signed using an unrecognized key.
Follow along
Goal: distinguish a signed claim from evidence accepted under a configured policy. This is a controlled exercise with a test repository, not a claim that signatures make a producer incapable of lying.
Before you start
Complete the push walkthrough. Have a human activate a policy that requires your chosen check command to succeed, with Block enforcement. Use a fresh disposable commit with no previously acceptable result for that required check. Retain the same repository, policy release, and commit throughout each case.
For the clean-diff example below, create the disposable README-only commit now, before recording metadata in step 1. Do not create another commit during the cases.
1. Identify the boundary
cilock agent status
git rev-parse HEAD
In Pushgate, record the active policy release and its required evidence, trusted producers, and enforcement mode. The agent's observational metadata is not its authenticated identity. A signature attributes an artifact to a signer; it does not establish that an arbitrary claimed test ran honestly.
If the repository requires the Git/agent metadata baseline, record it for this new commit before testing the additional check:
cilock attest --step push-metadata -a git -a alps-evidence
Expected: metadata is present for the exact commit, while the separate required check is still missing. This isolates the refusal case; missing metadata would otherwise confound the result.
2. Try a push without the required result
git push origin HEAD
Expected: refusal identifying the missing requirement. If the push succeeds, stop: inspect whether the policy is in Warn mode, the commit already has accepted evidence, the requirement is actually active, or the push bypassed the gate. Do not call that a passing negative test.
3. Try a signer the policy does not trust
This example requires a require-clean-diff step running git diff --check HEAD^ HEAD on the commit prepared before step 1. This checks whitespace, not application behavior. Use that configured requirement, or your team's designated test policy.
With OpenSSL installed, generate a disposable local key. Keep it outside the repository so it cannot be captured as a material or committed:
umask 077
DEMO_KEY_DIR=$(mktemp -d)
openssl genpkey -algorithm ed25519 -out "$DEMO_KEY_DIR/agent.key"
Using the platform endpoint from your approved setup, run the required check with this unrecognized key instead of the enrolled principal. Replace the example origin with your actual trusted HTTPS endpoint:
P=https://your-platform.example
cilock run --platform-url "$P" \
-k "$DEMO_KEY_DIR/agent.key" --step require-clean-diff \
-a git,product --enable-archivista -o own-key.json \
-- git diff --check HEAD^ HEAD
git push origin HEAD
Expected in the recorded configuration: no acceptable evidence is stored for that signer, and the required check remains unsatisfied. Inspect the actual error and refusal reason. A connectivity error is not a successful signer-trust test. Do not add the disposable key to the policy to make the exercise pass.
4. Supply the real passing result
Run the actual required command as the enrolled principal. For the demonstration's clean-diff policy:
cilock run --platform-url "$P" --step require-clean-diff \
-a git,product --enable-archivista -- git diff --check HEAD^ HEAD
git push origin HEAD
cilock pushgate status --remote origin --wait
Expected: the configured requirements are met and delivery is confirmed for that commit. Keep the refusal and delivery records so you can compare their subjects and policy identities.
What this exercise does not prove
It tests missing evidence and an unrecognized signer under your configuration. The clean-diff command checks whitespace, not application security or login rate limiting. It does not prove that a compromised trusted producer cannot fabricate results, that the test command covers every risk, or that all direct-write routes are blocked. Review producer trust and enforcement boundaries, isolate signing credentials, choose trusted execution environments, and restrict bypass routes.
Troubleshooting and cleanup
A different error, such as expired credentials, is not evidence that the intended rule worked. Resolve that error and repeat the case. Remove the temporary key directory you created and the disposable branch when finished; retain the exercise's evidence and decision records under your team's retention policy.