A model API is a capability layer, not a security layer. Runtime protection belongs with the application deploying the agent, because that system controls its tools, data, and authority.
Model providers are right to invest in refusal behavior, toxicity avoidance, and jailbreak resistance under ordinary use. That work is model safety, not runtime security for an agent deployment. The distinction is structural.
Model Safety Does Not Secure Agent Runtimes
Model safety asks whether a model will generate harmful content under particular prompts. RLHF, constitutional AI training, output filters, and adversarial tests address that question. These methods reduce the chance of slurs, violent instructions, or explicit content in general-user interactions.
Runtime security asks whether an adversary can steer a production agent, connected to internal tools and acting for users, beyond its intended authority. The concern is not output alone. It is model behavior inside a system that can affect real resources.
Prompt injection is a runtime attack. The goal is not abstractly harmful text, but an incorrect tool call, data exfiltration, or bypassed access control. The result depends on application design as well as model training.
Runtime Context Sits Outside the Model API
Model providers lack the application information needed to provide runtime security well. That is a structural limit, not an oversight.
Detecting an adversarial prompt requires knowing the agent's intended task. "Summarize all emails from legal this week and attach them to a reply" may be benign in one application and an injection in another. The model API sees the assembled prompt, not the intent behind its construction.
Runtime security needs context-aware classification. The application knows the agent's tools, permissions, and expected requests, while the model provider does not. Without the application's threat model, an API classifier would create false positives that undermine practical use.
System Boundaries Divide Security Responsibility
Model providers sell access to inference and control the model's behavior. They do not control how you connect it to internal systems, which tools you expose, or what unsanitized input you provide.
A database vendor can provide a secure engine without preventing SQL injection in every application built on it. Developers must parameterize queries correctly. The database does not intercept the application layer.
We are not arguing that model providers communicate this distinction well. Some model-safety framing obscures the gap, which is a real problem. "Our model is safe" can sound to teams like "our application is secure." Those claims differ.
Provider Economics Discourage Inline Blocking
Aggressive inline injection detection could sometimes reject legitimate requests from paying customers. Coverage brings false positives. If a provider blocks or rate-limits an API call because its classifier flagged your system prompt, it harms your product. That is difficult business ground to defend.
Providers are incentivized to process requests quickly and reliably. A security layer that sometimes rejects paying customers conflicts with that objective. This is an economic constraint, not a criticism.
How the Missing Layer Appears in an Agent
Take a customer-onboarding agent that reads a CRM, creates summaries, and sends email through an integrated tool. Its system prompt defines its role and permissions. Users submit contact details and onboarding preferences.
An attacker places an instruction in the "company name" field, directing the agent to forward pending onboarding records to an external address before handling the current request.
Model safety training does not address this case. The text is neither violent nor explicit, and it is not a conventional jailbreak. It is a plausible instruction abusing email access. Output filters have nothing to flag. The attack occurs in the request context before generation.
That is exactly where Repellox operates: inspecting the assembled prompt and retrieved content before the model processes them, classifying adversarial patterns in context, and blocking requests that attempt to redirect the agent's tool access. We intercept at the request layer, not the output layer, because that is where the attack surface actually is.
Teams Must Own the Runtime Defense
If your agent connects to internal systems, runtime security is your responsibility, not a model-provider feature. The model API supplies capability. It does not supply the security layer.
That does not mean providers should be blamed for a problem outside their structural purview. It means agent security must be built in the application layer, where context, tools, and access boundaries meet. Providers cannot see that layer. You can, and that is where the defense belongs.
The provider-side gap will remain because the relevant context lives in the deploying application. Any defense against prompt injection must therefore sit where the agent's instructions, retrieved content, tools, and permissions are assembled.