Who should own prompt injection risk in an organisation, security teams or AI application teams?

Why This Matters for Security Teams

Prompt injection is not just a model-quality issue. It is an application security and identity problem because attackers use instructions, retrieved content, and tool outputs to redirect an agent’s behaviour. That means risk ownership cannot sit in one silo. Security teams need to define the control baseline, but the team operating the AI application is the one closest to prompt sources, tool permissions, and runtime monitoring.

This is why current guidance increasingly treats prompt injection as a control-plane issue rather than a content-filtering problem. The OWASP Agentic AI Top 10 and NHIMG research on OWASP NHI Top 10 both show that injected instructions become dangerous when an agent can take action, call tools, or chain decisions without strong runtime checks. In practice, many security teams encounter prompt injection only after the application has already exposed data, triggered an external action, or amplified a low-trust input into an operational incident.

For the broader security program, this lines up with NIST Cybersecurity Framework 2.0 because ownership must be mapped to the asset, the workflow, and the control owner rather than assumed from the model vendor alone.

How It Works in Practice

Operational ownership usually means the AI application team owns the day-to-day risk treatment, while security owns policy, testing expectations, and exceptions. That split works because prompt injection is introduced at runtime through user prompts, retrieved documents, web content, tickets, emails, or agent tool outputs. Security can set the standard, but only the application team can instrument the code paths that mediate those inputs.

In practice, mature organisations define a shared control pattern:

• Security sets minimum requirements for prompt handling, tool scoping, data classification, and red-team testing.
• Application teams implement input sanitisation, retrieval filtering, tool allowlists, and output verification.
• Both teams review whether the agent can read, write, send, delete, or execute beyond what the business task requires.
• Monitoring covers anomalous tool calls, unusual prompt patterns, and cross-step behaviour that suggests instruction override.

The best-practice direction is also influenced by agentic AI guidance from OWASP Agentic AI Top 10, which emphasizes that an injected prompt becomes materially risky when it can influence decisions, memory, or connected systems. NHIMG’s Gemini AI Breach analysis is a practical reminder that even ordinary integrations can become exposure paths when instruction boundaries are weak. These controls tend to break down when a single agent has broad tool access across multiple systems because the injection path and the blast radius expand at the same time.

Common Variations and Edge Cases

Tighter prompt controls often increase engineering overhead, requiring organisations to balance safety against delivery speed. That tradeoff is most visible in teams building customer-facing assistants, internal copilots, and multi-agent workflows, where blocking every risky pattern can degrade usefulness. Current guidance suggests the right answer is not blanket restriction, but risk-based scoping by task and privilege.

There is no universal standard for this yet, but a few edge cases are already clear. If the AI system only summarizes text and cannot call tools, the prompt injection risk is lower and can often be managed by security review plus logging. If the system can access secrets, issue transactions, or modify records, ownership should become much more explicit and the application team should carry stronger implementation responsibility.

The same logic applies to vendor-hosted models and internal agents alike: security still defines the policy baseline, but the team that configures retrieval, memory, tool access, and fallback behaviour owns the operational exposure. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because prompt injection often becomes an NHI issue once an agent starts acting with durable credentials or delegated privileges.

Related resources from NHI Mgmt Group

• How should security teams reduce indirect prompt injection risk in AI systems?
• How should security teams reduce prompt injection risk in AI agents?
• How should security teams test AI-enabled mobile apps for prompt injection risk?
• How should security teams secure Microsoft 365 Copilot extensions and AI agents against prompt injection and remote execution risk?