The control that breaks is the assumption that review content is passive. Once the agent can interpret attacker-writable text and use the reviewer’s credentials, a single hidden instruction can redirect legitimate tool use into cross-project data theft. The failure is not just prompt injection, it is delegated authority being applied to untrusted instructions.
How delegated authority fails when the text itself is untrusted
The core problem is that the agent is no longer just reading review content, it is evaluating instructions embedded in content it does not control. That turns a passive review surface into an execution surface, because the agent can be steered by attacker-writable text while still appearing to act as a legitimate reviewer.
In practice, the dangerous boundary is not “human wrote it” versus “machine wrote it”, it is “trusted policy input” versus “untrusted content input”. Once those are blurred, the model can be induced to treat a PR comment, diff, or description as if it were an operational directive.
An agent that can act on behalf of a reviewer also inherits the reviewer’s authority boundary. If that authority includes repository actions, ticketing, deployment checks, or data access, the attacker does not need to break the system directly, they only need to redirect the reviewer’s tool use through malicious text.
Why prompt injection becomes a cross-project data exposure issue
The immediate risk is not simply that the agent follows a bad instruction, it is that it can do so with valid credentials and normal tooling. That creates a delegated-deputy problem: the action is authenticated, but the intent is attacker-shaped.
Cross-project theft becomes possible when the agent has broad read paths, shared workspace context, or reusable tokens that are not scoped tightly enough to the task. A hidden instruction can cause the agent to browse, copy, summarise, or exfiltrate data from places the reviewer would never intentionally inspect.
That is why the failure mode is better described as authority misuse than content injection alone. The text is the lure, but the real break is that the agent can convert untrusted instructions into legitimate downstream access.
For a practical reference on this control boundary, AI Agent Authorisation Guide focuses on task-scoped and just-in-time access, which is exactly the kind of constraint that limits what a compromised review flow can do.
What good containment looks like before the agent can act
A safe design separates reading from acting. The agent can inspect PR text, but it should not be able to translate every instruction it sees into tool calls, approvals, secrets access, or repository-wide reads without a second policy check.
Useful containment usually includes narrower tool grants, per-action approval for sensitive steps, and a hard split between the content the agent is analysing and the commands it is allowed to execute. Where the agent can trigger cross-repo or cross-environment access, that should be treated as a privileged action, not a normal review convenience.
Teams should also assume that review surfaces may carry adversarial instructions even when the PR originates from an apparently legitimate contributor. The right control is not “read less”, it is “decide less automatically”.
One useful pattern is to compare the agent’s authority to the reviewer’s intended task. If the action would be surprising in a manual review, it should not be silently available to the agent just because the content asked for it.
Risk and Threat Considerations
This failure mode creates both control loss and data exposure. The attacker is using trusted review pathways to turn a normal assistant into an execution channel, so the blast radius depends on how much authority the agent inherits from the reviewer or connected workspace.
Failure mechanism: The agent treats attacker-controlled PR text as actionable guidance, then uses delegated credentials or sessions to perform reads, writes, or queries outside the reviewer’s intended scope.
Impact: Legitimate tool use can be redirected into cross-project data theft, unauthorized changes, or broader compromise of review, build, or collaboration systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question centers on attacker text steering an agent's authority. |
| ASI02 — Tool Misuse | The agent is tricked into using legitimate tools for attacker-directed actions. | |
| Recommendation — Constrain agent authority so untrusted content cannot expand identity or privilege use. Restrict tool invocation paths and require policy checks before sensitive actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Human-authored review content is used to steer a non-human actor's actions. |
| Recommendation — Separate human review content from machine-executable instructions and approvals. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits what delegated reviewer credentials can do after injection. |
| IA-5 — Authenticator Management | Credential and token handling matter when attacker text can trigger privileged use. | |
| Recommendation — Limit agent credentials and sessions to the minimum access needed for the task. Rotate and scope credentials so a compromised review flow cannot reuse broad access. | ||
Practitioner Guidance
What to verify: Confirm that the agent cannot turn untrusted text into privileged action without an explicit policy decision. Test the path where a PR contains instructions that ask for secrets, cross-repo context, or repository actions, and verify the agent stops or asks for approval.
Decision rule: If the agent can access anything beyond the current task’s minimum scope, treat that access as sensitive and require scoped credentials, explicit approval gates, or a constrained execution environment. If the review content itself can influence action selection, the system is not yet safe enough for unattended execution.
Practitioner takeaway: The key question is not whether the agent can understand attacker text, it is whether understanding that text changes what it is allowed to do. If yes, you have a delegated-authority problem and must tighten action scope before you trust the review workflow.
Related resources from NHI Mgmt Group
- What breaks when an AI agent can auto-connect to attacker-controlled endpoints from a crafted link?
- What breaks when an AI agent has root-level database access and reads untrusted text?
- What breaks when AI email summaries can be shaped by attacker-controlled text?
- What breaks when an AI SOC agent can read attacker-written text as part of its normal workflow?