Why is indirect prompt injection harder to defend than XSS?

Why This Matters for Security Teams

indirect prompt injection is harder to defend than XSS because the attacker is not just trying to break rendering logic, they are trying to steer a decision-making system that can read, summarise, call tools, and act. XSS is usually contained by deterministic browser defenses such as output encoding and sanitisation. Agentic AI systems do not offer that same predictability, which is why current guidance in the OWASP Agentic AI Top 10 treats prompt-injection risk as a system design issue, not a text-filtering issue. The model may follow untrusted instructions only under certain context, tool availability, or prompt ordering, so the boundary has to be enforced around the agent’s authority and inputs, not just at the content layer. That makes governance closer to NHI control than classic web input handling. NHI Mgmt Group research shows 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a useful reminder that machine identities and their secrets are where attackers often turn influence into action; see the OWASP Agentic Applications Top 10 and CISA cyber threat advisories for the broader threat context. In practice, many security teams encounter indirect prompt injection only after an agent has already acted on contaminated context rather than through intentional testing.

How It Works in Practice

The practical difference is that XSS is executed code with known sinks, while indirect prompt injection is influence over an autonomous workflow. An attacker can hide instructions inside a document, ticket, email, web page, or data source that the agent later ingests. If the agent has tool access, those instructions can become a prompt to search, exfiltrate, create, modify, or approve. That is why static RBAC alone is not enough for agentic systems: roles describe what a workload should do in general, but they do not reliably constrain what an agent decides to do at runtime when context changes. Best practice is evolving toward intent-based authorisation, real-time policy evaluation, and short-lived credentials. The OWASP Agentic Applications Top 10 is a useful NHI-focused reference for this shift, and the OWASP Agentic AI Top 10 highlights why tool misuse and instruction hijacking are core risks. A practical control stack usually includes:

• JIT credential provisioning so an agent receives only the secrets needed for one task.
• Ephemeral secrets with tight TTLs and automatic revocation on completion.
• Workload identity, such as SPIFFE or OIDC-based proof of what the agent is, not just what it knows.
• Policy-as-code checks at request time, with full context about the task, data source, and target action.
• Tool scoping that separates read, write, and approval paths.

NIST’s CISA cyber threat advisories reinforce the broader operational point: when compromise is possible through untrusted inputs, defenders need layered controls, not a single text filter. These controls tend to break down when agents have broad, persistent access to internal SaaS, because long-lived tokens and shared service accounts make every prompt a potential privilege escalation path.

Common Variations and Edge Cases

Tighter agent controls often increase orchestration overhead, requiring organisations to balance safety against latency, usability, and operational complexity. That tradeoff is especially visible in multi-agent pipelines, where one agent summarises content, another decides, and a third executes. Current guidance suggests that each hop should be treated as a new trust boundary, because contaminated instructions can survive translation from source text to structured task to tool call. There is no universal standard for this yet, but the direction of travel in both the OWASP Agentic AI Top 10 and NHI-focused guidance is to reduce standing privilege and force fresh authorisation at each sensitive step. Edge cases matter. A retrieval-augmented chatbot with read-only access is less risky than an autonomous agent that can file tickets, send emails, or rotate secrets. Similarly, a model that only classifies text is not the same as one that can trigger CI/CD, invoke cloud APIs, or approve payments. In those environments, intent-based authorisation and ZSP are more important than content scanning, because the harm comes from action, not just exposure. Zero Trust Architecture and AI governance guidance align here: assume the input may be hostile, scope the agent narrowly, and revoke access as soon as the task ends. Where organisations still rely on long-lived API keys or broad service-account privileges, indirect prompt injection becomes much harder to contain because the model can turn a single compromised instruction into repeated downstream actions.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• How should security teams reduce indirect prompt injection risk in AI systems?
• When does indirect prompt injection become a business risk rather than a technical curiosity?
• Indirect Prompt Injection