Should organisations rely on model safety features alone to stop prompt injection?

No. Model-level guardrails reduce risk, but they do not define enterprise context, data boundaries, or action permissions. Organisations need their own enforcement layer for prompts, responses, and tool calls because the provider cannot know which business process is safe, which data is sensitive, or which action is out of bounds.

Why This Matters for Security Teams

Model safety features are useful, but they are not a complete defence because prompt injection is not only a language problem. It is an access-control problem, a data-boundary problem, and, in agentic systems, an execution problem. A model may refuse obvious malicious text and still be induced to reveal sensitive context, select the wrong tool, or pass unsafe instructions to a downstream workflow.

That is why current guidance increasingly separates model behaviour from enterprise enforcement. The attack surface spans prompts, retrieved content, tool calls, and the identities used to act on behalf of a user or workload. The OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same operational truth: the system that invokes the model must also control what the model is allowed to see, decide, and trigger.

NHI security teams should think in terms of policy enforcement, not model trust. If a prompt can influence a helpdesk bot, a code assistant, or a customer service agent, then the real question is whether that influence can reach secrets, customer data, or privileged actions. In practice, many security teams encounter prompt injection only after a tool invocation or data leak has already occurred, rather than through intentional testing.

How It Works in Practice

Effective defence uses layered controls around the model, not just within it. Start by classifying prompt sources, retrieval sources, and tools so the application can distinguish trusted instructions from untrusted content. Then enforce allowlists for tools and outputs, short-lived credentials for each task, and policy checks before any external action is taken. This is where OWASP Agentic AI Top 10 is useful as a design reference, while NHIMG’s OWASP Agentic Applications Top 10 frames the broader identity and governance implications.

• Use intent-based authorisation so the system evaluates what the user or agent is trying to do, not just who asked.
• Issue JIT credentials with tight TTLs for every agent task, then revoke them automatically on completion.
• Bind workload identity to the executing agent so tool access is cryptographically tied to the right service or runtime.
• Separate sensitive context from general prompts, and redact or tokenise secrets before model interaction.
• Apply real-time policy evaluation to tool calls, file access, and outbound network requests before execution.

For identity binding, implementation patterns such as SPIFFE and OIDC-based workload identity are often more reliable than static API keys because they prove what the workload is at runtime, not just what credential it possesses. Where teams rely on model-only guardrails, the system remains vulnerable to prompt smuggling through retrieved documents, chained tool use, and indirect instruction following. That is why the OWASP Agentic AI Top 10 emphasises application-layer controls alongside model defence. These controls tend to break down when agents are allowed broad tool chaining across SaaS systems because the model can still assemble a harmful sequence from individually permitted actions.

Common Variations and Edge Cases

Tighter prompt and tool controls often increase operational overhead, requiring organisations to balance safety against developer friction and latency. That tradeoff is real, especially where teams want autonomous workflows to remain fast enough for customer support, DevOps, or code-assist use cases.

Best practice is evolving for agents that operate across multiple systems, and there is no universal standard for this yet. Some environments can rely on strong filtering plus human approval for high-risk actions; others need fully automated policy-as-code because no human can review every step in time. The more autonomous the agent, the less useful static RBAC becomes, because behaviour changes with context, retrieved data, and prior tool output. In those cases, ZTA, ZSP, and ephemeral secrets become more important than perimeter assumptions.

One practical rule is to treat every agent action as a new authorisation decision. That means prompt injection tests should cover retrieval poisoning, malicious tool output, and indirect prompt injection from third-party content. For governance, the OWASP Agentic AI Top 10 and NHIMG research are most valuable when used together with internal policy that defines which data, tools, and actions are acceptable for each agent class. Current guidance suggests model safety features should be considered a control input, not a control boundary.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How does automated secret rotation change the operational model?
• How do organisations reduce false positives in secret detection pipelines?