Compliance

Compliance evaluations check your infrastructure code against rulesets and report how each rule resolves against the codebase. Evaluations can run manually, automatically after agent sessions, or as part of your GitHub CI pipeline. For an overview of how compliance works at the workspace level, see Workspace Compliance.

How evaluation works

When a compliance evaluation runs, an AI-powered agent explores your codebase using read-only tools. It reads files, searches for patterns, and checks each rule against the actual code. Every finding includes a justification citing specific files and line numbers.

Each finding resolves to one of five statuses:

Pass. The codebase satisfies the rule.
Fail. The codebase violates the rule or omits a required element.
Not applicable. The rule's scope has zero instances in this codebase. For example, a rule about S3 bucket configuration in a codebase that has no S3 buckets.
Inconclusive. The rule is verifiable from code and matching instances exist, but the available evidence is ambiguous or partial.
Non-code. The rule is about a process, training, or organizational policy that infrastructure code cannot witness either way. These findings are flagged for human review and typically indicate a rule that should be moved out of an IaC ruleset.

How the evaluator picks a status

The evaluator works through a fixed waterfall on every finding. Each step is a binary question; the first "no" wins. There is no default status, and no step is skipped.

Is the rule about something infrastructure code can witness? If no, the status is Non-code.
Does the rule's scope have any instances in this codebase? If no, the status is Not applicable.
Is there enough evidence to determine compliance? If no, the status is Inconclusive.
Does the evidence show compliance? If yes, the status is Pass. If no, the status is Fail.

This ladder is why the override policy treats Non-code findings differently from the others. Non-code is decided at step 1, before any evidence question has been asked, so a Pass or Fail override on a Non-code finding has nothing to override against. The right fix in that case is to remove the rule from the ruleset.

Scoring

The compliance score is passCount / (passCount + failCount). Pass counts toward the numerator; Fail counts toward the denominator only. Not applicable, Inconclusive, and Non-code are excluded from the score so a codebase is never penalized for rules that cannot fairly be evaluated against it.

Running evaluations

There are several ways to trigger an evaluation.

Manual. Click "Run Evaluation" on the workspace compliance page.

Agent. The workspace agent can run run_compliance_check() during a session. If "Auto-run after agent edits" is enabled in enterprise settings, the agent runs this automatically whenever it modifies infrastructure code in chat.

CI. When CI compliance checks are enabled, evaluations run automatically on every pull request and on every commit landing on the default branch. Results are posted as GitHub Check Runs with inline annotations.

Stable verdicts across re-runs

Two design choices make compliance verdicts reproducible enough to gate releases on:

The threshold is point-in-time. When an evaluation finishes, it stamps a pass / fail verdict against the Pass threshold that was active at that moment. Changing the threshold later does not retroactively flip prior evaluations. An auditor reviewing last quarter's evaluation always sees the verdict that was reached at the time, not what it would be under today's threshold.

Rollforward. When you re-evaluate a commit that has already been evaluated under the same ruleset, Infracodebase carries findings and their justifications forward from the prior evaluation instead of rolling a new agent run on unchanged files. The verdict is reproducible, the justifications stay coherent across runs, and the evaluator avoids paying compute to re-judge code it has already judged.

A full re-run is forced if the ruleset changed since the last evaluation, if a pattern in your evaluation scope failed to compile, or if you click Force re-evaluation from the dashboard.

Overrides

An override sets an effective verdict that takes precedence over the evaluator's status when scoring.

Pass. Count the rule as compliant. Useful when the evaluator missed existing code.
Fail. Count the rule as non-compliant.
Exclude. Remove the rule from scoring entirely. Useful for rules that genuinely do not apply to this workspace.

Two restrictions apply to every override:

Rules marked as required cannot be overridden.
Pass and Fail overrides cannot be applied to findings in the Non-code state. The right fix is to remove the rule from the ruleset, not to coerce it into the score.

Who can propose and ratify

Overrides follow a two-actor model. Submitting an override and ratifying it are separate verbs, gated by different permissions:

Users with workspace.compliance.manage can propose overrides. The override is staged as pending and does not affect the score.
Users with workspace.compliance.approve can ratify the pending proposal, revoke active overrides, or directly apply a new override without staging. A direct apply by an approver supersedes any pending proposal for the same rule.

The same gates apply uniformly across the dashboard UI, the REST API, and the agent's submit_compliance_overrides tool — an agent acting on a user's behalf cannot exceed that user's own permissions.

Enterprise-level approval (audit-grade governance)

By default, workspace approvers can both propose and ratify on their own workspaces. For deployments that need a separation between the workspace operators and the override approver, enable Require enterprise-level approval under Enterprise Settings > Compliance > Override governance.

When this toggle is on:

