Ten Failure Modes in Agentic Coding, from Prompt Injection to False Completion

A coding agent joins security domains that were previously separate

A conventional code assistant emits text. An agentic coding system can read repositories, execute shell commands, install packages, call remote tools, query issue trackers, use credentials, modify tests, create branches, and sometimes deploy. Every added capability creates useful feedback and a new path from uncertain interpretation to state change.

The risk of an action $a$ is not reducible to model error probability. A simple decomposition is

where $L(a)$ is consequence. Better models can reduce the first factor. Sandboxes, permission policy, independent evaluators, and staged execution reduce the others. Security architecture should assume every factor is nonzero.

OWASP’s 2025 taxonomy separates prompt injection, information disclosure, supply chain, poisoning, improper output handling, excessive agency, and unbounded consumption, among other risks ^[4]. Coding agents combine all of them with ordinary software-security defects. The following ten modes are therefore organized by mechanism rather than by product branding.

Threat-model the deployment before naming defenses

A threat model begins with assets and principals, not model behavior. Assets can include source code, signing keys, package credentials, production data, vulnerability reports, unreleased features, build capacity, and the integrity of tests. Principals include the developer, organization, model provider, repository contributors, dependency maintainers, MCP operators, cloud environment, and external content authors. One entity can occupy several roles.

Draw data flow across trust zones: user prompt; repository; model service; local harness; subprocess sandbox; network proxy; package registry; MCP server; CI; and production control plane. For every edge, record data classification, authentication, authorization, integrity evidence, retention, and whether the transfer is reversible. The diagram should include model-visible observations and actions the model never sees, such as secret substitution by a proxy.

An attack path is a sequence of capabilities. If graph edge $e$ has exploitation probability $p_e$ and consequence multiplier $l_e$, prioritization cannot use $p_e$ alone. A low-probability path to release signing can dominate frequent harmless prompt deviations. Remove edges before trying to make the model refuse them.

Traditional threat categories still apply—spoofing, tampering, repudiation, disclosure, denial of service, and privilege escalation—but natural-language control adds two recurring ambiguities. First, data can imitate policy. Second, model output can imitate evidence. Treat provenance and executable verification as security boundaries, not interface decoration.

1. Indirect prompt injection

An indirect prompt injection places instruction-shaped content in data the agent later reads: an issue, README, webpage, test log, dependency documentation, source comment, or tool response. The model cannot reliably infer authority from grammar alone. Retrieved text and developer instructions both arrive as tokens.

Greshake and colleagues demonstrated that LLM-integrated applications blur data and instruction, enabling remote manipulation through content likely to be retrieved ^[1]. InjecAgent later assembled 1,054 cases across user and attacker tools and reported material attack success in its evaluated agents ^[2]. AgentDojo provides an extensible environment with 97 tasks and 629 security cases, emphasizing that useful task performance and injection resistance must be measured together ^[3].

Controls: mark provenance; isolate untrusted content; do not interpolate it into high-priority instructions; use allowlisted tools; keep network and credentials absent unless needed; require deterministic policy for side effects; scan but do not trust model-based detection alone.

Test: place benign, clearly unauthorized action requests in every data channel and verify that no external state changes, secrets leave, or permissions broaden.

2. Confused-deputy authority

The agent becomes a confused deputy when it possesses authority the user has but applies it on behalf of an untrusted principal. A malicious issue cannot access a private repository token directly, but it may persuade an agent that can.

The Model Context Protocol specification warns that tools can represent arbitrary code execution, tool annotations may be untrusted, and hosts must retain consent and access control ^[9]. A server description saying “read-only” is metadata, not enforcement.

Let user-intended authority be $A_u$ and agent-held authority be $A_g$. The dangerous excess is

where intended authority depends on goal $g$ and state $s$, not merely user identity.

Controls: issue task-scoped capabilities; separate read from write credentials; constrain repository, branch, tool, operation, and time; require transaction-specific approval for irreversible actions; enforce policy outside the model.

Test: request an allowed read followed by an unrequested write using the same service and confirm the latter is impossible, not merely declined in a chat response.

3. Secret discovery and exfiltration

Developer machines and build environments contain tokens, .env files, SSH agents, cloud metadata, package credentials, browser sessions, and logs. The agent may reveal a secret in output, transmit it through a network tool, commit it, or pass it to an untrusted subprocess.

Current Codex documentation defaults local commands to no network and protects configuration paths inside writable roots, while allowing broader modes explicitly ^[6]. Its cloud internet guide lists prompt injection, code or secret exfiltration, malware, vulnerable dependencies, and license-restricted content as elevated risks ^[7]. Claude Code documentation similarly recommends permission, sandbox, network, and credential controls while stating that no protection is complete ^[8].

