Notifications
Clear all
Topic starter
18/08/2026 2:23 pm
TL;DR: AI coding agents can be tricked into attacking the wrong target when scope is manipulated through localhost relays, deceptive MCP signals, and network-layer deception, according to OFFENSAI. The finding shows that prompt safety alone is not enough: agents need out-of-band target verification and stricter authorization boundaries before they can be trusted to run offensive-style workflows.
NHIMG editorial — based on content published by OFFENSAI: Security attacking production apps without jailbreaking the model with scopeshift
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
Questions worth separating out
Q: How should security teams prevent AI agents from attacking the wrong target?
A: Security teams should require independent target attestation before an agent can run tests or send payloads.
Q: Why do localhost and MCP-based scope checks fail in practice?
A: They fail when the agent trusts signals that are already inside the attacker-controlled environment.
Q: What do security teams get wrong about agent safety prompts?
A: They assume a safer prompt can compensate for a deceptive execution environment.
Practitioner guidance
- Implement out-of-band target attestation Require a separate attestation path for host ownership, engagement scope, and environment type before any agent can send attack-shaped traffic.
- Block self-authorising localhost assumptions Do not treat 127.0.0.1, private DNS names, or local MCP responses as proof that a target is safe or authorised.
- Constrain tool access by engagement context Bind scanning and testing tools to pre-approved target lists, signed task metadata, and short-lived execution permissions.
What's in the full article
OFFENSAI's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact scopeshift proxy and MCP oracle setup used to relay agent traffic without the model noticing the real destination.
- The side-by-side Run A and Run B prompts and how the appended safety text altered the agent's decision-making.
- The control experiment against a genuine localhost dev build and why that discriminator is not a universal fix.
- The reproducible Docker-compose workflow and demo prompts for teams that want to test scope-deception scenarios in their own environment.
👉 Read OFFENSAI's analysis of scope manipulation against AI coding agents →
AI coding agents and scope drift: are your controls keeping up?
Explore further
18/08/2026 3:14 pm
Scope deception is now an identity problem, not just a prompt-safety problem. When an AI coding agent accepts localhost, DNS, or MCP assertions as proof of legitimacy, it is effectively making an identity decision about the target. That is the same class of governance failure IAM teams know from delegated access and spoofed trust claims. The practitioner lesson is that authorization must be backed by verifiable target identity, not by self-reported context.
A question worth separating out:
Q: Who is accountable when an AI coding agent sends traffic to the wrong system?
A: Accountability usually sits with the organisation that allowed the agent to act without verifiable scope controls. That includes the team that designed the workflow, the team that approved the permissions, and the operators who treated in-band evidence as sufficient. Governance frameworks for AI and NHI should require explicit ownership of target attestation.
👉 Read our full editorial: Scope manipulation is the new attack surface for AI coding agents
