What tasks should developers not delegate to AI coding agents?

What should stay with the developer, not the agent?

AI coding agents are best used for drafting, scaffolding, and repetitive implementation work. They should not be the final authority on security-sensitive decisions, because the developer still owns the blast radius, the trust boundary, and the consequences of a bad edit. That is especially true when the change affects authentication, authorisation, secrets, or access to production systems.

In practice, the safest split is between generation and judgment. The agent can propose code, tests, and refactors, but a human must decide whether the change is acceptable, whether the access path is appropriate, and whether the result creates new exposure. That division is the same reason teams keep humans in the loop for release approval and sensitive permission changes.

When the work touches access control or secret handling, treat the agent as a drafting tool, not a delegated operator. An AI agent may produce a plausible implementation that still widens permissions, leaks context into prompts, or normalises insecure patterns. The point is not to avoid automation, but to keep final authority with the person who can evaluate the security consequence.

Where AI coding agents are most likely to go wrong

The most dangerous failures usually come from a mismatch between what the agent can edit and what it can safely reason about. If you let it change auth flows, credential storage, token handling, or privilege checks, a small syntactic change can become a material security regression. The same applies when the agent is allowed to read sensitive repository context, environment variables, or deployment metadata that was never meant to be part of the prompt.

That is why a developer should never assume that a passing test suite means the change is safe. Tests may confirm that the code runs, but they do not prove that the new logic preserves access boundaries, resists abuse, or avoids unintended disclosure. The review step has to include semantics, not just syntax, especially for code that governs who can do what.

This is also where supply-chain and dependency risk enters the picture. Agents may suggest packages, snippets, or configuration changes that look convenient but introduce unvetted dependencies or unsafe defaults. AI Coding Agents Security Guide is useful background for the broader operating model, including secrets in context, sandboxing, and the safe use of agent permissions.

How to keep agent use productive without giving up control

The practical control is to scope the agent tightly and make the human the gate for anything that changes trust. Let the agent draft low-risk code, write tests, summarize diffs, or suggest refactors, but require a person to approve anything that affects access, secrets, production data, or deployment rights. That keeps the speed benefit while preserving accountability for the changes that can actually hurt you.

It also helps to reduce what the agent can see and do. Give it the minimum repository and tool access required for the task, keep sensitive contexts out of prompts, and separate ephemeral experimentation from production credentials. AI Agent Authorisation Guide is a strong fit for the least-privilege side of that operating model, while AI Agent Observability, Audit and Incident Response Guide helps when you need to verify what the agent actually did.

When the work is about agent identity, delegation, or lifecycle, the control decision gets even sharper. Identity Governance for AI Agents Guide and Agentic AI Identity Guide are relevant because they frame the ownership, approval, and retirement questions that arise when software acts with delegated authority.

Risk and Threat Considerations

AI coding agents become risky when they are allowed to operate inside trusted development contexts without adequate boundaries. A compromised prompt, poisoned repository, or over-scoped credential can turn a code assistant into a destructive actor that leaks secrets, changes permissions, or executes unsafe commands. Gemini CLI prompt injection flaw 2025 and Sentry MCP Agentjacking 2026 illustrate how hidden instructions and trusted tool output can push an agent into unsafe action.

Failure mechanism: The agent is given enough context, authority, or tool access to translate an unsafe instruction into a real environment change, while the human reviewer treats its output as if it were only advisory.

Impact: Unauthorized code execution, credential exposure, production data loss, or privilege expansion can follow, and the resulting change may look legitimate enough to pass a shallow review.

Practitioner Guidance

Decision rule: If the task can change who gets access, what a token can do, or whether a secret is exposed, keep the final decision with a human and require explicit review before merge or deployment.

What to verify: Check the diff for auth logic, permission checks, secret reads, dependency additions, prompt-injected instructions, and any place where the agent may have copied sensitive context into code or tests. A clean compile is not enough.

What not to automate: Do not automate final code approval for security-sensitive changes, and do not let the agent decide whether a control is “safe enough” when the change affects identity, credentials, or production access.

Practitioner takeaway: Use AI coding agents to accelerate drafting, not to inherit trust. The moment a change can affect access or exposure, the human reviewer must remain the security control of record.

Related resources from NHI Mgmt Group

• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?