AI Coding Assistants vs Autonomous Coding Agents: What Changes When the AI Can Act

An AI coding assistant that suggests code and an autonomous coding agent that runs commands, pushes branches and opens pull requests are different security problems, and most programmes still govern both as if they were the first. With inline suggestions, a human reads every line before it exists, so the controls are about data sent to the provider and the quality of accepted code. Once the AI can execute, the controls move to credentials, execution boundaries, untrusted input and review gates, because the model now acts between the moments a human looks. This guide covers that autonomy step only: what changes in credentials, review gates and sandboxing when you move from suggestions to agents that run in the IDE, the terminal, a cloud sandbox or CI. It is written for application security, platform and identity teams deciding how far to let coding agents act. For the full control set see the AI Coding Agents Security Guide; for per-product IDE settings see the AI IDE and Coding Agent Security Guide.

Key takeaways

• Short answer: the threat model changes when the human leaves the loop between actions. An assistant's output is inert text until a developer accepts it; an agent's output is a command, a commit or an API call that has already happened.
• Credentials become the main control. An assistant borrows the developer's editor session; an agent uses whatever token, key or cloud role it can reach, including ones nobody meant to give it.
• Every input becomes a possible instruction. Issues, pull request comments, READMEs, dependency files and fetched web pages can steer an agent, which OWASP calls Excessive Agency (LLM06:2025) when combined with too much functionality, permission or autonomy.
• Review moves from the keystroke to the merge. The pull request, branch protection and required approvals become the human checkpoint, so the person who asked the agent for a change should not be the one who approves it.
• Sandboxing is the price of autonomy. Network off by default, no long-lived secrets inside the execution environment and short sessions let you grant autonomy without granting the developer's whole reach.

Where each option sits on the autonomy scale

The products blur the line, so define the options by what the AI can do without a human action in between, not by the brand. Most organisations run several levels at once.

Levels 1 and 2 are the "assistant" side of this guide; levels 3 to 6 are the "agent" side. The jump that matters most is from level 2 to level 3: it is the first point at which the AI's output runs before a human reads it.

Threat model: the coding assistant

What can go wrong: the risks are about data leaving and code arriving. Source code, secrets in open files and customer data in test fixtures are sent to the provider as context. Accepted suggestions can carry vulnerable patterns, outdated APIs or hallucinated package names that a developer then installs. GitHub's own documentation states that its agent "can produce incorrect or suboptimal code, including code that contains security vulnerabilities", and the same is true of any model at level 1 or 2.

Architecture in words: the editor extension sends the current file, neighbouring files and the prompt to a provider endpoint over TLS, using a token tied to the developer's seat. The response is rendered as ghost text or a diff. Nothing is executed until the developer saves, builds or runs it.

Failure modes:

• Context leakage: a .env file or a pasted connection string is sent as context and retained under the provider's terms. See AI Coding Tools and Secrets Sprawl.
• Unreviewed acceptance: long suggestions are accepted with a single key and skimmed, so the human checkpoint exists in name only.
• Dependency confusion by suggestion: a suggested package name that does not exist is later registered by an attacker.
• Shadow seats: personal accounts on consumer tiers sit outside the organisation's retention and training terms.

Controls that fit: a sanctioned enterprise tier with SSO, content exclusion for sensitive paths, secret scanning in pre-commit and CI, dependency allowlisting and the same code review and SAST you apply to human code. The seat, token and audit log lifecycle is covered in Securing the AI coding assistant estate, and review technique in the AI-Generated Code Review Guide.

Threat model: the autonomous coding agent

What can go wrong: everything above, plus the agent can act on what it reads. OWASP LLM06:2025 Excessive Agency names three root causes, excessive functionality, excessive permissions and excessive autonomy, and lists prompt injection, hallucination and compromised extensions as triggers. In a coding agent the triggers arrive through ordinary engineering inputs: an issue body, a pull request comment, a README, a dependency's install script, a test fixture, an MCP tool description or a web page fetched during research. In MITRE ATLAS this is AML.T0051 LLM Prompt Injection; when it leads to a malicious package or build step, the ATT&CK equivalent is T1195.001 Compromise Software Dependencies and Development Tools.