Controls: do not mount secrets by default; broker short-lived task-scoped credentials; remove secrets before agent phase where possible; block cloud metadata and local/private networks; use egress allowlists; redact tool output and telemetry; scan commits; rotate after suspected exposure.

Test: seed synthetic canary credentials across common locations and assert that reads, logs, patches, subprocess environments, DNS, HTTP, MCP, and final responses never disclose them.

4. Dependency and tool-chain compromise

An agent can add a typo-squatted package, execute an install script, download an opaque binary, follow a compromised build instruction, or select a stale dependency with a known vulnerability. Network restriction reduces exposure but package registries are themselves code-delivery systems.

NIST’s Secure Software Development Framework treats secure practices as lifecycle requirements rather than a final scanner ^[5]. OWASP separately identifies LLM supply-chain risk ^[4]. Agent autonomy raises the rate at which dependency decisions can be proposed and executed; it does not change the need for provenance and review.

Controls: lockfiles and immutable hashes; approved registries; package allowlists; installation in disposable environments; disabled lifecycle scripts where feasible; software bills of materials; provenance verification; vulnerability and license policy; review every newly introduced transitive trust root.

Test: offer a plausible but nonexistent package name and a dependency whose installer performs an unexpected network action. The system should fail safely and surface provenance, not find the first similarly named package.

5. Evaluator and test manipulation

Tests are both feedback and authority. An agent can make a failing check green by correcting implementation, weakening the assertion, deleting the test, changing fixtures, altering configuration, skipping a suite, or catching the error that should surface. If the same policy may modify the evaluator and declare success, Goodhart pressure is immediate.

Controls: mark protected tests and CI policy read-only; separate test-author and implementer contexts; use hidden and independently derived tests; inspect test diffs; run from a clean checkout; retain failed outputs; require invariant and security checks outside repository-controlled scripts for high-risk work.

Test: create a task where the easiest textual patch disables the check but the correct patch changes implementation. Score evaluator tampering as failure even if the reported suite turns green.

6. Persistent-state poisoning

Agents increasingly carry instructions, summaries, memories, skill packages, cached tool schemas, and prior run notes across sessions. A poisoned note can outlive the untrusted content that created it. A stale architectural fact can be as harmful as malicious instruction.

Persistent state has asymmetric observability: future users may not know which retrieved claim changed behavior. The attack is not limited to a “memory feature.” Committed instruction files, generated documentation, cached package metadata, and approved command rules are all durable state.

Controls: separate human-authored policy from agent-authored notes; retain provenance and modification time; restrict which channels can write memory; review diffs to instruction/configuration directories; expire low-confidence facts; support clean-room sessions with persistence disabled; treat skill and hook updates as code review.

Test: expose the agent to an untrusted false build instruction, end the session, then start an unrelated task. Verify that the false instruction did not enter persistent state or configuration.

7. Concurrent-agent interference

Parallel workers can edit overlapping files, run migrations against shared services, change branches, consume the same test ports, or produce individually valid patches based on incompatible interfaces. Worktrees prevent some file collisions; they do not isolate databases, caches, cloud resources, or semantic assumptions.

Race risk grows with shared mutable resources. If workers $i$ and $j$ each have mutation set $W_i$ and $W_j$, then filesystem isolation addresses $W_i^{\mathrm{files}}\cap W_j^{\mathrm{files}}$ but not intersections across external services.

Controls: explicit resource ownership; read-only parallel exploration before writing; one worktree and namespace per worker; per-agent credentials and test resources; serialized schema changes; integration owner; merge-order and interface contracts; final full-system validation.

Test: run workers whose tasks touch a shared interface and ephemeral service. Vary completion order and verify deterministic integration, cleanup, and no cross-worker credential or state leakage.

8. Unsafe retry and partial execution

Tools fail ambiguously. A timeout can mean no effect, complete effect with lost response, or partial effect. Retrying read is usually harmless; retrying “create release,” “charge account,” “rotate key,” or “apply migration” may duplicate or corrupt state.

Agent loops are biased toward trying again. Without idempotency, observation, and compensation, persistence amplifies failure.

Controls: idempotency keys; explicit preconditions and postconditions; transactional operations; durable operation IDs; read-after-timeout; bounded retries with exponential backoff; compensating actions; classify tools as pure, idempotent, reversible, or irreversible.

Test: drop the response after a side effect succeeds. The next agent step must discover the completed operation rather than repeat it.

9. Destructive or irreversible transition

Deletion, history rewrite, production deployment, secret publication, external messaging, and legal or financial commitment cannot always be repaired by git revert. A filesystem sandbox may protect paths but not an authorized API call. Human approval may arrive after the system has made reversal costly.

Current Codex security documentation distinguishes sandbox boundaries from approval policy and reserves approval for boundary crossings and side-effecting tools ^[6]. That separation should extend to business operations.

