Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: AI agent security cannot safely start with deny rules, according to Ory, because teams still lack the visibility needed to distinguish normal behaviour from misconfigured or risky actions. The policy lesson is to observe first, then enforce, because existing review and blocking models assume stable, well-understood execution patterns that autonomous systems do not provide.
NHIMG editorial — based on content published by Ory: Turn the Lights On Before You Start Blocking Before blocking AI agent actions, turn the lights on
Questions worth separating out
Q: How should security teams govern AI agents before they start blocking actions?
A: They should begin with observation-only controls, capture action-level telemetry, and build a baseline of normal behaviour before enforcing deny rules.
Q: Why do AI agent controls fail when teams skip the monitoring phase?
A: They fail because security teams cannot reliably tell whether an action is legitimate, misconfigured, or risky without runtime evidence.
Q: What are the signs that AI agent policy is too aggressive?
A: Common signs include blocked business workflows, repeated false positives, and frequent exceptions that operators have to manually override.
Practitioner guidance
- Run agents in observation mode first Start with monitoring-only enforcement so you can capture which systems each agent touches, which permissions it exercises, and which actions are routine before you deny anything.
- Build a runtime behaviour baseline Collect action-level telemetry from the execution layer and use it to distinguish expected workflows from misconfigured or stale agent behaviour.
- Separate policy design from policy enforcement Write deny rules only after you have observed enough agent activity to understand legitimate variation, exception cases, and business-critical actions.
What's in the full article
Ory's full analysis covers the operational detail this post intentionally leaves for the source:
- How the harness layer observes agent actions before they execute and how that differs from ordinary logging.
- Why monitor mode is used to build an agent behaviour baseline before any deny policy is activated.
- How execution-point visibility supports later policy decisions, exception handling, and workflow tuning.
- What the control model means for teams running multiple agents against real systems at production pace.
👉 Read Ory's analysis of why AI agent blocking should start with visibility →
AI agent controls: why visibility has to come before blocking?
Explore further
14/09/2026 10:10 am
Turn-the-lights-on-before-blocking is the right model for agent governance: policy enforcement without runtime visibility recreates the same failure that broke early IPS and WAF rollouts. The article is correct that teams need observation before denial, because the control problem is not refusal but interpretation. For practitioners, that means the governance order matters as much as the policy itself.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Should organisations treat AI agent governance as a one-time rollout or an ongoing programme?
A: It should be treated as an ongoing programme, because agent workflows change as integrations, permissions, and tasks evolve. A baseline that worked in one quarter may not hold after a workflow update or new system connection. Continuous review is what keeps monitor mode useful after the first policy cycle.
👉 Read our full editorial: AI agent blocking without visibility creates false positive risk
