Two Policy Rules to Give Your AI Coding Agents Before Anything Else

Most teams adopting AI coding agents start with trust settings: what can the agent see, what can it change. Before you tune anything else, we'd start with two rules.

Rule 1: No production deploys on an agent's word

{ "id": "no-production-deploys", "action": "release.deploy", "resource": "production", "decision": "deny" }

An agent can propose a change, run tests and open a pull request. Shipping to production should still be a human decision, made with the evidence in front of them. A deny rule makes that explicit instead of hoping nobody wires it up.

Rule 2: Any change to your CI files waits for a person

{ "id": "review-ci-changes", "action": "diff.apply", "resource": ".github/**", "decision": "ask" }

Your CI configuration is what decides whether everything else is checked. A change to .github/workflows can quietly skip a test job or loosen a branch protection step. That makes CI files the highest-leverage target in the repo, for a buggy agent or a prompt injection alike. ask holds the change on an Approvals page until someone reviews it.

How the rules behave

• Strictest wins. When several rules match, deny beats ask, and ask beats allow, whatever their order.
• Ask fails closed. Where an action can't wait for a person, an ask is enforced as a deny.
• One reject stops it. On the Approvals page, a single reject ends the request.
• Versioned. Each save creates a new policy version, so you can see what changed and when.

If you're unsure about a rule's impact, run it in log-only mode first and watch which actions it would have blocked.

Video walkthroughs are on our YouTube channel: https://www.youtube.com/@AICodeOps

AI CodeOps is free during the open beta and free forever for non-commercial open source: https://aicodeops.dev