The Deployment Was Approved. The Dangerous Change Wasn't.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

Imagine reviewing a deployment script line by line. Everything looks fine, so you approve it. The script doesn't change afterward. But just before the deployment, someone changes the configuration file it reads:

- "require_human_review": true
+ "require_human_review": false

If the approval check watches only the script, it can miss an edit that changes what the script does. The approved file hasn't changed, but the behavior you approved might have.

That's the problem I explored with ShadowInputs, an open-source Python CLI that records SHA-256 hashes for a reviewed set of repository-local inputs, then checks whether those exact files have changed before a simulated deployment. It is a focused proof of concept, not a general-purpose CI security product.

I started with Md Imran Hossen's October 2026 research paper, When the Approved File Is Unchanged: Authority-Set Integrity for Deployment and Coding-Agent Approvals. The paper examines approvals that bind one script or workflow even though execution depends on additional files. ShadowInputs is my small, reproducible experiment with that idea, not an implementation of the paper's full authority-set model.

Who might pay for this?

Business hypothesis, not proven demand: Small DevOps consultancies and teams maintaining sensitive release pipelines might pay for dependency-mapping audits, custom adapters, or integration of reviewed-input checks into their existing CI workflows. The CLI remains open source under MIT; a genuine commercial offering would require customer interviews, broader dependency discovery, and stronger approval and artifact integrity controls. I haven't acquired a paying user.

Demo

Watch the ShadowInputs video walkthrough on YouTube

The demonstration uses a synthetic GitHub Actions workflow, a Python deploy.py script, and a local policy.json. The workflow and entrypoint are supplied explicitly to the CLI; the prototype does not automatically understand every GitHub Actions step or runtime dependency.

Scenario	Observed CLI result	Exit code
Approved inputs unchanged	PASS	0
Unrelated documentation edit	PASS	0
Approved policy.json changed while deploy.py stayed unchanged	BLOCK	1
Approved policy.json deleted	BLOCK	1

The local Windows 11 / Python 3.14 verification run reported 20 tests passed, 1 skipped. The skipped symlink test required a Windows privilege unavailable in that environment. These tests validate the prototype's documented behaviors, not production security.

What happened when I tried real Gemma inference?

I used the open-weight Gemma 3 1B model through a local Ollama server to suggest file dependencies that deterministic analysis might overlook. This was a real model call, not a mocked response:

py -m shadowinputs inspect `
  --root .\examples\deployment `
  --entry .github/workflows/deploy.yml `
  --entry deploy.py `
  --model gemma3:1b `
  --output ai-review.json

The static scanner identified the workflow entry, deploy.py, and policy.json. Gemma contributed zero accepted additional file candidates. Its response included a placeholder path (relative/path), which the path validator rejected.

That's not the result I hoped for. But it matters: a successful model call is not proof of successful dependency discovery. In an integrity-sensitive workflow, model suggestions must remain untrusted until they have been checked and reviewed. The deterministic scanner and hash verifier, not Gemma, produced the successful PASS/BLOCK behavior shown above.

Evidence note: These images are rendered cards based on local terminal results, not unedited desktop screenshots. The video is linked separately for the walkthrough.

Code

GitHub: adarsh-singh106/shadowinputs

The implementation is deliberately small:

• shadowinputs/core.py: limited Python AST inspection for literal file reads, safe path handling, SHA-256 manifests, and comparison.
• shadowinputs/ai.py: local Ollama integration, treating model-suggested paths as untrusted hints.
• shadowinputs/cli.py: inspect, approve, and verify subcommands with meaningful exit codes.
• examples/deployment/: synthetic workflow, script, and policy file for reproduction.
• tests/: checks for drift, missing files, unsafe paths, and other defined boundaries.

To create and verify a manifest from the project root:

py -m shadowinputs approve `
  --root .\examples\deployment `
  --entry .github/workflows/deploy.yml `
  --entry deploy.py `
  --manifest "$env:TEMP\shadowinputs-approved.json"

py -m shadowinputs verify `
  --root .\examples\deployment `
  --manifest "$env:TEMP\shadowinputs-approved.json"

The approve command makes a manifest after the operator has reviewed the intended scope. It does not authenticate that operator or cryptographically sign an approval. Any real deployment integration would need to protect the manifest and bind approval to an authorized reviewer.

How I Built It

The design separates discovery, review, and verification:

1. Explicit scope and static analysis. The operator supplies entry files. A Python AST scanner finds certain literal file reads, such as Path('policy.json').read_text(). Some unresolved dynamic paths cause the tool to stop rather than claim completeness.
2. Local open-weight model. Gemma runs via Ollama on loopback, proposing additional candidate paths. The prototype validates those suggestions instead of automatically trusting them. In the reported run it provided no accepted additions.
3. Operator-reviewed manifest. For the chosen files, the CLI calculates SHA-256 digests and saves a snapshot outside the example repository. That is not a signed approval mechanism.
4. Deterministic verification. The CLI compares listed paths and their current contents against the manifest. An altered or missing listed file causes the check to fail. It does not itself launch or secure a real deployment.

What the prototype cannot guarantee

• It does not identify every input consumed by arbitrary Python, Bash, GitHub Actions, imports, environment variables, or external services.
• Files omitted from the manifest are not protected. PASS means only that the listed inputs still match.
• An external manifest path alone is not tamper-proof. A real system needs protected storage, access controls, and reviewer authentication.
• Inputs may change after verification. This time-of-check/time-of-use gap requires immutable artifacts or controlled execution.
• The local Gemma run did not improve dependency coverage in the experiment shown.

These boundaries are part of the project rather than footnotes: someone should be able to understand exactly what a green check does and does not mean.

Why Open Innovation Matters

Deployment source code can be sensitive, and security-related tooling benefits from being inspectable. Using Python, an open-weight Gemma model, and local Ollama inference lets developers experiment without shipping repository snippets to a hosted model API. The static checks and manifests can also be reproduced without depending on a model's answer.

The more lasting open-source value is the reproducible failure case and extensible discovery tooling. Another developer can inspect the hash calculation, contribute a parser for a different deployment language, test a tricky input pattern, or challenge our assumptions. That kind of scrutiny is especially useful when the tool is about trust.

What I'd Test Next

Before claiming that AI helps, I'd assemble real deployment patterns in which the static scanner misses an input, then compare static analysis alone versus static analysis plus Gemma suggestions. I'd measure accepted-candidate precision, dependency recall, and runtime. Until then, the only demonstrated security behavior is the deterministic, manifest-based drift check.

Prize Categories

• Best Use of Gemma: ShadowInputs integrates an open-weight Gemma 3 model, served locally through Ollama, as an experimental dependency-suggestion component. I have disclosed its observed result: zero accepted additional candidates in the demonstrated run. This establishes a real integration, not an accuracy improvement or a production-grade AI security system.