AI Firewall Action Design: Block, Redact, Replace, or Alert

AI security discussions often over-focus on detection. Detection matters, but it's only half the control. Once a risk is caught, the system still has to decide what to do about it.

That's where a lot of AI controls fall apart, either too weak to matter or too painful for anyone to keep using.

If every issue becomes an alert, you've recreated the SIEM problem: plenty of signal, not enough action. If every issue becomes a block, business users learn to route around the control within a week. If redaction is applied without context, the output turns into something nobody can actually use. If content replacement isn't logged, the audit trail ends up misleading everyone who relies on it.

An AI firewall needs more than a risk score. It needs a response model.

The four core actions

A practical runtime control should support at least four primary actions: block, redact, replace, and alert.

Blocking stops the interaction outright, and it belongs anywhere the risk is unacceptable if allowed to continue. An agent attempting a high-risk tool action, a request to exfiltrate sensitive data, a model output that would hand someone unsafe operational instructions. There's no version of these where letting the interaction proceed and cleaning it up after is the safer choice.

Redaction masks or removes sensitive content outright, with no expectation that anyone downstream needs to know what was there. A draft that quotes from a confidential internal memo, a regulated field the recipient has no legitimate reason to see the shape of, a passing reference to something whose category alone would leak information. None of that needs to survive into the final output in any form, labeled or not, so it just comes out.

Replacement works differently from a display-time swap. Sensitive values get substituted with a structured variable, something like EMAIL_1 or PHONE_1, before they ever reach the model, so the LLM only sees the placeholder. When the response references that placeholder, the system swaps the real value back in before it reaches the user, agent, or application. The same mechanism also catches a sensitive value that only shows up in the model's own output, tokenizing it before it travels any further and restoring it only where someone's actually authorized to see it. Either way, the interaction looks unchanged from the outside. What's different is where the raw value was allowed to exist.

Alerting flags an event for review without stopping anything. It's the right call for suspicious patterns that don't clear the bar for a block, low-confidence detections you'd rather have a human eyeball than auto-resolve, and cases where interrupting the workflow would cost more than the risk itself. An unusual sequence of tool calls from an otherwise normal session, for instance, is often worth a look before it's worth a wall.

Why context changes the response

The same signal can call for a different action depending on where it shows up.

A secret in a generated answer might call for replacement if someone downstream is still authorized to see the real value, or redaction if no one is. That same secret headed into an external tool call is a different story: no amount of context makes it safe to send, so it gets blocked. A sandbox environment running a suspicious prompt can usually just get flagged for someone to check later. Put that same prompt in a production workflow touching customer data, and alerting alone probably isn't enough.

Here's one interaction worked all the way through. A support agent asks an AI assistant to draft a reply to a customer, and the draft includes the customer's account number in plain text. The data's sensitive, but this is a read-and-respond, not a send-and-execute. The source is a trusted internal workflow, confidence in the detection is high, and the cost of blocking outright is real: the support agent is left with nothing to send.

Replacement is the right call, and the mechanics matter here. Before the assistant drafts anything, the account number gets swapped for a placeholder like ACCOUNT_NUMBER_1. The model only ever works with the token. Once the draft comes back, the system restores the real number before the reply reaches anyone. Nobody downstream notices a thing happened. What actually changed is that the number was never exposed to the model in the first place.

Now say that same draft also references an internal project codename that has no business showing up in a customer-facing message. There's nothing to restore here, and no reason to. It gets masked out entirely.

And if that account number had instead been headed into a tool call pushing it to a third-party marketing platform? Same data, same confidence, completely different call. Sending sensitive data to an unauthorized destination isn't something a placeholder fixes. That gets blocked.

Developer workflows run into the same problem, just with different stakes.

A coding assistant hardcoding an API key into a generated function is one case. That same assistant proposing a destructive database migration with no rollback path is another. Generated code calling out to a dependency nobody's approved is a third. A function that leaves a real internal hostname sitting in a debug comment, when a placeholder would've done the job just as well, is a fourth.

Four different problems, four different responses. Tokenize the API key before it reaches the model, restore it in the code once the model's done its work, and leave the rest of the function alone. Block the migration before it runs. Alert a reviewer on the dependency, since it might be legitimate and just unreviewed. Strip the hostname out entirely, since there's no reason it needed to be there.

This is why AI firewall policies have to weigh a handful of dimensions before picking a response:

• Data sensitivity: what information is involved?
• Action type: is the system reading, writing, sending, executing, or modifying?
• Target: which tool, endpoint, user, application, or system is affected?
• Source trust: did the instruction come from a user, retrieved document, web page, file, application, or tool output?
• Confidence: how certain is the detection?
• Business impact: what happens if the system blocks or allows the interaction?

Skip that weighing and policy gets crude fast. Crude policy blocks too much or lets too much through, and there's rarely a middle ground with it.

Evidence is part of the action

Every runtime action should leave evidence behind. That doesn't mean dumping raw sensitive data into a log. It means keeping enough context that someone could actually review what happened.

Useful evidence includes the risk category, the action taken, which policy matched, confidence level, the modality involved, the tool name if one was involved, user or workflow context, and a sanitized snippet where that's appropriate.

Security operations, compliance, tuning, incident response, all of it depends on this. So does trust. If a control intervenes and nobody can reconstruct why, that's not really a control people will keep working with.

Designing proportional enforcement

A good AI firewall should feel less like a panic button and more like a policy engine.

These actions aren't always mutually exclusive, either. Alert pairs fine with any of the other three: a block gets logged and alerted, a redaction triggers a review, a replacement gets flagged for follow-up. What doesn't make sense is stacking actions that contradict each other, like redacting something you've also decided to block.

Naming these four actions is the easy part. Applying them consistently, and picking the right one, across prompts, responses, retrieved context, multimodal inputs, applications, agents, tool calls, and AI-generated code, is where it gets hard.

That's where runtime control earns its place.