An agent passes every prompt-injection benchmark you run against it in isolation. Clean scores, every time. Then in production, it retrieves a support ticket that contains three sentences of hidden instructions buried in the customer's message, and four tool calls later it has forwarded a different customer's billing details to an address nobody approved.

Nothing about the model changed between the benchmark and the incident. What changed is that the model was no longer just talking — it was retrieving, deciding, and acting, across a session with memory and tools attached. Agent operational security is the practice of monitoring and constraining what an AI agent does at runtime — its tool calls, memory writes, and delegated actions — not just what it says. That's a different problem than the one most LLM safety tooling was built to solve.

Model Safety vs. Agent Safety

Most "AI safety" tooling today answers one question: what can the model say? Content filters, RLHF alignment, and prompt-injection classifiers all operate on that single axis — a message goes in, a message comes out, and something checks whether the output is acceptable.

That's necessary — but it isn't the whole of AI agent security once a model can call tools, write to memory, delegate to sub-agents, and take multi-step action without a human approving each step. At that point the attack surface isn't "what can the model say" — it's "what can the agent do." The industry has started drawing this line explicitly: alongside the established OWASP LLM Top 10, a newer OWASP Agentic AI (ASI) Top 10 now covers failure modes that only exist once an LLM has agency — goal hijacking, tool misuse, privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures, and rogue agent behavior.

Where Prompt Injection Hides in Production Agents

The obvious version of prompt injection — a user typing "ignore your previous instructions" — is the one everyone tests for. It's also the least interesting version now. In practice, the same injection pattern shows up arriving through channels a message-level filter never sees:

• Fetched web content. A tool call retrieves a page, and the page itself contains role-override language planted for exactly this purpose.
• API and database responses. A downstream service or SQL result carries an instruction fragment in a field the agent trusts implicitly, because it came from "its own" tool.
• Persistent memory. An adversarial directive gets written into shared memory in one session and only activates when a later session reads it back — which means a single-session security check would never catch it.
• Sub-agent delegation. One agent hands work to another with no auth signature at all — not a weak one, just absent — because nobody thought to require it inside the trust boundary of "our own fleet."

None of these are things a static prompt filter can catch before the agent acts, because the payload was never in the user's message. It was in the world the agent was told to go read.

Agent Detection Runs on Three Clocks

A single real-time check can't cover everything, and neither can a single post-hoc audit. Some things have to be caught the instant they happen; others only become visible once you can see the whole session, or even the whole week. Detection should run on three time horizons, because attacks unfold at different speeds:

Real-Time Detection

High-confidence, deterministic patterns — delimiter smuggling (control tokens like [SYS] or <|im_start|> injected into a user turn), a live credential appearing in agent output — should be caught inline, in time to gate or terminate the session before it does damage.

Post-Session Detection

Once a session ends, the full replayed event history opens up checks that can't run mid-conversation: a goal that drifted across five turns without any single turn tripping an alarm, or a citation the agent fabricated to a source it never actually retrieved. You need the whole conversation to see either one.

Cross-Session Detection

Some patterns only surface over a longer window — a rolling seven days is a reasonable default — because no single session would ever reveal them: the same credential reused by two different users, or an exfiltration signature repeating across many sessions specifically to stay under any one session's radar.

Treating all of these as one static "is this safe" check is how the slow ones get missed.

Chained Findings Mean Bigger Risk

Here's a pattern worth sitting with: three medium-severity findings in a session are usually not "medium risk, times three." They're often one high-severity incident wearing a disguise, because real attacks chain.

Take a realistic sequence: a retrieved document smuggles an instruction (prompt injection), the agent responds by invoking a tool that was never in its declared manifest (tool misuse), and that tool's output — which included sensitive data — gets forwarded to an external endpoint (data disclosure). Scored independently, none of those three findings looks catastrophic. Chained together, they describe an actual exfiltration.

Good scoring models account for exactly that. Known attack-chain patterns can carry an amplification multiplier on top of the composite score, so a chain that plausibly ends in exfiltration — or worse, unexpected code execution — scores meaningfully higher than any of its parts would alone. The point isn't the specific multiplier. It's that a scoring model built only on isolated signals will systematically undercount the sessions that matter most, because the sessions that matter most are rarely single-signal.

Agent Trust Should Decay Over Time

It's tempting to treat "we reviewed this agent and it's safe" as a permanent state, the way a code review certifies a PR. Agent behavior doesn't work that way — the same agent, same code, same prompt, can behave differently against a different retrieved document or a different week of traffic.

If every input and every output in a session came back clean, do you still trust the agent — or do you trust that specific transcript?

One approach that holds up well: compute agent trust as a probabilistic score with a weak prior that has to be earned back over time through actual clean sessions, decaying if an agent goes quiet or starts drifting. A trust score is a snapshot of recent behavior, not a certificate. Treating it as the latter is how "we already checked this agent" becomes the sentence right before an incident.

Agent Security Operational Checklist

These are the fundamentals of agent operational security in practice — worth doing in any production environment, regardless of what tooling you use:

• Declare a tool manifest and enforce it as a hard boundary, not a suggestion — any tool call outside it should be a stop condition, not a warning.
• Gate irreversible actions behind a human-in-the-loop step. Deletion, payment, and outbound communication tools are exactly where "the agent seemed confident" is the wrong signal to trust.
• Treat retrieved content, tool output, and memory as untrusted input — the same scrutiny you'd give a user message, applied to every channel the agent reads from, not just the chat box.
• Baseline normal behavior per agent — tool-call fan-out, token spend, session cost — so a spike is visible against that agent's history, not some fleet-wide average that hides outliers.
• Score on more than one clock, and keep real-time cheap. Limit the inline layer to fast, high-confidence checks; push anything heavier to post-session or cross-session so it doesn't cost response time.
• Let trust decay. An agent's risk posture should be recomputed continuously from recent behavior, never certified once and left alone.

This is what agent operational security looks like in production at DapplePot — real-time and post-session detection across the OWASP LLM and Agentic AI Top 10, with cross-session pattern matching and attack-chain-aware scoring underneath it. If that's the kind of visibility you're missing on your own agent fleet, get in touch.