An instruction and a data field can both mislead
Indirect prompt injection enters through material an agent reads, such as a page, issue or tool response. An instruction attack asks it to change its goal. In a data injection, a field instead appears to establish an author, resource identifier, origin or action result. The agent can continue the authorised task while using a wrong target.
Transport does not determine trust. A signed-in GitHub connector can return a public issue comment; the connector identity may be verified while the comment is still third-party content. A model-generated summary inherits the provenance of what it summarised.
Draw a field-level trust map before writing prompts
The policy component, not the model reading the same untrusted context, must decide which fields may authorise an action.
- Authorised instruction
- The authenticated user goal and system policy. These do not automatically grant every operational permission.
- Verified control data
- Target, repository, commit, identity and authorisation checked by Git, an API or another deterministic component.
- Untrusted external content
- Pages, documents, comments, issues, filenames and tool-returned user text.
- Derived content
- Summaries or parameters generated from other data; keep source and trust labels attached.
Separate reading from consequential actions
- Start with read-only tools and the minimum repository, filesystem and network access.
- Keep credentials out of prompts and tool output; use short-lived scoped credentials at the execution layer.
- Resolve the action target again from verified data immediately before execution.
- Show target, parameters and consequences in an approval step independent of the model summary.
- Invalidate approval when state or target changes; record redacted provenance and action logs.
- Review the real diff and tests before installation, merge, publication or deployment.
Test the boundary without an attack payload
Create a synthetic issue whose prose names a different author or branch from the verified API fields. The system passes if it preserves both sources, uses verified fields for its decision, and blocks a write until the exact target is approved. Repeat this test after changing tools, schemas or policy.
The cited research describes a class of failures; it does not establish a ranking of products or guarantee that a given defence closes every path.