Place hard controls at the point where untrusted text could influence tools, data, or execution. That means non-LLM enforcement before the model, plus separate governance for tool permissions and retrieval. If a control can be steered by the prompt it is meant to inspect, it is not a boundary.
Why This Matters for Security Teams
Prompt injection controls fail most often when teams treat the model as the enforcement point. The model is not a reliable boundary if the text it is reading can also steer what it decides to inspect, retrieve, or execute. That is why the control decision has to start with trust boundaries, not with the prompt itself. The risk is especially sharp in agentic systems, where untrusted content can influence tool calls and downstream actions.
Current guidance from the OWASP Agentic AI Top 10 and NHIMG research on the OWASP Agentic Applications Top 10 points to a simple principle: inspection is not protection unless the inspecting component is outside the attacker’s influence. For NHI-heavy environments, this matters because the same prompt path often reaches secrets, APIs, and service accounts. NHIMG notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which aligns with the need to keep untrusted text away from enforcement logic.
In practice, many security teams encounter prompt injection only after a model has already triggered a tool call, leaked data, or chained into a broader workflow.
How It Works in Practice
The practical answer is to place hard controls before the model reaches anything that can act on untrusted input, and then split governance across tool access, retrieval, and output handling. The model can assist with classification or summarisation, but it should not be the only gate that decides whether a request is safe. For runtime decisions, current best practice is moving toward non-LLM enforcement, policy-as-code, and separate authorisation for each tool or data source.
In agentic systems, this usually means four layers:
- Pre-processing filters that remove or label untrusted content before it reaches the model.
- External policy checks that evaluate request context without asking the model to judge itself.
- Tool-level allowlists and scoped permissions that limit what an agent can do even if it is manipulated.
- Retrieval controls that restrict which documents, vectors, or connectors can influence the response.
This structure fits the direction described in the OWASP Agentic AI Top 10 and NHIMG’s analysis of JetBrains GitHub plugin token exposure, where trust in a connected workflow led to credential exposure and downstream risk. The control point should be wherever untrusted text could influence secrets, tool permissions, or retrieval scope, because that is where the attack becomes operational rather than textual.
Teams should also treat prompt injection as a boundary problem, not just a content problem. If a connector, retrieval index, or agent tool can be manipulated into returning higher-privilege context, then the real weakness is the integration layer, not the wording in the prompt. These controls tend to break down in multi-tenant copilots with broad connector access because the model can be steered into calling the wrong tool with the right credentials.
Common Variations and Edge Cases
Tighter prompt-injection controls often increase latency, false positives, and operational overhead, requiring organisations to balance safety against usability. That tradeoff is especially visible in workflows that need rich context from email, tickets, documents, or code repositories, where overly aggressive filtering can block legitimate work. Best practice is evolving, so there is no universal standard for exactly how much should be blocked at the model layer versus at the tool layer.
A few edge cases matter most:
- For read-only assistants, retrieval restrictions may do more than prompt filtering because the main risk is data exposure, not action execution.
- For autonomous agents, tool permissions and runtime policy checks matter more than prompt guards because the model can chain actions unexpectedly.
- For regulated environments, control placement should follow the data path, especially where secrets, customer records, or production systems are reachable.
The emerging pattern aligns with the Ultimate Guide to NHIs — Standards, which emphasises governance at the identity and access layer, and with the OWASP Agentic AI Top 10, which treats indirect instruction following as a system design issue. In short, place hard controls where prompt influence turns into privilege, because that is where prompt injection becomes a breach path rather than a language trick.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Prompt injection is a core agentic-app risk at the tool boundary. |
| CSA MAESTRO | AI-01 | MAESTRO addresses governance for agent workflows and control placement. |
| NIST AI RMF | AI RMF applies to managing model and system risks from untrusted inputs. |
Map prompt-injection risk to AI RMF and define preventive controls at input, tool, and retrieval boundaries.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