workspace.compliance.approve no longer unlocks ratification, revocation, or direct apply.
Only users with enterprise.compliance.approve can ratify, revoke, or directly apply overrides.
Workspace approvers still propose pending overrides, but they cannot ratify their own (or anyone else's) proposals.

The toggle takes effect immediately across every surface — the dashboard, the REST endpoints, and the agent's MCP tool — without re-issuing tokens or re-evaluating live overrides.

Audit trail

Each override and proposal carries forward across evaluations and persists until revoked. The audit log records the proposer separately from the ratifier when the two are different people, along with the justification text and the time of every state transition.

CI compliance checks

When CI compliance is enabled, Infracodebase automatically evaluates code on every pull request and on every commit that lands on the default branch, posting the result as a GitHub Check Run. Pull request checks include inline annotations showing which files triggered failures, directly in the PR diff. Default-branch checks act as the final guard on code that has already merged.

Setup

Install the Infracodebase GitHub App on your GitHub organization.
Connect a repo to a workspace in Infracodebase.
Add compliance rulesets to the workspace.
Go to Enterprise Settings > Compliance and turn on "Run on pull requests and the default branch" under Enforcement.
Set the Pass threshold (default is 80%).

No YAML files, workflow changes, or API keys are needed.

How it works

When a developer opens a PR, pushes new commits to a PR branch, or lands a commit on the default branch, GitHub sends a webhook to Infracodebase. Infracodebase clones the repo at the head commit, runs the compliance agent against your rulesets, and posts the results back as a Check Run. Failed findings on PR checks appear as inline annotations in the PR diff, pointing to the exact file and line.

Required rulesets and required rules

Enterprise rulesets marked as "required" guarantee coverage: they are always enabled on every workspace and cannot be disabled. This ensures all teams are evaluated against the same baseline standards. See Rulesets for more on required vs optional rulesets.

CI enforcement is controlled at the individual rule level. Rules marked as "required" act as hard gates. Any failure on a required rule fails the Check Run regardless of the overall score. This lets you mandate a broad ruleset across the organization while only hard-gating the specific rules that matter most for CI.

Branch protection

After enabling CI compliance, you can require the check to pass before merging. See GitHub's documentation on status checks for full details.

Go to your GitHub repo settings > Branches > Branch protection rules.
Enable "Require status checks to pass before merging."
Search for "Infracodebase Compliance" and add it as a required check.

Evaluation scope

Evaluation scope lets you connect every repo to Infracodebase without paying to evaluate every commit. When the scope is configured, commits that touch no infrastructure files reuse the prior evaluation result instead of triggering a fresh run. The verdict stays correct and your evaluation cost stays predictable as you connect more repos.

Configuring the scope

Evaluation scope is set per enterprise under Enterprise Settings > Compliance > Evaluation scope.

Turn on Skip evaluations on non-infrastructure commits.
Pick one or more Infrastructure-as-code tools. Each preset adds the file patterns and SDK markers that identify code from that tool. Infracodebase ships presets for Terraform / OpenTofu / Terragrunt, AWS CDK, CDKTF, cdk8s, Pulumi, CloudFormation / SAM, Serverless Framework, Azure Bicep / ARM, Kubernetes manifests, Helm, Kustomize, Crossplane, Argo CD / Flux CD, AWS Copilot, Docker, Ansible, Packer, Nomad / Consul / Vault, Chef, Puppet, SaltStack, and Tanka / jsonnet.
Pick any Exclusions that should never trigger a run, like build artifacts, lockfiles, and documentation.
Optionally edit Custom patterns directly to add internal IaC wrappers or one-off matchers that the presets don't cover.

Use the Test a file path input at the bottom of the section to confirm how the classifier would treat a specific file under the current configuration before applying it across runs.

What "in scope" means

A commit is in scope if it touches any file matched by an include pattern or containing a configured content marker, and not matched by an exclusion. In-scope commits run a full evaluation. Out-of-scope commits reuse the prior evaluation result and are marked as Skipped in the dashboard with a dotted outline so the bypass remains visible.

Safety nets

The scope feature is conservative by design. Infracodebase falls through to a full evaluation when:

The toggle is on but no presets and no custom patterns are configured. The settings UI labels this state as inactive and Infracodebase will not silently skip evaluations.
A custom pattern fails to compile. The bypass refuses to fire under a degraded pattern set.
The ruleset configuration changed since the last full evaluation. Carrying findings forward against a different set of rules would produce a stale verdict.

Enabling evaluation scope can only reduce cost, never silently relax enforcement.

Compliance settings

Compliance settings are in Enterprise Settings > Compliance.

Under Enforcement:

Pass threshold. The minimum score an evaluation must reach to pass (0-100%). Commits scoring below this value fail. Required rules always fail regardless of this threshold.
Run on pull requests and the default branch. When enabled, evaluations run on every pull request and on every commit that lands on the default branch. Results are posted as GitHub Check Runs. Requires the GitHub App to be installed.
Auto-run after agent edits. When enabled, the agent automatically runs a compliance check after writing or modifying infrastructure code in chat. When disabled, the agent stops at the edit and prompts the user to run the check.

Under Override governance:

Require enterprise-level approval. When off (the default), any user with workspace.compliance.approve can ratify or revoke overrides on their workspaces. When on, only users with enterprise.compliance.approve can ratify or revoke; workspace-level approval is bypassed. See Enterprise-level approval.

Under Evaluation scope:

Skip evaluations on non-infrastructure commits. Master toggle for the scope feature. See Evaluation scope for the full picture of presets, exclusions, and custom patterns.