AI agent guardrails: the wrong layer usually gets the blame

Most agent guardrail conversations start at the model and end at the model. Prompt filters, output classifiers, jailbreak detectors, refusal training. That's fine as far as it goes. But the failures that actually hurt production agents — the ones that delete data, leak records, or bill a customer twice — don't happen inside the model. They happen when a tool call executes. If your guardrails only sit around the LLM, you're guarding the wrong layer.

This is a POV piece, so here's the position plainly: AI agent guardrails are a runtime discipline, not a prompt discipline. The model is one input to the decision. The tool call is where the decision becomes real.

Pre-LLM and post-LLM guardrails are the easy half

The industry has converged on a reasonable pattern around the model itself. On the way in, you filter prompts for injection attempts, sensitive data, and policy violations. On the way out, you classify responses for toxicity, hallucinated citations, or leaked PII. Vendors like Lakera and open-source projects like NeMo Guardrails do this well.

This is useful. It's also the easy half. Pre-LLM and post-LLM guardrails treat the agent as a text-in, text-out system. Modern agents aren't. They're systems that decide to call tools, and those tool calls hit real APIs against real customer data. A perfectly polite response that includes the wrong SQL update is not a safe response. It's a production incident with good grammar.

The tool call is the real trust boundary

When a model emits a tool call, three things need to be true before it executes, and none of them are the model's job to enforce:

1. The caller has permission to do this thing. Not the agent's shared service account — the actual authenticated user on whose behalf the agent is acting. Row-level security, feature flags, plan limits, org boundaries. All the access rules your product already enforces for humans in the UI.
2. The arguments are within policy. A refund tool that can technically accept any amount should not, at runtime, accept an amount larger than the order total. That's not a prompt problem. Prompts are advisory; policy is binding.
3. The call is reversible, idempotent, or explicitly confirmed. Destructive actions need a different treatment from read-only ones. "Delete customer" and "list customers" should not sit behind the same runtime posture.

Call these agent runtime policy rules. They're the guardrails that matter, and they live outside the model on purpose. If the model gets jailbroken, gets confused, or hallucinates a tool argument, the runtime is the layer that has to hold.

Prompt-level guardrails fail silently; runtime guardrails fail loudly

Here's the asymmetry that keeps getting missed. When a prompt-level guardrail fails, you often don't know. The model complied with an injected instruction, the output classifier didn't catch it, and the tool call went through. The logs show a successful invocation. The incident is discovered when a customer notices.

When a runtime guardrail fails — when the tool call is rejected because the user lacks permission, or the argument is out of policy, or the action requires confirmation — you get a structured error. It's logged. It's countable. It shows up in dashboards. You can alert on it, rate-limit on it, and page on it.

That difference matters more than most guardrail vendors admit. You cannot operate what you cannot observe, and prompt-level failures are largely unobservable in the way that counts. Runtime failures are events. Prompt failures are vibes. If you're serious about tool call safety, you invest where the signal is.

What good agent runtime policy looks like

A working set of runtime guardrails is boring in a way that prompt guardrails aren't. It's a small number of enforced rules, applied consistently, at the point of execution:

• Every tool call executes as the authenticated user, not a shared service account. The user's real permissions apply. This alone eliminates a class of "the agent did something it shouldn't" incidents that have nothing to do with the model at all.
• Destructive tools require confirmation or run in a two-phase pattern (prepare, then commit). The model can propose the delete; a human or an explicit policy check has to commit it.
• Argument validation is declarative and enforced server-side. Not "we told the model in the system prompt to only refund up to $500." The refund endpoint refuses amounts over $500 for this user's role. Full stop.
• Every call is logged with the user identity, the arguments, the outcome, and the policy decisions applied. So when something goes wrong you can answer "who did what" without reconstructing it from LLM traces.

This is the layer that makes agents deployable in regulated environments. Not a better classifier. Not a bigger prompt. A runtime that treats tool calls as first-class security events.

How Pontil fits

The reason we keep coming back to this argument: Pontil operates in the tools layer of the agent stack, which is where runtime guardrails actually get applied. Our runtime executes tool calls as the authenticated user, honours the permission model your product already enforces, and treats every invocation as a logged, policy-checked event.

That's not a claim that Pontil replaces prompt-level guardrails — you still want those. It's a claim that if you're only doing prompt-level guardrails, you've secured the layer where failures are silent and left the layer where they're expensive unguarded. For teams whose agent projects have stalled at security review, the fix is rarely a better model. It's a runtime that a security team can reason about.

What to do differently

If your agent guardrail conversation lives entirely in prompt-land, move it. Ask three questions of your next agent design review. Which tool calls are destructive, and what stops them being called wrong? Whose identity does each call execute under, and does that identity carry the permissions your product already enforces? When a guardrail trips, where is the log, and who gets paged?

If you can't answer those without hand-waving toward the model, you don't have agent runtime policy — you have prompt hygiene. Both are useful. Only one of them will hold when the model gets it wrong.