Azure OpenAI Prompt Injection: What Prompt Shields Misses
Azure OpenAI’s prompt injection controls are scoped to a boundary, and most production agents sit...
Aug 14, 2026
Your prompt injection classifier is working. It scored the retrieved policy document clean, and the payload reads as ordinary instructional prose, planted three weeks earlier in a wiki page nobody has edited since.
Forty seconds later the support agent has queried a customer table it has never touched in six weeks of production, staged the results, and opened a connection to a destination that appears nowhere in its history.
Your stack notices. A kernel-level sensor flags an unusual outbound connection. Your CNAPP flags a new egress destination from the same pod. Your SIEM ingests the DNS resolution. Three signals, three queues, three analysts who may never speak to each other. The first ticket gets opened at minute fourteen.
Every one of those detections was correct. None of them mattered.
The question that decides whether a prompt injection becomes an incident is not which signal caught it. It is whether anything in your stack could act on that signal while acting still changed the outcome. That is an arithmetic problem, and most detection architectures fail it before they are ever attacked.
Three clocks run during a prompt injection, and whether you get breached depends on which one finishes first.
The damage clock starts when the agent acts on the injected instruction and stops when the objective completes. For an agent with tool access, you can calculate this rather than look it up. A read-and-exfiltrate chain against a database the agent is already authorized to query is a handful of tool calls: retrieve, query, stage, transmit. Each call returns in somewhere between a few hundred milliseconds and a couple of seconds, with model inference between them adding a comparable amount. Four to six calls end to end puts the chain in the range of tens of seconds.
An agent chain also skips the stages that make a conventional intrusion slow. There is no credential harvesting, because the agent already holds working credentials. There is no lateral movement to reach the data, because the agent is already authorized to query it. The reconnaissance an external attacker spends hours on was handed to the agent as a tool manifest at startup. Every phase of the standard kill chain that buys defenders time has been removed in advance by the architecture.
The signal clock starts at the same moment and stops when telemetry describing the behavior becomes observable to something that can score it. Kernel-level instrumentation resolves this in near real time. Cloud audit logs take minutes.
The response clock starts when a signal is scored and stops when an action executes. This is the one nobody budgets. Manual triage is widely reported across SOC tooling vendors at between fifteen and forty-five minutes per alert, and that number describes a single alert with an analyst already looking at it.
Not budgeting the response clock was the correct call for a decade. When the workload under attack was a human-paced application and the attacker was a human operator, a thirty-minute response was inside the window. Agent workloads moved the window and left the architecture in place.
Put the three clocks in order and the arithmetic is not close. If your response clock exceeds your damage clock, your detection stack produces a record of what happened. Call that telemetry. It carries real forensic and compliance value, and it carries no defensive value at all.
Fast enough is therefore a span that runs from the injected instruction to executed containment. The alert is a waypoint inside it, and every second spent between the alert and the action counts against the same budget as the seconds spent before the detector fired.
So the response clock has to shrink, which raises the obvious follow-up: act on the first signal available. The problem is that agent attack signals arrive in the wrong order.
The earliest observable deviations carry the least information. A retrieval that pulls from a source the agent has never used before is a deviation, and it is also a Tuesday. Corpus refreshes happen. New documents get indexed. The signal is real and it is nowhere near strong enough to justify touching a production workload.
The strongest signal is a completed chain: baseline deviation, then privilege use outside the observed set, then an outbound transfer to a destination with no history. That signal is close to unambiguous. It is also only available once the transfer is underway.
| Signal | Available at | Confidence on its own | Damage already done |
|---|---|---|---|
| Retrieval pulls from a source outside the agent’s history | T+0 to T+2s | Low | None |
| Assembled context contains a chunk from an unfamiliar source | T+0 to T+2s | Low | None |
| Authorized tool invoked against a target outside baseline scope | T+3 to T+15s | Moderate | Sensitive read complete |
| Tool sequence the agent has never executed | T+5 to T+30s | Moderate to high | Staging complete |
| Credential or metadata endpoint accessed outside baseline | T+15 to T+60s | High | Lateral movement available |
| Outbound transfer to a destination with no history | T+30s onward | Very high | Exfiltration in progress |
Read the first and last columns together. Confidence rises while remaining preventable damage falls. The two move in opposite directions and they meet somewhere in the middle of the table, and that meeting point is your entire decision window.
This is why a single alerting threshold cannot work for agent workloads. Set it low and you fire on corpus refreshes, model updates, and every legitimate expansion of an agent’s job, and your platform team turns the control off inside a week. Set it high and you have built a very accurate breach notification service.
None of this is an argument against prompt-plane detection. Classifiers and guardrails remove a large volume of unsophisticated attempts, and removing that volume is worth doing. The subject here is the residual. Zhan and colleagues evaluated eight published defenses against indirect injection at NAACL 2025 and bypassed all eight with adaptive attacks at success rates above fifty percent. Nasr and colleagues extended the result to twelve defenses with success above ninety percent for most of them. Any defense that scores content can be optimized against by an attacker who knows it is there. Your detection design has to assume a residual miss rate and be built to survive one.
An early signal needs a confidence source, and there is exactly one available before the damage completes.
Coercion is what makes this hard. A trusted prompt redirects capability the agent already holds. The agent queries a database it is authorized to query, using an identity it is supposed to use, over a network path that policy permits. Every individual step passes every control you own. The sequence is the attack.
That rules out the class of controls built on permission boundaries. RBAC returns valid. IAM returns valid. Network policy returns valid. The prompt-plane check was not wrong either, because indirect payloads arrive through the data plane as a retrieved document, a tool response, or a message from another agent. The content was never in the request the classifier inspected.
What changes is smaller and harder to fake. The agent stops behaving like itself.
That is the confidence source. A per-agent behavioral baseline scores four dimensions a coerced agent cannot avoid touching. Tool targets: which tables, buckets, and endpoints this specific agent actually reaches, against the much larger set it is permitted to reach. Tool sequences: which orderings it has executed before, because a file read followed by an outbound post is a chain, and chains are where coercion shows. Identity use: which credentials it exercises in normal operation, against which it merely holds. Egress destinations: where its traffic actually goes.
ARMO builds this per agent as Application Profile DNA, derived from what a kernel-level sensor observes rather than from what a manifest declares. The distinction matters for confidence scoring. Declared permissions describe a ceiling, and the ceiling is exactly the space coercion operates inside. A deviation scored against observed behavior is a deviation from a much tighter envelope, which is what makes an early signal worth acting on at all.
A confidence score is only useful if something is attached to each level of it. One rule makes automated response work on agent workloads: response cost tracks reversibility. Severity is the wrong axis, because a high-severity alert nobody can safely act on produces no action at all.
Killing a pod costs the same whether the alert was right or wrong. Restricting an agent’s egress to destinations it already uses is close to free to get wrong, because a false positive leaves the agent doing exactly what it was already doing. That asymmetry is what lets you act on a moderate-confidence signal at T+8 seconds instead of waiting for certainty at T+45.
| Confidence tier | What qualifies | Response | Cost if the alert is wrong |
|---|---|---|---|
| Low | One deviation on one dimension | Raise telemetry fidelity on this workload, hold the correlation window open | None |
| Moderate | Two correlated deviations inside one execution window | Restrict egress to baselined destinations, neutralize live credentials | One retryable failed call |
| High | Deviation plus privilege use outside the observed set | Soft quarantine, agent isolated and process preserved | Agent unavailable, restartable |
| Confirmed | Chain terminating in transfer to an unbaselined destination | Hard quarantine, forensic state preserved | Task loss, evidence intact |
ARMO ships the response column of that table as alert, soft quarantine, and hard quarantine, with the tier chosen by how far the deviation has progressed against the agent’s own profile. Credential neutralization sits in the moderate tier because it is the cheapest containment available against coercion specifically. An agent holding substitute credentials continues to run, continues to reason, and reaches nothing. If the deviation was legitimate, you have spent one retry. If it was not, the blast radius stopped expanding at T+8 seconds.
The high and confirmed tiers are where human judgment still belongs, and the tiering is what buys the time for it. An analyst deciding whether to terminate a workload is making a business call about an agent someone depends on, and that call benefits from context a scoring engine does not have. The point of containing at the moderate tier is that the analyst gets to make that decision with the exfiltration already stopped.
None of these tiers fire without telemetry resolved to a single workload identity. You need process execution, network connections, file access, identity usage, and tool invocation records on one timeline. The same signals sitting in five separate products are five separate tickets, which is the failure the opening scenario describes.
Everything above describes a system that acts on production agents without asking a human first. Security teams are right to be nervous about that. A probabilistic control with a block action attached is an outage risk, and treating it as one is the reason it survives contact with a platform team.
The way through is to separate the decision to detect from the decision to block. Run the full tiering logic in audit mode. Every response the platform would have taken gets logged, with the signal that triggered it and the baseline dimension it deviated from, and nothing gets blocked. After a week you have evidence about what your policy would have done to real traffic.
Read the audit log for two failure shapes. A tier firing on legitimate behavior means the baseline is not mature enough for that agent. A chain that should have fired and did not means a dimension is uninstrumented. Both are cheap to fix in audit and expensive to discover in enforce.
The same log answers a question that arrives later from a different direction. When a board or an auditor asks whether your AI agent policies are actually enforced, that log is the answer: which deviations were scored, what containment fired against each one, and how long it took to execute.
Then graduate per workload. The agent with the narrowest job and the tightest baseline goes first, which is the same observe-then-enforce progression that keeps generated network policies and seccomp profiles from breaking production.
Behavioral drift is the standing objection, and it has a clean answer. Agents legitimately change when models update, prompts change, and tools get added. Those changes correlate with deployment events. A behavioral shift arriving with a pod restart and a new image digest is drift. A behavioral shift arriving with no infrastructure change behind it is a deviation. Correlating the two is what keeps a maturing baseline from becoming an alert generator, and it is why this needs Kubernetes context rather than syscall data alone.
The instrumentation cost is lower than the argument suggests. ARMO’s kernel-level eBPF sensor runs at one to two and a half percent CPU and one percent memory with no sidecars and no code changes, which means the platform team is being asked to approve a DaemonSet.
The detection market optimizes the signal clock. Every new classifier, guardrail, and scanner competes on whether it notices the attack, and the competition has produced better detectors. It has not moved the number that decides the outcome.
Measure one thing in your own environment: the time from first scored baseline deviation to executed containment. If that number is expressed in minutes, the detectors you add next will produce better records of the same breach. If it is expressed in seconds, the stage at which an injection gets caught starts to matter, because catching it early now changes what happens.
The good news is that you are probably not missing the telemetry. Most clusters running AI agents already emit process execution, network connections, and identity usage. What is missing is a per-agent baseline to score it against and a graded response attached to the score. That is a configuration problem sitting on top of data you already have.
Getting that number down also changes what you are able to approve. A team that can contain a coerced agent inside a few seconds can hand agents broader tool access, because the cost of being wrong about any single grant has fallen. Containment speed is what buys the room to expand.
ARMO is built around this arithmetic. One kernel-level sensor records what every agent actually does, that record becomes the Application Profile DNA a deviation gets scored against, and the same profile drives containment through the Audit to Enforce progression. Detection and response run off a single artifact, which removes the handoff where most of the response clock is spent. In most programs the detection layer captures a deviation the enforcement layer cannot consume, and the gap between them is filled by a human paging another human.
That is also what the analyst sees at the end of it. Instead of three tickets in three queues, the incident arrives assembled: which agent deviated, on which dimension of its profile, what it reached, and which containment tier fired against it.
See how cloud-native security for AI workloads scores agent deviation and contains it before the transfer completes.
How fast does prompt injection detection actually need to be? Fast enough to beat the damage clock for the agent in question, which makes the threshold per agent rather than universal. An agent with read-only access to a single non-sensitive dataset can tolerate minutes. An agent holding write access to production systems or reachable credentials needs containment inside the first thirty seconds, because that is roughly the window in which a read-stage-transfer chain completes. Work backwards from what the agent can reach.
Can you detect prompt injection without inspecting prompts? You can detect the consequence, which is the part that matters operationally. Runtime behavioral detection does not identify the injected text. It identifies the agent acting outside its own established pattern, which is what a successful injection produces. The behavioral approach is the only one still available after an indirect payload has already passed a content check.
How long before a behavioral baseline is reliable enough to act on? Plan for one to two full deployment cycles of observation, long enough to capture scheduled jobs, scaling events, and the seasonal edges of the agent’s work. Reliability is a property you read out of audit-mode logs rather than a fixed date: when a week of audit produces no tier firing on legitimate behavior, the baseline is ready for that agent. Agents with narrow repetitive jobs mature in days. Agents with broad tool access take longer.
What happens when an agent legitimately changes what it does? Correlate the behavioral shift with infrastructure events. Legitimate change arrives alongside a pod restart, a new image digest, an updated model version, or a tool registration, and the baseline absorbs it as drift. A shift with no corresponding deployment event gets scored as a deviation. The correlation is the discriminator, which is why this requires Kubernetes context and not syscall telemetry on its own.
Does automated containment risk breaking production agents? It does if you enforce before the baseline is mature, which is the reason to run audit first and graduate one workload at a time. The tiering design limits the remaining exposure, because the responses that fire on lower-confidence signals are reversible by construction and a false positive at the moderate tier costs a retried call rather than a failed job. Irreversible actions stay reserved for chains that have already reached an unbaselined external destination.
Azure OpenAI’s prompt injection controls are scoped to a boundary, and most production agents sit...
Bedrock Guardrails do not inspect your agent’s tool calls. AWS says so, in its own...
You can harden an agent against prompt injection in an afternoon. Delimiters around retrieved content....