Rolling out coding agents to an engineering team without losing control

If you run an engineering team in 2026, coding agents are already on your engineers’ machines. In the 2025 DORA survey of nearly 5,000 technology professionals, 90% reported using AI at work and more than 80% believed it had made them more productive.¹ The question is no longer whether to allow agents. It is whether they run with settings someone chose deliberately, follow your conventions, stay away from production secrets, and produce changes your review process can actually absorb.

This is the rollout we use when a team asks us to turn ad-hoc agent use into something an engineering manager and a security lead can both sign off. It is tool-neutral: the controls exist, under different names, in every serious tool.

The landscape in August 2026

Four tools come up in almost every engagement. They differ less in raw capability than in where the agent runs and what an administrator can enforce.

Choosing tools

Pick on governance first and benchmarks second. The questions we ask:

• Where may code and context go? Local agents send context to a model provider; cloud agents also clone your repository into someone else’s environment. Check this against your data policies before anyone falls in love with a tool.
• Can an admin enforce settings? You need to block the “skip all approvals” modes centrally, not by asking nicely.
• Does the sandbox work on your machines? Claude Code’s Bash sandbox runs on macOS, Linux and WSL2 but not native Windows,⁷ which matters if half your team is on Windows.
• Does it fit your review flow? An agent that opens pull requests on GitHub inherits your branch protection; one that edits a laptop checkout relies on the engineer to push.

We usually standardise on one primary tool plus at most one secondary, with a shared instruction file so switching costs stay low. Allowing every tool means maintaining every tool’s security settings.

Permission modes, sandboxes and approval settings

Two separate controls decide what an agent can do. The approval policy decides when the agent must ask. The sandbox decides what a command can reach once it runs. You want both: approvals alone train people to click “yes”, and a sandbox alone does not stop a destructive action inside the workspace.

Claude Code

Claude Code has six modes: default (Manual), acceptEdits, plan, auto, dontAsk (only pre-approved tools, intended for CI) and bypassPermissions, which the docs reserve for isolated containers and VMs.² Rules are evaluated deny, then ask, then allow, and a deny in any scope beats an allow in another.⁸ Commit a project .claude/settings.json so everyone starts from the same baseline:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "mcp__issues__get_*"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  },
  "sandbox": { "enabled": true }
}