Architecture in words: a loop of model call, tool call, observation. Tools include a shell, file write, git, package managers, an HTTP fetcher and MCP servers. The loop runs inside a boundary (the developer's machine, a container, a cloud sandbox or a CI runner) with an identity (the OS user, a workflow token, an app installation token, a cloud role). What the agent can damage equals what that identity can reach from that boundary.

Failure modes:

• Ambient credential use: the agent finds a token in a file and uses it for something its task never needed. In the PocketOS database deletion, an agent working on staging used an unrelated platform token, created for domain management but valid across the account, and deleted production data and its backups in one call. This maps to T1552.001 Credentials In Files.
• Allowlist bypass: an auto-approved command prefix carries a chained second command. The Gemini CLI prompt injection flaw showed instructions in a README leading a terminal agent to run an allowed program with a malicious command appended, sending environment variables to a remote server.
• Repository configuration as code: instruction files, MCP configuration and hooks committed to a repository change agent behaviour for everyone who opens it. See Coding Agent Configuration File Attacks.
• Privileged CI trigger: an agent workflow runs on events that untrusted users can create, with write tokens and secrets in scope.
• Self-approval: the person who prompted the change approves the pull request, so no independent human ever reads it.
• Silent egress: the agent fetches or posts to arbitrary hosts, so injected instructions can carry data out (T1567 Exfiltration Over Web Service).

Side-by-side comparison

Credentials: what changes at the autonomy step

At level 1 the only credential is the seat token. From level 3 onwards, credential design is the control that decides how bad a manipulated agent can be.

• Separate the agent's identity from the developer's: a local agent inherits the OS user, so put it in a container or a separate user with its own short-lived credentials rather than the developer's SSO-cached cloud sessions. Cloud and CI agents should run as an app or workload identity, never a personal access token.
• Prefer federation over stored keys: GitHub recommends authenticating workflows to cloud providers with OIDC so that credentials are not stored as "long-lived secrets". The same pattern applies to model provider keys where the provider supports workload identity federation. See the GitHub Actions OIDC Federation Hardening Guide.
• Scope tokens to one repository and one purpose: set the default GITHUB_TOKEN to read-only and raise permissions per job. An agent that only opens pull requests needs contents and pull request write, not workflow or administration rights.
• Keep secrets out of the agent phase: make dependencies available in a setup step, then remove secrets before the model starts acting. Where a task truly needs a secret, inject it at runtime through a broker. See Runtime Secrets Injection for AI Agents Without Prompt Exposure.
• Retire credentials completely: deleting a CI secret does not revoke the key it held; revoke it at the issuer too.

Review gates: moving the human checkpoint

With an assistant the review happens at acceptance. With an agent the review has to happen at a gate the agent cannot pass on its own. Design gates in this order:

1. Who can start the agent: only users with write access, and ignore events from anyone else by default.
2. Where it can write: one dedicated branch per task, never the default branch; branch protection and required checks apply to agent branches as they do to human ones.
3. Who approves: at least one approval from someone other than the requester; the agent cannot approve or merge its own work.
4. What runs on agent code: CI workflows on agent-authored changes wait for a human to approve the run, so a modified workflow file cannot execute with repository secrets before review.
5. What reaches production: deploy rights stay with a separate pipeline identity behind an environment approval, never with the agent.

Required approvals only work if reviewers read the change. Track review time and diff size for agent pull requests and split large ones; a 2,000-line agent change approved in two minutes is a rubber stamp.

Sandboxing: the execution boundary

Self-hosted CI runners need particular care: GitHub notes they "can be persistently compromised by untrusted code in a workflow" and should almost never serve public repositories. Use ephemeral runners for agent jobs. Design patterns for isolation are in the AI Agent Sandboxing and Code Execution Guide and network controls in the Agent Egress Control and Network Isolation Guide.

How three cloud agents implement these controls

Platforms are listed alphabetically; order is not a ranking. Each has its own security guide on nhimg.org: Claude Code Security Guide, OpenAI Codex Security Guide and GitHub Copilot Security Guide. Features change, so confirm against current documentation (checked November 2026).

Availability: each product's features depend on plan and organisation policy as stated in its own documentation. The Claude GitHub App is granted its full permission set at install; Anthropic documents a custom app with only Contents, Issues and Pull requests for organisations that want a narrower set. Codex approval policy and sandbox mode are set in configuration or on the command line. Copilot cloud agent is available on paid plans subject to organisation and enterprise policy.

Worked scenario: promoting a team from assistant to agent

A payments team uses inline completion and chat. It wants an agent to take labelled issues, fix flaky tests and open pull requests. The decisions, in order:

1. Inventory reach: the repository's CI holds a cloud deploy role, a package publishing token and a database URL for integration tests. None is needed to fix tests.
2. Choose the boundary: the agent runs in an ephemeral sandbox, network off except the internal package mirror, with integration tests using a disposable database created in the setup step.
3. Choose the identity: an app identity with contents and pull request write on this repository only; no workflow write, so the agent cannot change CI files that run with secrets.
4. Restrict input: only issues labelled by a maintainer start a task; comments from users without write access are ignored.
5. Set the gate: agent branches use a dedicated prefix, require one approval from someone other than the requester and passing checks, and workflow runs on agent code need approval.
6. Pilot and measure: two weeks on one repository, then review blocked actions, egress attempts and review times before extending to the next.

The publishing token and deploy role never enter the agent's environment, so a poisoned issue can at worst produce a bad pull request that a reviewer rejects.

Decision guidance

• Stay at assistant level for repositories holding signing keys, release pipelines or production infrastructure code until you can sandbox and scope the agent; the productivity gain rarely justifies agent reach into those.
• Use a local agent in approval mode for exploratory work on a developer's own branch, with the agent in a container and auto-approve limited to read-only commands.
• Use a cloud or CI agent when tasks are well defined (dependency bumps, test fixes, small features) and you can give it its own identity, a dedicated branch and an independent reviewer.
• Use event-driven automation only for read-only or report-only tasks first; add write tools one at a time with a named owner.
• Small organisations: a hosted cloud agent with its default branch and approval rules often gives a stronger boundary than local agents on unmanaged laptops.
• Large organisations: register each agent identity with an owner, standardise one sandbox image and one federation pattern, and enforce rulesets at organisation level.

Detection and measurement

Collect the platform audit log, agent session logs, CI run logs and cloud provider logs, keyed by the agent's identity. Alert on an agent identity using a credential outside its declared scope, on agent sessions with network enabled outside the allowlist, on changes to workflow or agent configuration files in agent pull requests, and on any agent push to a protected branch.

• Sandbox coverage: percentage of agent sessions running in an isolated environment, target 100%.
• Long-lived credentials in agent reach: count of static keys available to agent sessions, target zero.
• Independent approval rate: percentage of merged agent pull requests approved by someone other than the requester, target 100%.
• Review depth: median review time per 100 changed lines on agent pull requests, watched for collapse.
• Blocked actions: denied commands and egress attempts per 100 sessions, investigated when they spike.

Framework mapping

Common failure patterns

• Same policy for both levels: an AI tool policy written for completions is applied unchanged to agents, so nobody owns execution rights.
• Auto-approve creep: developers widen command allowlists to stop prompts, and prefix matching lets chained commands through.
• Agent runs as the developer: cached cloud sessions, SSH keys and platform tokens on the laptop are all in reach of a local agent.
• Write tokens on untrusted triggers: an agent workflow runs on events from forks or outside users with secrets in scope.
• Requester approves the agent's pull request: the only human who reads the change is the one who wanted it.
• Prompt as a control: "do not touch production" in an instruction file stands in for a credential boundary.

Practitioner checklist

• Classify every AI coding tool in use by autonomy level, not product name.
• Run every local agent in a container or OS sandbox with no access to the home directory, SSH keys or cloud configuration.
• Give each cloud or CI agent its own app or workload identity scoped to one repository.
• Replace stored provider and cloud keys with OIDC federation where supported, and revoke retired keys at the issuer.
• Set network off by default for agent phases and allowlist package registries.
• Restrict agent triggers to users with write access and ignore untrusted events by default.
• Require independent approval and passing checks on agent branches; never let the requester approve.
• Hold CI runs on agent-authored changes until a human approves them.
• Mark agent commits and sessions so audit logs separate agent from human actions.
• Review agent configuration files in pull requests as you would CI workflow files.

Standards and references

• OWASP: Top 10 for LLM Applications 2025 (LLM01 Prompt Injection, LLM06 Excessive Agency)
• MITRE ATLAS: AML.T0051 LLM Prompt Injection
• GitHub Docs: Secure use reference for GitHub Actions
• Anthropic: Claude Code GitHub Actions
• OpenAI: Codex agent approvals and security
• GitHub Docs: Risks and mitigations for Copilot cloud agent
• GitHub Docs: About Copilot cloud agent
• Model Context Protocol: Security Best Practices

Related NHI Mgmt Group resources: AI Coding Agents Security Guide, AI IDE and Coding Agent Security Guide, CI/CD Pipeline Identity Security Guide, AI Coding Agent Incident Playbook.