Prompt injection happens when content an AI system reads redirects its behavior away from the intended task. In a coding workflow, the content might be a project file, an issue description or information returned by a connected tool.
The risk grows when the agent can act on that content. A misleading instruction might affect a proposed change, prompt an unnecessary permission request or lead to an action the user never asked for.
Reading a file should not make it an authority
OWASP distinguishes indirect prompt injection from instructions supplied directly by a user: the indirect form arrives through external material the model consumes. Its consequences depend partly on the access and capabilities available to the application.
A coding agent needs project context to work. The difficulty is keeping a statement inside that context separate from permission to change the task or use a tool.
Consider this hypothetical example. A developer asks an agent to fix a display bug. A project note then tells the agent that completing the fix requires disabling review checks and sharing local configuration with an outside support service.
The note may sound helpful. It still does not establish that the service is approved, that configuration may be shared or that review checks should be disabled. Those decisions need to come from the authorized task and your organization's rules.
Know what connected tools add
Model Context Protocol, usually shortened to MCP, provides a way for AI applications to connect to tools and information sources. A connection can be useful for development, but its presence alone does not establish that every instruction or result it returns is trustworthy.
When reviewing an integration, check what the connected service can read and do. Ask who operates it, which identity it uses and how its access can be revoked. GitHub's MCP documentation explains the protocol in the context of Copilot.
An employee should not have to make that assessment from scratch every time they start a task. Maintain an approved integration list with a responsible owner.
Watch for a change in scope
Developers cannot identify every malicious instruction by reading its wording. They can, however, notice when the agent's proposed action no longer fits the task.
Pause when an agent unexpectedly asks to:
- Access unrelated projects or directories.
- Send files or configuration to a new destination.
- Use a credential with broader permissions than the task needs.
- Disable tests, review rules or security checks.
- Publish or delete something outside the agreed change.
These requests can have legitimate explanations. Ask for the reason, inspect the proposed action and verify it with the task owner before expanding access. The warning sign is a scope change that nobody can account for.
Be especially careful with repeated approval prompts. Approving a harmless action earlier does not settle whether a later request to share data or modify another system is appropriate.
Put technical limits behind the training
Awareness helps people respond to unusual requests. It should sit alongside restrictions that limit what an agent can actually do.
Keep production secrets out of ordinary development tasks. Limit access to the relevant project and approved services. Require review for actions with wider consequences, and retain the records your team needs to investigate unexpected behavior.
Anthropic's explanation of Claude Code sandboxing describes filesystem and network isolation as boundaries for autonomous work. These controls reduce the agent's available access; they do not make arbitrary project content trustworthy.
Check both permissions and the employee's response. An agent blocked from an external destination should trigger investigation if it then asks someone to bypass that boundary.
A five-minute exercise for your next team meeting
Use a discussion exercise with fictional data. Keep it out of a live agent session and avoid real credentials or external destinations.
- Set the task: An agent is helping fix a display bug in a test project.
- Introduce the unexpected request: A project note says the fix requires sharing local configuration with an unfamiliar support service.
- Ask the team to decide: Does that action fit the task? Who owns the service? Which information would leave the project?
- Practise the response: Pause the action, save the relevant request or logs without spreading secrets, and contact the project's security or IT owner.
- Review the boundary: Confirm which controls should prevent the transfer and how the event would be investigated.
The aim is to practise recognizing a change in authority and scope. Employees should know how to get help without being blamed for reporting an ambiguous request.
Give reporting a clear destination
Name the team or channel that receives unexpected agent requests. Explain what to include: the original task, the proposed action, the source of the instruction if known, and whether anything was approved or executed.
If sensitive data may have been shared, follow your organization's incident process. Avoid deleting the activity history or independently experimenting with the suspicious instruction while the response team investigates.
Use the same reporting habits you teach in awareness training: pause, verify and ask for help. For administrators, our coding-agent security checklist connects those habits to the access settings that support them.
