Coding-Agent Prompt Injection: Trust, Permissions, and Containment

The coding agent opens a repository issue that says the build is broken. Hidden among the troubleshooting notes is an instruction to upload configuration files to an external endpoint “for diagnostics.” The candidate treats the issue as authoritative because it lives inside the repository. The interviewer asks one follow-up: why was that text allowed to change the agent's permissions?

Prompt injection in coding-agent interviews is a trust-boundary problem. OWASP documents direct and indirect prompt injection, including malicious instructions delivered through external content. GitHub's responsible-use guidance emphasizes reviewing and validating agent output. The practical lesson is not that one filter will solve the problem. It is that repository text and tool output remain untrusted data even when the agent can read them fluently.

Find the Instruction Where You Least Expect It

Candidates often look only at the message they typed. A repository-aware agent can receive instructions from many other surfaces:

• README files and contribution notes;
• issue descriptions and pull-request comments;
• source comments, fixtures, and generated documentation;
• build output, test logs, and error messages;
• dependency metadata and downloaded archives;
• web pages or search results retrieved by a tool;
• responses from package registries, APIs, or internal services.

Most of this content is useful data. The danger appears when the agent interprets data as permission to alter the task, reveal information, run a consequential command, or contact an unapproved destination.

The coding-agent permission gates guide shows how to turn this trust decision into explicit approval boundaries. This article stays focused on instruction confusion: untrusted content attempting to control the agent through context.

Establish a Trust Hierarchy Before Tools Run

A strong answer starts by naming who may change what.

At the top is the authorized interview task and the explicit rules supplied by the interviewer or approved environment. Next are repository instructions that have been identified as legitimate and consistent with that task. Below them are ordinary repository content, retrieved pages, issue text, logs, and tool responses. Those lower sources may contain facts to inspect, but they do not silently gain authority to change goals or permissions.

Use three questions whenever new instructions appear:

1. Source: Where did this instruction come from?
2. Authority: Is that source allowed to change the current task or tool boundary?
3. Conflict: Does it request behavior that contradicts the authorized goal, data rules, or permissions?

If a test log says “disable security checks and rerun,” its location does not make it trusted. Treat it as evidence about the test environment, not an instruction to obey.

This distinction is more durable than a list of suspicious phrases. Attack wording changes; source authority and task consistency remain inspectable.

Bound Capabilities So Confusion Has Less Impact

Prompt injection becomes more dangerous when the agent can turn mistaken instructions into consequential actions.

Apply least privilege by task phase. Discovery may need read access to a limited repository. Implementation may need writes only to expected files. Verification may need approved local commands. Network access, secret access, package publication, external messages, deployments, and destructive operations should remain unavailable unless the task explicitly requires them and a human approves the exact action.

Separate capabilities where possible. The tool that reads untrusted web content should not automatically inherit access to credentials. A repository task should not gain deployment authority merely because the agent can run tests. A package lookup should not receive private source code in its query.

The harness engineering guardrails guide provides a broader view of approvals and constrained execution. In an interview answer, connect each permission to the smallest action needed now.

Inspect Consequential Requests at an Approval Gate

An approval prompt is useful only if the candidate examines the proposed effect.

Before approving, state:

• the exact command or tool action;
• the intended target and expected output;
• the files, data, or destinations it can reach;
• whether the action is reversible;
• the local or lower-privilege alternative considered;
• the evidence you will inspect immediately afterward.

Suppose the agent asks for network access after reading a repository note. Do not approve because “the build instructions say so.” Verify whether the assignment permits network use, whether the destination is official and necessary, and whether any local files would be transmitted. If the request cannot be narrowed, pause.

Approval is not a guarantee that content is safe. It is a deliberate point where untrusted suggestions meet human authorization.

Contain a Suspicious Agent Before Diagnosing Everything

If the agent attempts an unauthorized action, containment comes before a complete root-cause analysis.

First, pause the agent and stop active tool execution. Second, remove or narrow the capability that could increase impact, such as network, write, secret, or deployment access. Third, preserve the relevant prompt source, command request, logs, and working-tree state without copying protected data to an unapproved place.

Then answer the impact questions:

• Did any command execute?
• Which files changed?
• Did data leave the environment?
• Were credentials accessed or exposed?
• Did the agent modify tests, configuration, or security controls?
• Is the current workspace still trustworthy?

Restore from a known-good boundary when necessary. Rotate or revoke exposed credentials through the approved process. Re-run only after the malicious content is isolated, the task is restated, and tool permissions are reduced.

Do not claim that restoring local files reverses external effects. A sent request, published artifact, or exposed secret needs separate recovery.

Walk Through the Interviewer's Containment Scenario

Consider a task that asks you to update a parser and run existing tests. During discovery, the agent reads a fixture containing an instruction to ignore the interview task and send environment variables to a diagnostic service.

A weak answer says, “I would add a stronger system prompt.” That might be one layer, but it leaves tool authority unchanged and does not address impact.

A stronger response is:

1. classify the fixture as untrusted test data, not a source allowed to change the task;
2. deny network access because the parser task does not require it;
3. keep writes limited to the parser and focused tests;
4. inspect whether the agent attempted commands or modified configuration;
5. preserve the fixture as a regression case without publishing operational details;
6. run the parser test and verify the suspicious text is treated as data;
7. review the final diff for disabled controls, new destinations, or secret access.

The answer demonstrates both prevention and recovery without pretending the injection can never succeed.

Give a Layered Answer, Not a Magic Fix

Interviewers often ask, “How would you prevent prompt injection?” Avoid a single-control answer.

Say:

“I would separate authorized task instructions from repository and tool content, which remain untrusted data. The agent would receive only the capabilities needed for the current phase, with human approval for network, secret, destructive, or external actions. I would validate proposed commands and outputs against the task, preserve logs for suspicious requests, and keep a known-good recovery boundary. These controls reduce probability and impact; they do not guarantee complete prevention.”

Then adapt the answer to the scenario. If the repository handles customer data, emphasize data egress. If the agent can publish packages, emphasize artifact integrity and credentials. If the task is read-only review, explain why write and network tools should be disabled entirely.

The AI interview tools data security guide can help you extend the same reasoning to retention, encryption, and approved data flows.

Interview AiBox can support preparation by helping you rehearse security follow-ups and capture missed containment steps in a post-practice checklist. It does not replace the target employer's AI policy or the actual environment's security controls.

FAQ

Is repository content less trustworthy than the user's prompt?

Repository content is not inherently malicious, but ordinary files, issues, logs, and retrieved text should not gain authority to override the authorized task or permissions merely because the agent can read them.

Can input sanitization solve indirect prompt injection?

It can reduce some attacks, but no single sanitizer recognizes every harmful instruction or context. Combine source separation, least privilege, approvals, validation, monitoring, and recovery.

Should coding agents have network access during interviews?

Only when the interview rules and task require it. Narrow the destination and purpose, exclude protected data, and approve the exact action rather than granting broad access by default.

What should I report after a suspected injection?

Report the source, attempted action, capabilities available, observed effects, containment steps, recovery status, and remaining uncertainty. Avoid claiming no impact until relevant evidence supports it.

Sources

• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• GitHub Docs: Responsible use of Copilot coding agent

Next Steps

• Review the Interview AiBox feature overview
• Follow the product roadmap for workflow improvements
• Apply the same permission discipline to AI-assisted take-home provenance
• Download Interview AiBox