A security policy that blocks everything sounds safe until people start working around it. A policy that only logs everything sounds thorough until someone points out that logging a data leak after it happens isn’t the same as stopping it. Most AI security programs default to one of these two settings, and both defaults create their own kind of failure.
The better approach treats enforcement as a spectrum rather than a switch. Some activity should be recorded and left alone. Some activity should continue, minus the specific detail that makes it risky. Some activity should never happen at all. Getting that match right, case by case, is most of what separates a security posture people actually work alongside from one they quietly route around. None of the three responses is inherently more secure than the others. Each one is correct for a specific kind of situation and actively wrong for the other two, which is exactly why picking a single default for every case guarantees you’ll get it wrong some meaningful share of the time.
When audit is the right call
Audit fits situations worth knowing about that aren’t dangerous on their own. An employee tries a new AI writing tool for an internal draft. A developer tests a model against a sandbox dataset. Neither of these needs to be stopped in the moment, but both are worth a record, because the same tool might behave differently against production data next week, and having a trail matters when you eventually need to answer for what happened.
Auditing everything by default and calling it a security program is where a lot of efforts stall, because a log by itself doesn’t prevent anything. Its value only shows up later, during an investigation or a compliance review, which is exactly why it should be the default for low risk activity and never the only tool in use. Treating a complete log as equivalent to a complete security program is a comfortable place to stop, because it produces something to show leadership, but it leaves every actual risk in that log exactly as unaddressed as it was before anyone started watching.
When redaction is the right call
Redaction handles the far more common case: the activity itself is legitimate, but something inside it shouldn’t leave. A customer support agent pastes a full support ticket into an AI tool to draft a response, and that ticket happens to include a customer’s name, email address, and phone number. The underlying task, drafting a response, is exactly what the tool should be doing. The problem is narrower: specific identifiers riding along with it.
Stripping those details out before anything leaves, while letting the rest of the interaction continue normally, solves the actual problem without stopping legitimate work. This is usually the response that gets skipped, because it takes more configuration than a blanket allow or a blanket block, but it’s also the one that prevents the most real exposure without generating the friction that makes people find workarounds. Names, contact details, account numbers, and similar identifiers are the most common candidates, precisely because they show up constantly in otherwise ordinary work and rarely need to travel with the request they’re attached to.
When block is the right call
Block is for activity where the action itself, not a detail inside it, is the problem. An unapproved model handling a task that requires a specific compliance certification it doesn’t have. An agent attempting to access a data source outside its intended scope. A tool with no legitimate use case in a given workflow at all. None of these are made safer by redacting a detail. The activity itself needs to stop.
Reserving hard blocks for this category, rather than applying them broadly, is what keeps a security posture from training people to avoid it. Block everything by default, and the response to friction is rarely “follow the process.” It’s usually “find a tool that doesn’t ask permission.” A block used sparingly, on activity that clearly warrants it, reads as reasonable even to the person it stops. A block applied indiscriminately reads as an obstacle, and obstacles get routed around rather than respected.
Why the mix matters more than any single setting
None of these three responses does the whole job alone. A program built entirely on audit produces a detailed record of problems it never stopped. A program built entirely on block produces friction that pushes activity into channels with no oversight at all. A program built entirely on redaction assumes every risk is a data detail, when some risks are the activity itself.
The organizations that get this right treat audit, redaction, and block as three settings on the same policy engine rather than three separate tools, applied based on what a given interaction actually needs rather than a single rule applied everywhere. That consistency also has to hold across every layer AI shows up in, identity systems, browsers, devices, network traffic, APIs, applications, and code, because a policy that’s carefully tuned in one place and absent in another leaves exactly the gap someone will eventually find.
Building a policy that actually fits
Getting the mix right starts with resisting the urge to pick one default and apply it everywhere. It means looking at what’s actually happening in a given interaction, not just what tool it’s happening in, and asking whether the activity is worth recording, worth stripping a detail from, or worth stopping outright. That’s a harder question to answer once than “block everything,” but it’s the difference between a policy people work alongside and one they find ways around.
Security posture management is built around making that judgment consistent rather than manual, so the right response gets applied automatically instead of depending on whoever happens to configure a given tool.
Govern your AI activity with responses that actually fit the risk, not a single setting applied everywhere. Connect with our team about building a policy that knows the difference between a detail worth stripping and an action worth stopping.
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.