Then enforce the non-negotiables through managed settings (a managed-settings.json file, an MDM policy or server-managed settings), which user and project files cannot override.⁹ This one blocks bypass mode, denies .env files anywhere, and refuses to start if the sandbox cannot, rather than quietly running unsandboxed:⁸⁷

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(//**/.env)", "Read(//**/.env.*)"]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Three details matter. Auto mode can be removed centrally with disableAutoMode if you want to evaluate it before allowing it.² The sandbox’s default read policy still allows directories such as ~/.aws and ~/.ssh, so add them to its credential settings explicitly. And because the sandbox does not run on native Windows, scope a failIfUnavailable policy to macOS and Linux or have Windows users work in WSL2.⁷

OpenAI Codex

Codex combines a sandbox mode (read-only, workspace-write, danger-full-access) with an approval policy (untrusted, on-request, never, or a granular policy). In workspace-write, network access is off unless you enable it, and .git stays read-only. In Codex cloud, setup can reach the network to install dependencies, the agent phase runs offline by default, and secrets configured for the environment are removed before the agent phase starts.³ Admins pin the allowed values in requirements.toml; Codex falls back to a compliant value if a user’s config conflicts. This example from the docs blocks both never and full access:¹⁰

# ~/.codex/config.toml  (developer default)
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# requirements.toml  (admin-enforced: cloud-managed, MDM, or /etc/codex/requirements.toml)
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes     = ["read-only", "workspace-write"]

Recent Codex releases add permission profiles as the preferred way to express the same policy, so check which versions your fleet runs before choosing a format.¹⁰

Cursor

Cursor lets agents read files and edit workspace files without approval (configuration files excepted), asks before terminal commands and each MCP tool call, and limits its own tools’ network requests to GitHub, direct link retrieval and web search by default. Use .cursorignore to hide files from the agent. Run Modes range from an allowlist to an Auto-review classifier, and Cursor itself calls them best-effort guardrails rather than a hard security boundary.⁴ Terminal commands can also run in a sandbox with network blocked by default.¹¹ Workspace trust exists but is off by default; Cursor’s advice for untrusted repositories is to open them in a plain text editor.⁴

GitHub Copilot cloud agent

The cloud agent is the most constrained by design: only users with write access can trigger it, it pushes to a single copilot/ branch, its pull requests must be reviewed and merged by a human, the person who asked for the change cannot approve it, and Actions workflows do not run on its pull requests until someone with write access approves them. Its internet access goes through a firewall, its commits are signed and co-authored by the requester, and session logs are available to admins.⁶ Business and Enterprise customers must enable it by policy first.⁵

Instruction files: AGENTS.md, CLAUDE.md and friends

Agents follow written conventions far better than tribal ones. AGENTS.md has become the common format: when it moved to the Linux Foundation’s Agentic AI Foundation in December 2025, it had been adopted by more than 60,000 open source projects and agent frameworks.¹² Support is not uniform, though:

So we write one AGENTS.md as the source of truth and add thin tool-specific files only where needed. Keep it short and operational; Claude Code’s docs suggest staying under 200 lines per file, because longer files reduce adherence.¹⁶

# AGENTS.md

## Project
Payments API (TypeScript, Node 22, PostgreSQL). Services live in src/services/.

## Commands
- Install: npm ci
- Lint + types: npm run lint && npm run typecheck
- Unit tests: npm test -- <path>     (run the narrowest relevant tests first)
- Never run: npm run db:reset, anything under scripts/prod/

## Conventions
- Every behaviour change needs a test in the same PR.
- Money is integer minor units; never floats.
- New endpoints follow src/services/_template.ts.
- Do not edit generated files in src/gen/ — run npm run codegen instead.

## Boundaries
- Do not read or create .env files; use .env.example for variable names.
- Do not change CI config, CODEOWNERS or migrations without saying so in the PR description.
- Ask before adding a dependency.

## Pull requests
- Small PRs (under ~400 changed lines). Title: <area>: <change>.
- Description: what changed, why, how it was tested, and what the agent was unsure about.

# CLAUDE.md
@AGENTS.md

## Claude Code specifics
- Use plan mode for changes touching more than three files.

MCP connections to internal tools: read-only by default

The quickest productivity gain after the instruction file is letting agents read the issue tracker, docs and logs. The quickest way to cause an incident is letting them write to those systems. Start every MCP connection read-only and widen it per tool:

• Allowlist tools, not servers. Codex supports enabled_tools and a per-server default approval mode of prompt.¹⁷ Claude Code rules can target mcp__server__tool names, and it asks before connecting servers declared in a repository’s .mcp.json.⁸ Cursor asks per tool call unless you allowlist it.⁴
• Use the engineer’s own scoped credentials, never a shared service token with admin rights. If the internal server supports OAuth scopes, grant read scopes only for the pilot. Our guide to production MCP servers covers the server side.
• Treat tool output as untrusted input. An issue body or log line can contain instructions. Pair read access to untrusted content with no ability to send data out, and keep approvals on any write.

Secrets hygiene

Assume anything the agent can read may end up in a prompt, a log or a commit. The controls, in order of value:

1. Keep secrets out of reach. No production credentials on developer machines; short-lived, least-privilege dev credentials from your secrets manager; deny rules for .env files and credential directories.
2. Sandbox network egress so a compromised session cannot post a token to an arbitrary host.
3. Block secrets at push time. GitHub push protection checks pushes, web commits, uploads and API requests and blocks detected secrets before they enter history; at repository level it needs GitHub Secret Protection and is off until an admin enables it.¹⁸ Equivalent pre-receive scanning exists on other platforms.
4. Give cloud agents separate, minimal credentials. Codex cloud strips environment secrets before the agent phase,³ which is the pattern to copy elsewhere.

CI and code review guardrails

DORA’s 2025 finding is the reason this section exists: AI adoption now correlates with higher throughput but still with worse delivery stability, and the report attributes that to weak downstream controls such as testing and fast feedback.¹ More code arriving faster is only good if the pipeline catches what it should. Before widening access, make sure the default branch requires:

• Passing tests, lint and type checks, with coverage not allowed to fall on changed files.
• At least one human approval from someone other than the author or requester, plus CODEOWNERS review for sensitive paths (auth, payments, migrations, CI config).
• Secret scanning and dependency checks on every pull request.
• Labels or trailers identifying agent-assisted changes, so you can measure them later.
• No CI workflow running automatically on agent-authored changes to workflow files.

Reviewers need a norm too: review agent code as if a new hire wrote it. Read the tests first, check the change does only what the description says, and reject oversized pull requests rather than skimming them.

Team conventions

• The engineer owns the change. “The agent wrote it” is never an explanation in review or in an incident.
• Plan before large edits. Ask for a plan, correct it, then let the agent implement.
• Small, single-purpose pull requests. Agents make large diffs cheap to produce and expensive to review.
• Update AGENTS.md when the agent gets something wrong twice. Corrections belong in the file, not in individual chat sessions.
• No agents on production systems. Production access stays behind your normal change process.

A rollout plan: pilot group to team

Measuring impact honestly

Measure with the delivery metrics you already trust, not with how fast people feel. DORA’s five software delivery metrics split into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate).¹⁹ Add two review-side measures that agents stress directly: time to first review and review rounds per pull request.

