Where Agent Security Controls Actually Sit at Runtime

Most agent security advice arrives as a list. Prompt injection, PII leakage, tool poisoning, sensitive-data exposure, unsafe actions. The list keeps growing, and every new threat gets its own detection technique. What the list never answers is the question a builder actually needs settled before shipping: where does each control run?

A control that catches prompt injection is useless if it fires after the malicious input already reached the model. A hallucination check that runs before generation has nothing to check. The point in the execution loop where a control sits determines whether it works, what it costs, and how much damage it can prevent. Security for AI agents is an architecture problem, and the architecture has three planes.

Security advice is a pile of controls without a map

Teams assemble a set of defenses and wire them in wherever integration is easiest. Injection detection lands in one middleware, PII redaction in another, output validation somewhere near the response handler. Each control works in isolation. Together they leave gaps, because nobody decided which plane each control belongs to.

The fix is to sort every control into one of three planes based on when it runs relative to the model call:

• Pre-deployment runs before the agent is ever live.
• Pre-LLM runtime runs in the hot path, before input reaches the model.
• Post-LLM runtime runs after the model responds, before the output is acted on or returned.

Once controls are mapped to planes, the gaps become obvious and the cost of each control becomes a deliberate choice rather than an accident of where it happened to get wired in.

The three planes of agent security

Pre-deployment is the security work you do once, before shipping. Scoping the agent's access to the minimum it needs, red-teaming known attack classes, and turning every attack you discover into a regression test so the same exploit can't quietly return. These controls don't run per request. They shape what the agent is allowed to do and prove it holds up against known attacks before real traffic arrives.

Pre-LLM runtime runs on every request, before the user's input and assembled context reach the model. Its job is to protect what goes in: strip sensitive data, block malicious input, stop injection attempts before the model ever sees them.

Post-LLM runtime runs after the model returns a response, before that response is acted on or returned to the user. Its job is to control what comes out: validate the output, check for leaked data, confirm the agent chose safe actions.

Each plane has a different latency budget and a different failure consequence. Putting a control in the wrong plane is the most common architecture mistake, and it usually shows up as either a slow agent or a breach that a correctly placed control would have stopped.

Pre-LLM: protect what goes into the model

Pre-LLM controls handle three jobs. PII detection and redaction strip personal and company data before it leaves your environment for an external model provider. Sensitive-data blocking keeps credentials, credit card numbers, and proprietary internal data out of the model's context. Prompt injection detection identifies input crafted to override the system prompt or hijack the agent's behavior before it reaches the model.

The design constraint on this plane is speed. These checks run before every single LLM call, in the hot path, so they add latency to every request whether or not anything is wrong. A guardrail that runs in the hot path should be fast and deterministic: regex-based PII detection and rule-based injection checks add minimal overhead. Reserve model-based judgment for cases that genuinely need it, because an LLM call in the pre-LLM plane doubles your latency and cost on every request.

For a customer-facing agent that handles bookings, payments, and account details, PII redaction in this plane is often a hard compliance requirement. Every conversation passes through detection before anything is sent to the model, and identified PII is redacted so customer data never reaches an external provider.

Post-LLM: control what comes out

Post-LLM controls run after generation. Output validation confirms the response conforms to the expected structure. Tool and action validation verifies the agent selected safe tools and correct actions given the request. Leak checks scan the response for sensitive data that shouldn't be surfaced. Hallucination detection confirms the model's claims are supported by the context it had access to.

The strongest pattern on this plane is self-correction. Instead of blocking a flagged response and surfacing a failure to the user, feed the flagged issue back to the model with a targeted correction request: here is what you said, here is what was unsupported, revise it. The agent retries, the revised output runs through the check again, and this repeats until it passes or hits a retry limit. A control that would otherwise produce user-facing errors becomes a quality guarantee baked into the loop.

Post-LLM checks that rely on a model to assess output add latency and cost per request, the same tax that applies in the pre-LLM plane. Scope model-based post checks to what genuinely requires that level of judgment, and use deterministic validators for structure and format where they'll do the job more cheaply.

Pre-deployment: the security work that can't wait for runtime

Some controls can't be enforced at request time. Access scoping is the clearest example: an agent should hold the minimum permissions it needs to do its job, and that decision is made before the agent is live, not on the fly. An agent with read/write access to systems it never needs is a standing risk no runtime guardrail fully offsets.

Red-teaming belongs here too. Before shipping, run the agent against known attack classes, prompt injection variants, data-exfiltration attempts, unsafe tool sequences, and observe how it behaves. Every attack that succeeds becomes a test case. Turning discovered failures into a regression suite you re-run before every deployment means the same exploit can't silently reappear after a prompt change or model swap. The suite grows over time into a record of every attack the agent has learned to withstand.

Why the boundary matters: cost, latency, and blast radius

Placing a control in the wrong plane fails in one of two ways. Put a control too late and it's ineffective: an output validator that flags injected instructions is checking damage that already happened, because the injection needed to be blocked pre-LLM. Put a control too early or too heavy and it's expensive: an LLM-based check in the pre-LLM hot path adds latency and cost to every request, including the overwhelming majority that are perfectly benign.

Mapping controls to planes is a performance and risk decision. Pre-LLM controls trade a small, constant latency cost for a large reduction in what the model is ever exposed to. Post-LLM controls trade per-request cost for control over what reaches the user. Pre-deployment controls cost nothing at runtime but require discipline before shipping. Knowing which plane a control belongs to tells you what it should cost and what it can actually prevent.

You can't secure a plane you can't see

Every control decision should leave a trace. When a pre-LLM guardrail redacts PII, when a post-LLM check catches an unsupported claim, when a self-correction loop retries, each event should emit telemetry just like any other step in the agent's execution. Instrumenting every tool call, retrieval, and decision point turns your security controls into an audit trail: you can see how often each guardrail fires, what it catches, whether self-correction succeeds, and whether a sudden spike in injection detections signals an active attack.

Tracing is itself a security control. Without it, you're enforcing policies you can't verify and responding to incidents you can't reconstruct.

Layered security as a governance signal

Enterprise review asks a direct question before an agent goes live: what controls are in place, and can you show them? A documented three-plane architecture answers that question concretely. You can point to what runs before deployment, what intercepts input, and what validates output, with telemetry proving each one fires in production.

Agents that emit their control decisions to standard, centralized destinations can be discovered and assessed automatically. Being able to demonstrate active guardrails across all three planes during agent discovery and governance review is a meaningful signal of production readiness, and it shortens the review cycle. An agent that can't show its controls faces longer reviews and harder questions.

TLDR

• Agent security is an architecture, not a list of threats. Sort every control into one of three planes based on when it runs.
• Pre-deployment: access scoping, red-teaming, and regression suites built from discovered attacks. Runs once, before shipping.
• Pre-LLM runtime: injection detection, PII redaction, sensitive-data blocking. Runs in the hot path, so keep it fast and deterministic.
• Post-LLM runtime: output validation, action validation, leak and hallucination checks. Use self-correction to fix flagged responses before they reach the user.
• A control in the wrong plane is either too slow or too late. Placement is a cost and risk decision.
• Emit every control decision as telemetry so you can audit, detect anomalies, and demonstrate controls in governance review.

Ready to see where your agent's controls actually sit? Book a demo with an AI expert.

‍