Is AI model security the same as securing the training pipeline?

These are two different problems. Securing the training pipeline covers the model as an artifact: data provenance, poisoning defense, weight integrity, and fine-tune supply chain. Securing a deployed model at the access boundary covers the model as a running service: who may call it, what enters the prompt, what leaves in the response, and what gets recorded. Both matter, and they use different controls. A request-path gateway addresses the runtime access boundary and acts as a compensating control for artifact-level risks it cannot repair. The training-pipeline disciplines are covered in the poisoning and supply-chain articles linked above.

Can a gateway stop prompt injection?

A gateway on the request path adds a deterministic inspection layer that reads the inbound prompt, retrieved context, and tool definitions before they reach the model, and it records what it evaluated. That is a second line of defense on top of the model's own probabilistic refusal training. Neither layer eliminates injection alone, and indirect injection through retrieved content remains the hardest variant. Running an explicit request-path check plus model-level defenses is the practical posture, and the gateway also produces the audit trail when an injection attempt is caught or suspected.

Why not rely on the model provider's built-in guardrails?

Provider guardrails operate inside the inference process and are trained behaviors, so they are probabilistic and degrade under adversarial fine-tuning and pressure, as the Stanford and AIUC-1 briefing documented. They also apply only to the provider's own endpoints, which leaves any non-provider or self-hosted model in the same deployment ungoverned. An access-boundary control applies uniform, deterministic policy across every model an identity can reach and writes an independent record of each decision.

How does identity-aware authorization work when calls use a shared API key?

The shared key identifies the calling application, not the human or agent behind the request. An identity-aware gateway requires the application to pass the actual actor identity with each call, then evaluates that identity against per-model policy before forwarding. The audit record captures the resolved actor rather than the service account. Without this, every caller inherits the application's full model entitlements and the log attributes every action to one credential.

Does this replace our DLP?

Network-layer DLP inspects traffic underneath TLS and reads ciphertext, so it never sees the prompt or the completion. An access-boundary control terminates the AI request, inspects the decrypted prompt and response, and applies classification and policy to the actual content. It governs the AI request path specifically and complements, rather than replaces, DLP running elsewhere in the estate.

AI Model Security for Deployers: Governing the Access and Inference Boundary

A deployed model exposes exactly one interface an attacker can reach at runtime: the inference endpoint. Everything the model does in production happens because a request arrived at that endpoint, carried a prompt, and got a response back. When a security team says "we need to secure our AI model," most of what they can actually control in a running system lives on that request and response path, not inside the weights. The OWASP LLM Top 10 has ranked prompt injection at the top of its list across successive editions, and prompt injection is a runtime-boundary problem by definition. It arrives in the input.

I want to separate two things that get merged under "AI model security" and then walk the part a deployer can enforce. There is the model as an artifact, which the builder secures during training and packaging. There is the model as a running service, which the deployer governs at the point where identities send it prompts and receive answers. This article is about the second one, and it is deliberately narrow because the first one belongs to a different set of disciplines I will name plainly.

The access boundary is where a deployer has authority

A model you host or call has a request path that looks the same whether the weights sit in your VPC or behind a provider API. An authenticated user or an autonomous agent issues an HTTP call. The call carries an identity claim, a prompt, and sometimes tool definitions or retrieved context. The model returns tokens to the caller. That round trip is the surface a deployer owns and can instrument.

Three attacks ride that surface. Prompt injection reaches the model through the input. Sensitive data leaves through the output. Unauthorized callers reach a model they were never scoped to use. Each of these is visible on the decrypted HTTP request, which means each is governable by something sitting on that path. I covered the general case for putting enforcement on the request path in why AI security must be inline; model security is a specific application of that argument.

What sits outside the boundary, and why a gateway is a compensating control

Being honest about scope is the difference between a security claim a principal engineer trusts and one they discard. Several real model-security problems never touch the runtime request path, and no request-path control fixes them.

Training-data poisoning corrupts the model before it is ever deployed. An attacker seeds the training corpus so the model learns a backdoor or a bias, and by the time you call the inference endpoint, the damage is baked into the weights. That is a data-supply and training-pipeline discipline, covered in OWASP LLM03 training-data poisoning and AI model poisoning. Weight tampering and a compromised fine-tune supply chain sit in the same category, alongside the broader LLM supply chain security problem: they are attacks on the artifact and its provenance, handled by signing, integrity verification, and controlled training infrastructure.

