Turn the Lights On Before You Start Blocking
Before blocking AI agent actions, turn the lights on. Learn why visibility, monitoring, and understanding normal agent behavior are crucial before enforcing policy

Before blocking AI agent actions, turn the lights on. Learn why visibility, monitoring, and understanding normal agent behavior are crucial before enforcing policy

It's all just a little bit of history repeating"....
When intrusion prevention systems (IPS) showed up on the network, nobody in their right mind flipped them straight into blocking mode. You ran them in monitor mode first. You watched. You learned what "normal" actually looked like on your network, because the diagram in the vendor slide deck and the traffic actually crossing your wire are two different things. Only after you'd built that picture did you start denying anything.
Web application firewalls (WAF) got the same treatment. Same reasoning: turn it on, watch what it flags, tune it, and only then let it start dropping requests. Skip that step and you find out the hard way that your own QA team's load tester looks exactly like an attacker to a WAF with no context. Production breaks. And a "security improvement" becomes the reason a CISO is explaining an outage to the CEO on a Friday afternoon.
That's not caution for its own sake. It's how you avoid a career limiting event.
We are in that moment again, with agents
AI agents are the newest control plane, and organizations are racing to put policy in front of them before they've done the one thing that made every previous control plane safe to trust: actually look at what's happening.
So what's different this time? Rate of adoption. IPS took years to become standard. WAFs took years too. Agentic workloads went from interesting demo to production dependency in a matter of months, at organizations already running dozens of agents doing real work against real systems. The muscle memory from the last two control plane rollouts still applies. There just isn't as much time to use it.
This isn't a blocking problem. It's a visibility problem.
Ask most security teams what their agents are actually doing right now (which systems they're touching, what permissions they're exercising, whether that agent calling the billing API this morning is expected behavior or a misconfigured workflow nobody remembers approving) and you'll get a shrug. Not because they don't care. Because nobody built the sensor yet.
That's the gap Ory Agent Security is built to close. We sit at the harness layer, the point where an agent's actions actually execute, and watch what happens there: every action, every call, every system touched. That position matters for a reason beyond visibility. Because we're already sitting at the point of execution, we're not just watching traffic go by the way an IPS watches packets on a wire. We can stop any action from executing at all. Monitor first, so you understand what normal looks like for your agents the same way you once had to learn what normal looked like for your network traffic. Only then do you get to decide, deliberately, which actions to allow and which to stop before they ever run.
Turn the lights on to inform policy
Here's the message I'd want every security leader to walk away with: turn the lights on before you act.
You cannot write good policy for a system you can't see. Every generation of security control has taught us that lesson the hard way, and agentic AI is not going to be the exception just because it's moving faster. The organizations that skip the analysis phase and go straight to blocking are going to relearn the WAF lesson, except this time the false positive might be an agent that was supposed to process a refund, or approve a deployment, or update a customer record, and now it just... can't.
What does doing this right actually look like?
We've run this playbook with IPS. We've run it with WAFs. We know it works, and we know what happens when you skip it.
Turn the lights on. Then decide what to block.