How to Enforce AI Agent Governance in CI (Not Just Document It)

Most AI agent governance lives in a document. Someone writes down the agent's intended autonomy — what it's allowed to do, where a human has to approve, what the worst case is — and everyone nods. Then the code changes fifty times, and nobody re-reads the document. The governance was claimed, never checked. That gap is where production incidents come from.

The fix is to treat an agent's safety boundary the way you treat everything else you care about in software: make it a check that runs automatically, on every change, and blocks the merge when it's violated. This post is about how to do that — computing an agent's Trust Level on every push or pull request, and failing the build when the agent gets riskier than your policy allows.

Claimed, verifiable, enforceable

There's a natural progression to making a governance claim trustworthy:

Claimed. You declare an agent's autonomy in a spec — an agentaz.json that states its worst-case action, its Trust Level, and its tool boundary (what can auto-execute versus what requires human approval). This is already better than governance living in someone's head, but a declaration is only a promise.

Verifiable. Anyone can run the reference validator against that spec and confirm the declared tier actually matches the boundary. The classification is deterministic — the same spec always produces the same tier — so it's not a matter of opinion. That makes the claim auditable.

Enforceable. The validator runs automatically in CI and blocks a change that pushes the agent past your risk policy. This is the step most teams never reach, and it's the one that actually prevents incidents — because it removes the human who forgot to re-check.

The agentaz-validate GitHub Action is how you reach that third step, and it takes about five lines.

The setup

Add an agentaz.json to your repository (the AgentAz specification has the schema and worked examples), then add a workflow:

# .github/workflows/agentaz.yml
name: AgentAz
on: [push, pull_request]
jobs:
  governance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: agent-kits/agentaz-validate@v1
        with:
          file: agentaz.json     # path to your spec (this is the default)
          min-tier: A4           # optional: fail if riskier than bounded autonomy
          strict: false          # optional: fail on thin, unclassifiable specs

On every push and pull request, the check reads your spec, computes the Trust Level, writes a summary to the run (the tier, the worst-case action, and the reasoning behind the classification), and — if you set min-tier — fails when the agent is riskier than you allow. It's self-contained and has no dependencies, so it runs anywhere without API keys or model calls.

What the check actually computes

The Action doesn't take your word for the tier — it derives one from the spec's tool_boundary, conservatively. The logic is simple and legible on purpose:

If the agent has no execution tools at all, it can't change anything, so it's ADV — advisory. If every consequential tool sits behind a human approval gate, it's A3 — it can act, but a person signs off on each irreversible step. If some tools auto-execute while others stay gated, it's A4 — bounded autonomy. And if everything auto-executes with no gate at all, it's A5 — full autonomy. The specification defines each band precisely; the point is that the tier follows mechanically from what the agent can do without a human, not from what the author hoped to convey.

Set min-tier: A4 and the check passes an ADV, A0, A3, or A4 agent and fails an A5 one. That single line turns your risk appetite into an automated gate.

What this catches that code review doesn't

The value shows up on the changes that look harmless. Three concrete cases:

A tool loses its gate. Someone moves a refund tool from approval-required to auto-execute to smooth out a common case. In a raw diff that's a one-line config change that reads as a convenience. To the check, it's an agent moving from A3 to A4 — and if your policy caps at A3, the build goes red before merge. The regression is legible where the code diff hid it.

An enterprise policy, enforced across repos. "No agent above A4 without a security sign-off" stops being a sentence in a wiki and becomes a check that runs on every repo that adopts it. The gatekeeper is automated and consistent.

A contribution meets the bar before it's accepted. A new agent submitted to a registry or a monorepo passes the same governance check as everything already there, so the quality bar holds without a manual reviewer eyeballing every spec.

Where it fits — and where it doesn't

Be clear about the layer this operates at, because governance tooling is often oversold. AgentAz is a design-time specification, and the Action verifies what that spec declares and enforces your policy in CI. It does not run your agent, intercept tool calls, or enforce anything at execution time. Your runtime still does that — framework guards, your own orchestration code, or a dedicated policy engine. The two are complementary: the spec says what the boundaries are in human-reviewable form; the runtime enforces them when the agent runs; and this check makes sure the declared boundaries don't quietly drift as the code evolves.

That's the whole idea. Capable agents are becoming abundant — anyone can generate one. What stays scarce, and what a security or compliance reviewer actually asks for, is a way to know an agent's boundaries and to catch when they change. Moving that from a document nobody re-reads to a check that runs on every pull request is a small change with an outsized effect: teams can ship fast and still answer, at any moment, exactly how much authority each agent holds.

If you're building agents and care about governance, add the Action to one repo, write an agentaz.json for your agent, and watch the check run on your next pull request. Then set a min-tier and see it hold the line.