Model-level safety guardrails also live inside the inference process rather than on the request path you control. Providers train refusal behavior through RLHF and fine-tuning, and those behaviors degrade under pressure. A Stanford Trustworthy AI and AIUC-1 consortium briefing, developed with CISOs from Confluent, Elastic, UiPath, and Deutsche Börse alongside researchers from MIT Sloan, Scale AI, and Databricks, found refusal behaviors significantly degraded under targeted fine-tuning and adversarial pressure. That is why model guardrails are not a security control in the enforceable sense.

A request-path gateway is a compensating control for these. It contains the runtime blast radius of a poisoned or manipulable model by governing who may reach it and what may leave in its answers, and it produces the evidence trail when something goes wrong. It does not repair the weights, re-clean the training set, or verify the fine-tune lineage. Treating a gateway as the fix for a training-pipeline attack is the overclaim to avoid.

Prompt injection reaching the model

Prompt injection is instruction text smuggled into the model's input so the model follows the attacker instead of the deployer. The direct form arrives in the user's own prompt. The indirect form arrives inside retrieved documents, a web page the agent fetched, or a tool result, and it is the harder variant because the malicious text never passed through a human.

The runtime signal is on the inbound request. A control on the request path reads the decrypted prompt, the retrieved context, and the tool definitions before they reach the model, and it can apply classification and policy at that point. The model-layer refusal training is one line of defense and it is probabilistic. The request-path check is a second, deterministic line: it evaluates the input against explicit rules and records what it saw. Neither line eliminates injection on its own, which is the practical reason defenders run both.

Data exfiltration through model outputs

Sensitive content leaves through the output path. A model that was given sensitive context, or that has memorized sensitive material, can emit PII, PHI, source code, or regulated financial data in its response. The exposure is the same whether a legitimate user phrased a clever prompt or an injected instruction steered the model toward the sensitive content. I walked through the channel mechanics in data exfiltration via LLM, and OWASP tracks the category as LLM06 sensitive information disclosure.

An outbound control on the response path classifies the tokens the model produced and applies a redact, block, or pass decision before the response returns to the caller. This is a genuine deployer capability because the response transits the same HTTP path the request did. Network-layer DLP is blind here: it runs underneath the TLS session and reads ciphertext, so it never sees the completion text.

Unauthorized model access by identity

The last access-boundary problem is authorization. In many deployments, model calls run on a shared service credential or a static API key issued to the application. The credential identifies the calling service, not the human or agent behind the request. Any caller who reaches the application reaches the model with the application's full entitlements, and the audit log, if one exists, records the service account rather than the actor.

Model security at the access boundary means answering a precise question on every call: which identity is invoking which model, for what purpose, and are they scoped to do so. The request-authorization model for AI traffic binds the call to a verified identity and evaluates it against per-identity, per-model policy. An identity-aware AI gateway is the component that carries that identity context onto the request path so the decision can be made and recorded.

Here is what an identity-aware model access policy looks like when authorization is expressed as configuration rather than left to whoever holds the API key:

The default: deny line is the one a committee would soften, and it is the line that matters. A model endpoint that accepts any authenticated caller by default has no access boundary worth the name. Scoping starts from refusal and opens only what policy names.

The audit record is the evidence layer

Every decision on the access boundary should produce a record: the verified identity, the model invoked, the inbound classification, the outbound classification, the policy version in effect, and the outcome. That record has to be committed independently of the application and before the response returns, or the system that failed is also the system writing its own alibi. The properties this record needs, and why application logs miss them, are in signed audit logs for AI requests. For regulated deployers, this is also what turns "we secured the model" into something an auditor can inspect under NIST's AI Risk Management Framework rather than a claim taken on faith.

DeepInspect

This is the part of AI model security a deployer can actually enforce, and it is the problem DeepInspect was built to solve. DeepInspect is a stateless, identity-aware policy gateway that sits on the HTTP path between authenticated users or agents and any LLM. It does two things at the access boundary and claims nothing beyond them.

First, it binds every model call to the identity the application supplies and evaluates that call against per-identity, per-model policy, so authorization stops being an implicit property of whoever holds the API key. It classifies the inbound prompt and the retrieved context, applies a block, redact, or pass decision before the request reaches the model, and applies the same classification to the outbound response before it returns to the caller. Second, it commits a signed, per-decision audit record containing identity, model, policy version, classification, and outcome, written before the application sees the response.

DeepInspect does not clean a poisoned training set, verify a fine-tune's provenance, or repair tampered weights. Those remain artifact-level disciplines outside the request path. What it provides is the runtime access boundary: it governs who may call which model, what may enter the prompt, what may leave in the response, and it produces the record that proves what happened. If your model security today rests on a shared API key and the provider's own guardrails, the access boundary is unenforced. Book a demo today.