Prompt Injection Risk Assessment: Can Your AI System Be Hijacked by Its Own Input?
This free prompt injection risk assessment scores your AI agents and RAG systems across eight dimensions that determine whether untrusted input can hijack the model's behavior, and it is built for AI engineers and security architects deploying agentic or tool-calling systems. Prompt injection is the OWASP LLM Top 10's most consequential category precisely because it does not require compromising your infrastructure, only crafting text the model will read. Answer eight questions covering content ingestion, action authority, output validation, and human oversight, and get a scored risk band with prioritized architectural fixes.
1. Does your AI system ingest content from untrusted sources into its context, such as web pages, email, or uploaded documents?
Untrusted content is the primary delivery mechanism for indirect prompt injection: instructions hidden inside a document the model reads, not typed by the user.
2. Can the model take real-world actions, such as sending email, modifying records, or calling APIs, based on its own output?
3. Do you sanitize or quarantine instructions found inside retrieved documents before they reach the model?
4. Is there a hard privilege boundary between what the model can read and what it can act on?
5. Have you red-teamed your system with adversarial prompt injection payloads?
6. Do you use output filtering or a second model to validate high-risk actions before execution?
7. Could a user's effective permissions be escalated through crafted input, including indirect injection via a retrieved document?
8. Is there human-in-the-loop approval for consequential actions such as financial transactions, data deletion, or external communication?
Why prompt injection is different from every prior injection class
SQL injection and XSS have known syntax to filter for. Prompt injection has none, because natural language is the attack surface and the model's own reasoning is the thing being manipulated. Indirect injection is the more dangerous variant: an attacker never touches your input field at all, they plant an instruction inside a web page, a resume, a support ticket, or an email attachment, knowing your system will eventually retrieve and feed that content to the model. The model cannot reliably distinguish its system instructions from instructions embedded in the data it is reading, because both arrive as the same kind of text in the same context window.
- Direct injection comes from the user's own input; indirect injection arrives through retrieved or ingested content.
- No syntactic filter reliably catches injection, because the attack is meaning, not a fixed pattern.
- Agentic systems with tool access turn a successful injection into a real-world action, not just a bad chat reply.
- The same weaknesses that make models good instruction-followers make them susceptible to unauthorized instructions.
The eight risks this assessment measures
Each question targets a specific link in the attack chain: whether untrusted content reaches the model at all, whether the model can act on its own output, whether retrieved content is structurally separated from instructions, whether a privilege boundary exists independent of the model's stated intent, whether you have tested for these failure modes, whether a second layer validates risky actions, whether permissions can be escalated through crafted input, and whether a human approves consequential actions. Close enough of these and a successful injection stops being able to cause real damage even when it succeeds at fooling the model.
How to read your score
The two questions that matter most are whether the model can act on untrusted content and whether a privilege boundary exists independent of the model's own reasoning. A system that only produces text for human review, however poorly it filters input, cannot cause direct harm from injection. A system that can send emails or modify records based on its own output, without independent validation, is one crafted document away from an incident regardless of how good its prompts look in a demo. Prioritize architectural separation over prompt-level defenses, because prompt-level instructions telling the model to ignore embedded commands are advisory, not enforced.
How Netray hardens agentic AI systems
Netray builds agentic and RAG systems for manufacturers where a hijacked AI assistant could touch ERP transactions, supplier communications, or export-controlled documentation. We architect a hard boundary between what a system reads and what it can act on, add independent validation for consequential actions, and red-team every agent against current injection techniques before it reaches production. For customers running SyteLine, LN, or M3 integrations, we scope agent actions to the minimum required and route anything consequential through human approval, so a successful injection has nowhere useful to go.
Frequently Asked Questions
Can I just tell the model in the system prompt to ignore instructions found in retrieved content?
That instruction helps but does not reliably work, because the model processes system instructions and retrieved content through the same underlying mechanism and a sufficiently crafted payload can still override it. Treat prompt-level instructions as one weak layer among several, never as your primary defense. The defense that actually holds is architectural: enforce action permissions outside the model's control, independent of what it claims its intent is.
What is the difference between direct and indirect prompt injection?
Direct injection comes from the user typing a malicious instruction straight into the chat, which is easier to filter because you control that input channel. Indirect injection is embedded inside content the system retrieves later, such as a webpage, document, or email, and the attacker never interacts with your system directly. Indirect injection is generally the higher-risk category because it can compromise a system through content an ordinary, trusted user innocently asked the assistant to read.
Does a smaller or open-weight model make prompt injection worse?
Model size and openness are not the deciding factor; instruction-following capability and the surrounding system architecture are. A frontier model that can take unrestricted actions is more dangerous when hijacked than a small model confined to read-only summarization. Focus hardening effort on the action surface and privilege boundary around the model, not on switching models in the hope that a different one is inherently immune, because none currently are.
How often should we red-team our AI agents for prompt injection?
Before every production launch, and again whenever you add a new tool, data source, or action capability to an existing agent, since each addition changes the attack surface. Mature teams maintain an automated adversarial test suite that runs on every release rather than relying on a single pre-launch exercise, because injection techniques evolve continuously and a suite that was thorough a year ago will miss current attack patterns.
Get an adversarial red-team review of your AI agent's action surface before an attacker finds it first.
Related Tools
LLM Security Hardening Checklist
A practical control checklist for hardening LLM applications against prompt injection, insecure output handling, supply chain risk, and excessive agency, organized around the OWASP LLM Top 10.
On-Prem AIAI Incident Response Readiness Checklist
A practical readiness checklist for AI-specific incident response, covering detection, playbooks by incident type, escalation roles, containment, and post-incident reporting.
On-Prem AIOn-Prem AI Security Hardening Checklist
A practical control checklist for securing self-hosted language models, covering model provenance, network isolation, data governance, host hardening, and audit readiness.
Go Deeper
Prompt Injection Defense Architecture for the Enterprise
Prompt injection defense architecture for enterprise AI: input and output filtering, least-privilege tool access, and human approval gates.
The AI Incident Response Playbook
An AI incident response playbook: classify AI-specific incidents, contain a compromised agent, and run the postmortem that prevents a repeat.