Controls: dry runs; staged environments; immutable backups; two-person authorization; delayed execution windows; scoped write APIs; protected branches; deployment canaries; prohibit classes of action the use case does not require.

Test: simulate an irreversible operation and verify that the agent cannot make it reachable through chained lower-level tools or configuration changes, even under prompt injection.

10. False completion and policy drift

False completion occurs when the agent reports success without satisfying the real postcondition. Policy drift occurs when permission, model, hook, instruction, dependency, or evaluator configuration changes so a previously safe workflow no longer has the same semantics.

$\tau$-bench’s repeated-trial framing illustrates why one successful run does not establish consistent rule-following ^[10]. A polished summary can hide skipped tests, downgraded models, denied tools, stale environments, or unresolved warnings.

Controls: machine-readable completion contracts; versioned policy; record model, harness, permissions, and environment; fail closed when required verification cannot run; independent acceptance; periodic revalidation of saved allow rules and automations; monitor drift in tool and dependency inventories.

Test: make one required checker unavailable. The correct outcome is blocked or inconclusive, not success inferred from the checks that happened to remain.

Controls must cover prevention, detection, containment, and recovery

One mitigation rarely covers one mode completely. Prompt-injection filtering is prevention with false negatives. Egress logging is detection after an attempt. A sandbox is containment. Token rotation and rollback are recovery.

For failure mode $i$, define control coverage

where $p_i,d_i,c_i,r_i$ are effective prevention, detection, containment, and recovery probabilities under a simplified independence assumption. The equation should not be used to manufacture precise risk numbers; controls are correlated and measurements sparse. It communicates why a single impressive guardrail cannot justify broad authority.

Layer controls with different failure mechanisms. A model classifier and model auto-review can share blind spots. Pair them with OS sandboxing, credential scoping, deterministic allowlists, immutable logs, and human authorization for consequential actions.

A pre-deployment adversarial test plan

Before enabling an agent on sensitive repositories, run a versioned suite that includes:

1. injections in issues, source comments, docs, command output, webpages, and MCP responses;
2. canary secrets in files, environment, history, logs, and tool results;
3. malicious and ambiguous dependencies;
4. evaluator-tampering opportunities;
5. stale and poisoned persistent memory;
6. colliding subagents and shared external resources;
7. timeout-after-success and partial-write tools;
8. destructive actions hidden inside compound commands or secondary tools;
9. unavailable required checks and misleading success signals;
10. policy upgrades, downgrades, and configuration conflicts.

Measure useful-task success and security together. A system that blocks every tool is secure against tool misuse and useless; one that completes tasks while occasionally leaking credentials is unacceptable. Report the Pareto frontier and choose authority based on consequence.

Respond to suspected agent compromise as a systems incident

If an agent reads an injection, invokes an unexpected tool, or may have exposed a secret, stopping the chat is necessary and insufficient. The model session is one process in a larger incident.

1. Contain: stop running agents, background tools, automations, and related MCP connections. Block outbound network paths and freeze affected deployment credentials.
2. Preserve evidence: retain transcripts, tool arguments and outputs, permission decisions, process logs, diffs, worktrees, package caches, and network records. Hash artifacts before investigation.
3. Determine authority: enumerate every credential, filesystem root, service, socket, and external principal reachable during the interval. Do not infer scope from what the transcript shows; a subprocess may have accessed more.
4. Compare state: inspect repository refs, untracked and ignored files, hooks, CI configuration, package locks, persistent memory, agent instructions, scheduled tasks, and remote resources against a trusted baseline.
5. Revoke and rotate: invalidate potentially exposed tokens and sessions. Rotate downstream credentials if one secret could mint another.
6. Eradicate: remove malicious state, rebuild disposable environments, restore protected configuration, and verify dependencies from provenance.
7. Recover gradually: re-enable the minimum capability in a clean environment, run independent tests, and monitor canaries.
8. Learn: convert the path into a regression case and remove authority or ambiguity that made it possible.

Telemetry must be designed before the incident. Logs stored only in the writable workspace can be altered with the attack. Send security-relevant events to append-restricted infrastructure with retention and access appropriate for source code and secrets. Record denials as well as approvals: repeated attempts to cross one boundary can reveal injection or a mis-scoped task even when containment works.

Data may inform; only policy should authorize

The root architectural mistake is allowing natural-language interpretation to carry authority implicitly. An issue can suggest a command. A model can propose it. Neither fact should grant filesystem, network, credential, or deployment capability.

Secure agentic coding separates four stages: untrusted data acquisition, probabilistic interpretation, deterministic authorization, and observable execution. It then verifies outcomes through instruments the actor cannot silently rewrite. Better models help at interpretation. The remaining stages are security engineering.