Handle prompt injection in a coding agent: untrusted text cannot grant authority

A worked example: where the task becomes difficult

A fictional agent reads an issue comment containing instructions to upload environment files to a “debugging endpoint.” The comment is task material, not permission from the project owner. The agent still needs the real bug description, so it should extract relevant facts while ignoring the attempted authority change. Removing all external context would make the tool less useful without establishing a sound boundary.

Decisions to make before implementation

Define which sources can set instructions and which are untrusted task data. Separate planning from tool execution and use explicit permissions for remote writes, messages and sensitive uploads. Validate paths, destinations and active project identity before applying edits. Keep secrets outside unnecessary context and use deterministic checks where a model’s interpretation alone would create a high-impact action.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Classify instruction sources and tool-result content in the workflow.
• Restrict tool authority to the intended project and operation.
• Detect requests that conflict with trusted scope or seek sensitive transmission.
• Test hostile fixtures and preserve legitimate task progress without obeying injected commands.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Review the agent workflow for untrusted repository and tool text. Identify trusted instruction sources and consequential tool boundaries. Use hostile fixtures that request secret upload or cross-project edits. Preserve legitimate debugging facts while rejecting authority changes. Report deterministic checks and remaining limitations; do not claim complete protection from a single successful refusal.

Failure modes that an attractive preview can hide

A keyword blacklist cannot capture every adversarial instruction and may block innocent documentation. Use authority and action boundaries, not only suspicious phrasing. A model refusing one hostile example does not certify the whole system. Review actual tool calls and destination checks, and avoid logging secrets while demonstrating the attack.

Technical references: MDN: practical security implementation guides

Acceptance checks and the evidence to retain

Keep the authority model, tool constraints, tested hostile fixtures and observed action decisions. Treat injection resilience as an ongoing engineering property rather than a universal guarantee.

Specific answers

Common questions