AI Agent Security Checks for GitHub and CI
Foo Guard turns an agent configuration scan into a merge decision. The sequence is scan, then policy, then a check, then the branch protection or pipeline rule you already use. The scan reads the configuration at a specific commit. It does not monitor the agent after deploy.
Two enforcement paths exist. Pro and Team accounts can fail any CI job with the CLI or the GitHub Action. Team workspaces can also publish a native GitHub Check named Foo Guard Security, without adding a workflow file, on repositories where the GitHub App is installed and the repository is enabled.
Scan, policy, check, merge
On a pull request or a default-branch push, a Team installation:
- Reads
.fooguard.ymlat the scanned commit SHA - Selects supported agent configuration files from the scan paths
- Runs the deterministic rules engine on those files
- Merges organization policy, repository policy, and defaults, keeping the strictest threshold
- Publishes Foo Guard Security with success, failure, or neutral
Success means the scan finished and policy passed. Failure means the scan finished and policy did not. Neutral means no supported configuration was found, or the run hit an operational error. Requiring the check in GitHub branch protection or a ruleset is what blocks the merge. Foo Guard does not bypass GitHub's own protection settings.
CLI exit codes and the GitHub Action
The CLI is the portable gate for GitHub Actions and for other CI systems. Exit code 0 means policy passed. Exit code 1 means policy failed, and the job should fail. Exit code 2 means an operational or configuration error, which is not the same as a finding.
A typical invocation is fooguard scan ./agents --fail-on high --min-grade B. Flags on that command can tighten the run. They cannot weaken a stricter organization policy. The GitHub Action calls the same API with a Pro or Team key. Free analysis in the browser does not include the CLI, the Action, or the API.
The Action does not upload SARIF. The check summary on GitHub includes grade, score, policy result, the effective threshold, top findings, and baseline status when a baseline is configured. Details stay in Foo Guard rather than in a code-scanning alert feed.
Exact SHA, baselines, and what is stored
GitHub scans analyze the commit SHA for that event. A later push scans the new SHA. Installation tokens used to read the repository are created for the scan and are not stored in the scan record. Raw repository configuration is not persisted. Scan records keep summaries, policy results, and structural finding locations.
An optional baseline compares the current scan with a committed baseline so a repository can fail when posture regresses. That comparison is still a static diff of scan results, not a runtime trace.
What the author sees
A failed Foo Guard Security check means the scan completed and the policy threshold was missed. The summary shows the grade, the score, the effective failOn and optional minGrade, which source set that threshold, and the top findings. The author fixes the configuration or the policy file and pushes. The next SHA is scanned on its own. A neutral check is the case to investigate setup: no supported file was in the scan paths, or the App could not complete the run.
Baseline regression is optional. When a repository has a baseline, the check also says whether the new scan is worse than that baseline. A regression fails policy even when you are tracking change over time rather than a single absolute grade. The baseline is a committed scan summary, not a recording of production traffic.
Choose the gate that matches the plan
Use the CLI or GitHub Action when you want a failing job in GitHub Actions, GitLab, Jenkins, or another pipeline. Use GitHub Checks and branch protection when a Team workspace should block merges inside GitHub. Both paths evaluate the same rules and the same policy file.
There is no scheduled nightly scan. A check runs because a pull request, a default-branch push, or a CI job asked for it.