Approving AI tools in the development team: which guardrails are needed

01

Why does a coding agent need different rules than autocomplete?

Autocomplete suggests text that a person accepts. A coding agent acts: it reads files, runs commands, installs packages and calls external tools. The same questions apply to it as to any account with permissions, plus a new one: instructions can hide inside files, tickets or web pages that it reads.

The OWASP project describes both risks for applications built on language models. Excessive agency comes from too much functionality, too many permissions or too much autonomy; among its countermeasures, OWASP names having a person approve consequential actions beforehand (OWASP, 2025). Indirect prompt injection occurs when a model processes input from external sources such as web pages or files (OWASP, 2025). In a repository, that means a README, an issue or a dependency can contain text that acts like an instruction.

The 2025 DORA report finds a positive correlation between AI use and delivery throughput, but still a negative one with delivery stability (Google Cloud, 2025). What studies on the quality of generated code show, and where their limits lie, is summarised in What studies show about the quality of AI-generated code. Which agent suits which team is compared in Choosing a coding agent.

02

What can run automatically, and what never should?

What can run automatically is whatever stays inside the working directory and is easy to undo: reading, searching, tests and linters. Package installs and network access run with a confirmation prompt. What should never run through the agent is merging into protected branches, deployments, access to production data and reading secrets.

These details follow the vendors' own documentation (Claude Code Permissions, Claude Code Sandboxing, Cursor Run Modes, Copilot Risks and Mitigations, Copilot Content Exclusion). Names and functionality change between versions.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(git push *)"],
    "ask": ["Bash(npm install *)"],
    "disableBypassPermissionsMode": "disable"
  }
}

03

How can review before merging be enforced?

Review is enforced when the platform requires it, not when a policy merely recommends it. On GitHub, that comes from rulesets: a mandatory pull request, a minimum number of approvals, dismissing approvals after new commits, requiring approval from someone other than the last person to push, and mandatory status checks before merging.

Two of these options suit AI tools particularly well (GitHub Docs). Dismissing approvals stops a last-minute fix from the agent slipping through unreviewed. Requiring approval from someone other than the last person to push stops someone pushing a change through their own agent and then approving it themselves. For the Copilot cloud agent, GitHub describes a built-in version of this: the person who requested the change cannot approve its pull request, and workflows by default only start once someone with write access allows them after review. For paths such as authentication or database migrations, a code owner rule requires approval from the people responsible.

What reviewers should watch for in generated changes

• Changed or deleted tests. An agent told to make tests pass can also just change the test.
• New dependencies. Does the package exist, is it maintained, does the licence fit?
• Permission checks. Does the check sit on the server, or only in the interface?
• Pipeline and configuration. Changes to CI files, permissions or environment variables deserve a second pair of eyes.
• Scope. A diff nobody can read calmly has not been reviewed. Small tasks produce reviewable pull requests.

Which debt patterns build up in generated code is described in Recognising technical debt in AI-generated code.

04

How can secrets be kept out of the agent's reach?

Secrets are safe when they never sit in the environment the agent works in. Exclusion rules and ignore files help, but they are not a boundary. What actually works is development credentials with no production rights, a sandbox with an allowlist of network destinations, and a block that rejects detected secrets when they are pushed to the repository.

• Exclusion is not a boundary. According to Cursor's documentation, .cursorignore does not block access through terminal and MCP tools. Anthropic explicitly describes Bash rules in Claude Code as not being a security boundary, and points to the sandbox for that instead.
• Session histories sit locally. According to Anthropic's documentation (2026), Claude Code stores them in plain text under ~/.claude/projects/ for 30 days by default (Anthropic). A key pasted into a session ends up on disk as a result.
• Push protection. GitHub blocks detected secrets, among other places, on pushes made from the command line. For a repository, this requires GitHub Secret Protection; people with write access can bypass the block with a justification, which raises an alert (GitHub Docs).
• Short-lived credentials. Development environments get their own narrowly scoped keys that can be revoked without consequences.

05

Is customer data allowed into an AI tool?

That depends on the contract and configuration of the specific plan: whether inputs are used for training, how long the provider retains them, where processing happens, and whether a data processing agreement is in place. Development itself usually works fine with synthetic or anonymised data, and production data has no place in working directories that an agent reads.

Vendor terms vary considerably by plan. Anthropic states that code and prompts under commercial terms (Team, Enterprise, API) are not used for training unless the customer explicitly opts in, and cites a default retention of 30 days there; consumer plans follow different rules (Anthropic). Cursor describes a Privacy Mode with no training on user data, which team administrators can turn on (Cursor). At GitHub, the Generative AI Services Terms have replaced the previously applicable product-specific terms since March 2026.

06

How should provenance and licensing of generated code be handled?

Generated code can resemble public code, including code under licence. Some tools check for this: GitHub Copilot compares suggestions against public code and can block matches or show them with their licence. Where a tool does not offer this, what remains are dependency licence checks in the pipeline and a closer look at suspiciously complete code blocks.

According to GitHub, code referencing compares a suggestion, together with roughly 150 characters of surrounding code, against an index of public repositories on GitHub.com; matches typically affect fewer than one percent of suggestions (GitHub Docs, 2026). The Suggestions matching public code setting either blocks matches or shows them with their source and licence. Code written or later changed by the developer is not checked against this index (GitHub Docs).

For policy, that means deciding which filters are active, checking dependency licences automatically, and looking at the provenance of larger, library-like blocks before adopting them. The legal position on liability for generated code is covered in Who is liable when AI-generated code causes damage?. Provider terms such as Anthropic's Commercial Terms of Service change over time and should be read in their current version.

07

How can changes made by a tool stay traceable?

It stays traceable when every change goes through a branch and a pull request, the description names the instruction given to the tool, and the tool's own configuration is version-controlled. Whether generated code is additionally flagged in the commit is a policy decision. What matters is that this decision applies consistently across every repository.

According to GitHub, the Copilot cloud agent commits under its own name and records the requesting person as a co-author (GitHub Docs); Git has the Co-authored-by trailer for exactly this (GitHub Docs). In Claude Code, shared project settings sit in .claude/settings.json inside the repository, while binding requirements sit in managed settings with the highest priority (Anthropic). That keeps it visible under which rules a given change was made.

08

How should an internal policy be structured?

A workable policy is short and describes principles, responsibilities and exceptions. The concrete rules live in configuration: managed settings, rulesets, push protection. That way, the document does not quietly go stale when a tool renames a feature, and enforcement does not depend on everyone having read it.