Self-reported productivity is the wrong instrument. In METR’s randomised trial with 16 experienced open-source developers on 246 real issues, developers took 19% longer with AI tools allowed, having predicted a 24% speedup and still believing afterwards that they had been 20% faster.²⁰ That was early 2025 tooling, and METR has since said developers are likely more sped up now, while calling its newer data unreliable because many developers would no longer agree to work without AI.²¹ The lesson is not that agents slow people down. It is that perception and measured outcome can point in opposite directions, so surveys alone cannot settle the question.

A worked example, with hypothetical numbers for a pilot group of six engineers over six weeks, compared with the same engineers over the previous twelve:

The honest summary of that pilot is “faster to merge, with review load and stability to watch”, not “30% more productive”. Compare against engineers outside the pilot over the same weeks to control for seasonality and release cycles, and do not set agent usage targets: once usage is a goal, it stops telling you anything.

Failure modes

Rollout checklist

1. One primary tool (and at most one secondary) chosen against your data and admin requirements.
2. Managed settings deployed: bypass modes disabled, deny rules for secrets, sandbox required where supported.
3. Committed project settings with allow, ask and deny rules for common commands.
4. One AGENTS.md as the source of truth, with thin tool-specific files that import or mirror it.
5. MCP connections read-only, tool-allowlisted and using personal scoped credentials.
6. No production credentials on developer machines; push protection or equivalent enabled.
7. Required checks and independent human approval on the default branch; CODEOWNERS for sensitive paths.
8. Agent-assisted changes labelled so they can be measured.
9. Twelve weeks of baseline delivery and review metrics recorded before the pilot.
10. A pilot of five to eight volunteers with a weekly feedback loop.
11. Results judged on cycle time, review time and change fail rate against a comparison group.
12. A quarterly review of settings, tools and metrics.

None of this slows a good team down; it lets you say yes to agents with your eyes open. If you would like help designing the settings, conventions and measurement for your team, that is what our AI coding enablement work covers.

Sources

1. Google Cloud Blog, “Announcing the 2025 DORA Report: State of AI-Assisted Software Development,” 23 Sep 2025 — cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
2. Claude Code documentation, “Choose a permission mode” — code.claude.com/docs/en/permission-modes
3. OpenAI Codex documentation, “Agent approvals & security” — developers.openai.com/codex/agent-approvals-security
4. Cursor documentation, “Agent Security” — cursor.com/docs/agent/security
5. GitHub Docs, “About GitHub Copilot cloud agent” — docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
6. GitHub Docs, “Risks and mitigations for GitHub Copilot cloud agent” — docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations
7. Claude Code documentation, “Configure the sandboxed Bash tool” — code.claude.com/docs/en/sandboxing
8. Claude Code documentation, “Configure permissions” — code.claude.com/docs/en/permissions
9. Claude Code documentation, “Settings” — code.claude.com/docs/en/settings
10. OpenAI Codex documentation, “Managed configuration” (requirements.toml) — developers.openai.com/codex/enterprise/managed-configuration
11. Cursor documentation, “Run Modes” — cursor.com/docs/agent/security/run-modes
12. Linux Foundation, “Linux Foundation Announces the Formation of the Agentic AI Foundation,” 9 Dec 2025 — www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
13. OpenAI Codex documentation, “Custom instructions with AGENTS.md” — developers.openai.com/codex/guides/agents-md
14. Cursor documentation, “Rules” — cursor.com/docs/rules
15. GitHub Docs, “Adding repository custom instructions for GitHub Copilot” — docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
16. Claude Code documentation, “How Claude remembers your project” (CLAUDE.md) — code.claude.com/docs/en/memory
17. OpenAI Codex documentation, “Model Context Protocol” — developers.openai.com/codex/mcp
18. GitHub Docs, “About push protection” — docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection
19. DORA, “DORA’s software delivery performance metrics” (last updated 5 Jan 2026) — dora.dev/guides/dora-metrics/
20. METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” 10 Jul 2025 — metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
21. METR, “We are Changing our Developer Productivity Experiment Design,” 24 Feb 2026 — metr.org/blog/2026-02-24-uplift-update/

Tool behaviour, settings and defaults were checked against each vendor’s documentation as it stood in August 2026; these products change quickly, so confirm against current docs before deploying. Pilot figures in the worked example are hypothetical. Configuration samples are starting points, not drop-in policies.