TL;DR: Enterprise AI coding governance is the set of controls that decides what coding agents like Claude Code or Codex can read and change, who approves each write or execution, and what evidence gets logged for audits. It matters now because adoption is already wide: 76% of developers were using or planning to use AI tools in 2024 (Stack Overflow Developer Survey, 2024). Start with least privilege connections, human approval before merge, and saved run records. ContextQA Ship, the autonomous quality engineer, tests every pull request and gives reviewers the evidence.
Many platform and security leads approve a coding agent rollout and only find the gaps when an audit asks for evidence. This guide covers permission scopes, approval gates, audit trails, and the verification evidence that shows what an agent changed and how the change was checked.
Quick answers
What may Claude Code or Codex touch through MCP? Only what one workflow needs. Connect through Settings → MCP, finish OAuth, then send a read only request first.
Who approves an agent's changes or test runs? A named human reviewer. The agent reads context, proposes an action, and runs only what the reviewer approves.
What evidence holds up in an audit? A chain from intent to test: build identity, run state, missing coverage and a named owner, kept with the pull request.
What is enterprise AI coding governance, and when do you need it?
Enterprise AI coding governance is the set of policies, permissions, and audit records that decide what coding agents like Claude Code or Codex may read, change, and run. It also covers who approves each action and what evidence shows the change works. You need it once agents open pull requests against repositories that ship to customers.
A usage policy describes the rules. Governance enforces them in your tooling. Auditors ask who approved a change and what verified it, not whether a policy document exists.
A usable policy covers five areas:
- Scope: the repositories, branches, and environments each agent may touch.
- Identity: every agent action runs under a named person, such as the OAuth identity behind a ContextQA MCP connection.
- Approval: which reads run automatically and which writes or test executions need human sign off.
- Logging: prompts, diffs, and commands, kept with the pull request.
- Evidence: test results tied to the exact build, attached before merge.
What do you need before you start?
Before you roll out Claude Code or Codex under governance, you need four things: a written policy on what agents may touch, a merge gate that still requires human review and security scanning, a Ship workspace with only the connections the pilot needs, and named approvers for every agent action that writes or executes something.
- Agent permission policy: List the repositories, branches and secrets each agent may read or write. Agent code follows the same pull request path as human code, never straight to protected branches.
- Security scanning on every PR: In CI, run SAST (static application security testing, which analyzes source code without running it), dependency scanning and secret scanning. Block merges on high severity findings. Ship tests how the code behaves and does not replace these scanners.
- Scoped Ship connections: Connect one repository first, then check its scope, read access and callback status (Connect Ship integrations and MCP).
- Named approvers: Assign an owner who approves each change or execution before an agent performs it.
How do you set up governance for coding agents, step by step?
Governance for coding agents takes four steps: limit what each agent can read and run, connect Ship through MCP under one OAuth identity, require a person to approve every write or execution, and gate delivery with a CI / CD test plan and review Ship test evidence. Each step leaves a record an auditor can check.
- Limit agent permissions in the repository. For Claude Code, commit allow and deny rules to the project settings file (Anthropic settings docs). For other assistants, check the vendor's own docs for admin, policy, and audit log controls before rollout.
mkdir -p .claude && cat > .claude/settings.json <<'EOF'
{
"permissions": {
"allow": ["Bash(npm run test:*)", "Bash(git diff:*)"],
"deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(git push:*)"]
}
}
EOF
- Connect Ship under one identity. Open Settings → MCP and choose Claude Code, Codex, or Cursor. Copy the configuration shown, complete OAuth, and send a read only request that confirms the organization and the available tools (Ship integrations and MCP). The ContextQA integrations page lists supported AI clients.
- Make a person approve writes. The agent summarizes its findings, proposes an action, and runs only the operation a reviewer approves. Map the remaining controls on the Ship security and controls page to your policy.
- Gate delivery with a CI / CD test plan. Open a validated test plan, select CI / CD, and set the secret reference, environment, trigger, timeout, and failure path. Review each run's evidence in the Ship dashboard and link it to its pull request.
What are the most common mistakes?
Four mistakes come up most often: broad agent access on day one, agents approving their own changes, chat transcripts kept in place of verification evidence, and data privacy and IP terms treated as a procurement checkbox. Each one leaves an auditor asking who approved a change, with no record to answer.
- Org wide tokens on day one: Ship's integration guide says to connect only what the workflow needs. Start with one repository, project or channel, and expand only after you verify it.
- Agents that approve their own changes: In the documented MCP flow, the client authenticates, checks its tools, and reads workspace context. Then it waits for a human to approve any change or execution.
- Transcripts as audit evidence: A chat log shows the agent ran, not that the code works. Keep repository test results, ContextQA execution evidence and exported code as separate, traceable artifacts.
- Trusting vendor defaults on privacy and IP: Each vendor's terms set retention, training on prompts, and ownership of generated code. Read them for your plan, and confirm that evidence is redacted before it reaches Slack.
How do you know it is working?
Governance is working when every merged agent change traces back to three things: the person who approved it, the test run that checked it, and the evidence that run produced. If any link is missing when you sample for an audit, more agent usage adds risk you cannot prove you controlled.
Two published numbers show why the evidence trail matters:
- Trust gap: In the Stack Overflow Developer Survey 2024, 76% of respondents said they use or plan to use AI tools, but only 43% said they trust the accuracy of those tools.
- Stability cost: The DORA 2024 Accelerate State of DevOps report estimated that a 25% rise in AI adoption goes with a 7.2% drop in delivery stability.
SOC 2 and ISO 27001 have no special rules for AI written code, but their change management controls still cover agent pull requests. GDPR applies when personal data shows up in prompts or test evidence. The EU AI Act (Regulation 2024/1689) mainly regulates the AI systems you ship, not the code an assistant writes for you.
Each month, sample a few agent PRs and confirm three things:
- You can find the OAuth identity that started the work.
- A person approved any write before it happened.
- The run evidence is still available in Ship (evidence).
How can you automate agent governance checks with ContextQA?
Ship, the ContextQA autonomous quality engineer, automates governance checks by testing every pull request that Claude Code or Codex opens. Before merge, it runs impact analysis and targeted regressions, then gives reviewers the evidence. Humans still approve every merge.
Once the MCP connection from the setup steps is in place, follow Connect Ship Integrations and MCP:
- Connect GitHub or GitLab with read access to one repository. Check the default branch and callback status.
- Open a validated test plan, select CI / CD, and check the secret reference, environment, trigger, polling, timeout and failure path.
- Connect Jira or Linear and set the project, issue type and write boundary for findings.
This gives you a CI / CD gate and run evidence for agent written code. Through the ContextQA MCP server, the agent reads first and waits for a reviewer to approve any change or execution. Before you rely on that evidence for audits, map it against the controls documented on the Ship security and controls page.
If Claude Code or Codex can open pull requests without clear approvals or an audit trail, see how Ship uses scoped connections and keeps run evidence for each pull request. Get started free with Ship, no credit card needed.
What should you do right now?
Find the AI coding tools your engineers already use, approve a short list, and shut off the rest. Route approved agents through scoped connections that keep a record, require a human to approve any write or execution, and keep verification evidence with each pull request so auditors can trace it from intent to result.
- Look for shadow AI (AI tools nobody approved): check IDE extension inventories, GitHub OAuth app grants, and outbound traffic to model APIs.
- Publish the list of approved AI clients and name an owner for each.
- Revoke OAuth grants for unapproved apps and give each team the approved replacement.
- Connect one repository to Ship and confirm the OAuth identity and tools with a read only request.
- In CI/CD gates, reference stored secrets instead of putting values inline.
- Map each control in Ship security and controls to your written AI policy, and keep the run evidence for each pull request.
Bottom line
Governing coding agents comes down to three written answers: what each agent may touch, who approves each change or execution, and what evidence each run leaves. Start with one repository under least privilege, confirm the OAuth identity and tools, require human approval for every write, and keep verification evidence with the pull request. Read what an autonomous quality engineer does and what an enterprise AI testing platform covers.
Sources
Every statistic and vendor claim in this guide links to its primary source. ContextQA steps come from the Ship documentation, and vendor permission settings come from each vendor's own docs.
- Anthropic, Claude Code settings documentation: permission allow and deny rules.
- Stack Overflow Developer Survey 2024, AI section: AI tool usage and trust in accuracy.
- DORA, 2024 Accelerate State of DevOps report: AI adoption and delivery stability.
- EUR-Lex, Regulation (EU) 2024/1689: scope of the EU AI Act.
- ContextQA, Connect Ship integrations and MCP: OAuth, scoped connections, read before write.
- ContextQA, Ship overview, Ship dashboard and evidence, and Ship security and controls.
