AI Agent Governance for Coding Teams: A Practical Checklist for Claude Code, Cursor and Codex

Most writing on AI agent governance is aimed at enterprise risk teams and stays at the level of frameworks and pillars. If you run an engineering team where developers use Claude Code, Cursor or Codex every day, you need something more concrete: settings you can turn on this week and rules a developer can follow without a training session. This checklist is that version.

It comes down to five questions. Who runs the agents? What can they do? What needs a human? What gets recorded? And what are the agents told? The last one is the one most policies skip, and it is where a lot of the risk now sits.

1. Who runs the agents

Governance starts with knowing which agents are running on company code and whose account they run under.

• Put developers on company accounts. A developer paying for Claude Code on a personal card is outside every control you set. Team and Enterprise plans on Claude, and team plans on the other tools, give you one bill, single sign-on and settings you control. Our Claude Code Team plan guide covers what that buys you.
• Treat CI as its own identity. An agent running in a pipeline with an API key is not a developer. On Claude Code, a job that signs in with a Console API key doesn't receive the settings from your Team admin console, so it needs its own managed settings file on the runner.
• Know which tools are in use. Ask. The answer is usually more than one, and each has its own settings to configure.

2. What the agents can do

This is the part with the most tooling, and the part that most people mean by agent governance.

In Claude Code, permission rules allow, ask or deny each tool call. They're checked deny first, then ask, then allow, and they're enforced by Claude Code, not by the model. A line in CLAUDE.md asking Claude not to push is a request. A deny rule is a control. Our Claude Code permissions guide covers the syntax and a starter config.

For a team, the rules that must hold go in managed settings, which no developer can override. Two keys are worth setting on day one:

• permissions.disableBypassPermissionsMode set to "disable", so nobody runs a session that skips every prompt
• deny rules for reading secrets, such as Read(./.env) and Read(./secrets/**)

Be honest about the limits. A shell rule matches the command text the agent writes, so Bash(rm *) doesn't stop bash -c 'rm -rf build/'. When a rule has to hold, add OS-level sandboxing or a hook that inspects the full command. Permission rules are guardrails for normal behavior, not a security boundary on their own.

3. What needs a human

Decide which actions an agent may take alone and which need a person. A reasonable default for most teams:

You don't need a new tool for most of this. Ask rules in Claude Code cover pushes. Branch protection on GitHub or GitLab already blocks merges without review, and it applies to agent-written code the same way it applies to yours. The governance step is writing the table down and making sure the settings match it.

4. What gets recorded

When something goes wrong, you want to know what the agent did and who started it.

• Git history is your first audit log. Agent commits go through the same branches and reviews as everyone else's, and you can see them there.
• Claude Code telemetry. Claude Code can export usage metrics and events over OpenTelemetry to the monitoring system you already run, and admins can turn it on for everyone through managed settings.
• Enterprise audit logs. The Claude Enterprise plan adds audit logs and a Compliance API. If your security review asks for these, the Team plan won't pass it.
• A hook for shell commands. For a simple local record, a PostToolUse hook can append every shell command to a file:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{time: now, session: .session_id, cmd: .tool_input.command}' >> ~/.claude/bash-audit.log"
          }
        ]
      }
    ]
  }
}

A file on the developer's own machine can be edited, so treat it as a debugging aid, not evidence. For records that must hold up, send events somewhere central. Our Claude Code hooks guide has more on how hooks run.

5. What the agents are told

Here is the layer most governance policies miss. Every coding agent starts its session by reading instructions: CLAUDE.md, AGENTS.md, .cursorrules, skills, the tool descriptions from connected MCP servers, and any memory system you use. Those instructions shape every action the agent takes, and in most repos anyone who can open a pull request can change them.

The numbers from our study of 1,431 agent files in popular GitHub repos show how loosely this layer is managed today:

• 82% never mention destructive git commands, and 67% never mention secrets or .env files
• 132 repos keep two different sets of instructions in CLAUDE.md and AGENTS.md for the same codebase, so the agent's behavior depends on which tool a developer uses

Treat agent instructions like code that runs with your developers' permissions.

Give them owners. A CODEOWNERS file makes changes to these paths need a review from the team that owns them:

CLAUDE.md     @your-org/platform
AGENTS.md     @your-org/platform
.claude/      @your-org/platform
.cursor/      @your-org/platform
.mcp.json     @your-org/platform

Turn on "require review from code owners" in branch protection, or the file only suggests reviewers.

Keep one source of truth. If you use AGENTS.md, a CLAUDE.md that only says "see AGENTS.md" doesn't load it. Either delete the CLAUDE.md or import the file with @AGENTS.md.

Check what MCP servers you connect. A server's tool descriptions go into the agent's context like any other instruction. Approve servers the way you approve dependencies, and use managed settings to deny the ones you haven't approved.

Govern shared memory too. Teams increasingly share what their agents have learned, such as the working steps for a deploy or a migration. That makes shared memory an instruction source with the widest reach of all, since one change lands in every developer's agent. It needs the same thing CODEOWNERS gives your repo files: a person who approves changes before they spread.

A one-page policy

If you need something to put in front of your team this week:

1. Everyone uses agents through company accounts. No personal plans on company code.
2. CI agents get their own settings file and the narrowest permissions that work.
3. Managed settings deny reading secrets and disable bypass mode.
4. Agents may commit to branches. Pushes need a prompt. Merges need the same review as human code.
5. Agents never deploy or change CI, secrets or permissions without a person.
6. Agent instruction files and MCP config have code owners, and changes need their review.
7. One instruction file per repo, or an explicit import between them.
8. Shared agent memory has an approver for changes.

Paste each repo's CLAUDE.md or AGENTS.md into the free CLAUDE.md checker to see which guardrail topics it never mentions.

Where FixMyPrompt fits

FixMyPrompt covers item 8. Memories saves the fixes your developers' Claude Code, Codex and Cursor sessions work out, as steps the next agent can follow, and checks them for passwords, keys and other secrets before storing anything. On the Biz plan, memories are shared across the company, and admins decide what is shared and whether a change to a shared memory needs their approval before it reaches everyone. Every change keeps a version you can roll back to. It costs $25 a seat a month with a 2-seat minimum and a 7-day trial.

The rest of the checklist uses settings you already have. Most teams can get through it in an afternoon.