AI agent blocking without visibility creates false positive risk

At a glance

What this is: This is an analysis arguing that AI agent policy enforcement should begin in monitor mode, because teams need visibility into real agent behaviour before they can safely block actions.

Why it matters: It matters because IAM, PAM, and governance teams cannot set reliable controls for agents until they know which systems the agents touch, what permissions they use, and which actions are normal.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Ory's analysis of why AI agent blocking should start with visibility

Context

AI agent control is not just a policy problem. It is a visibility problem, because blocking decisions are only reliable when security teams can see what an agent actually does, which systems it touches, and which actions are normal for that workflow. The first mistake many programmes make is treating agent enforcement like a static access rule instead of an evolving execution pattern.

The article frames this as a lesson learned from earlier control planes such as IPS and WAF, where monitor mode came before blocking mode for a reason. That same sequence applies to agentic AI governance, especially where agents are already reaching production systems and exercising permissions faster than teams can document them.

For identity programmes, the key issue is not whether an agent can be denied. It is whether the team has enough runtime evidence to know what should be denied without breaking legitimate work. That is typical of early control-plane adoption, and the article says the same pattern now applies to AI agents.

Key questions

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. That sequence reduces false positives and prevents policy from being written against assumptions instead of evidence. Once the baseline is stable, teams can harden policy around observed workflows rather than generic templates.

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. A policy built in the dark will over-block normal work or miss unusual behaviour. Monitoring provides the context needed to separate expected execution from dangerous drift.

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. Those symptoms usually mean the team enforced policy before it understood normal behaviour. If the control cannot distinguish routine actions from outliers, the baseline is not mature enough for blocking.

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.

Technical breakdown

Why monitor mode comes before blocking in agent security

Monitor mode is the stage where a control observes actions without preventing them, so defenders can build a baseline of normal behaviour. In agent security, that baseline has to include action calls, system targets, permission use, and workflow context. Without it, a deny rule is blind to legitimate variation and creates avoidable outages. This is the same operating logic that made IPS and WAF deployments safer: learn first, enforce second. The difference with agents is speed, because agentic workflows can reach production before teams have the monitoring layer mature.

Practical implication: run agent controls in observation mode first and derive policy from actual execution data.

Agent harness telemetry and runtime visibility

A harness layer sits where the agent executes actions, which gives security teams a chance to see each call before it completes. That is different from log-only monitoring after the fact, because runtime visibility can connect intent, permission, and outcome in the same control point. For IAM and governance teams, this matters because permissions alone do not explain whether an action was expected, risky, or simply misconfigured. In practice, this is the difference between writing policy from theory and writing policy from observed behaviour.

Practical implication: instrument the execution layer so every agent action can be inspected before policy hardening.

Why agent behaviour cannot be governed like static application access

Static applications tend to have predictable access patterns, but agents can vary their action sequence as workflows change. That makes them harder to classify from documentation alone, because the real governance problem is runtime behaviour, not declared purpose. If teams assume the agent will always operate the same way, they will miss drift, misconfiguration, and permission creep. This is why agent governance belongs in the NHI conversation: the identity may be non-human, but the control problem is still about access scope, execution context, and accountability.

Practical implication: treat agent behaviour as a moving control surface and re-baseline it whenever workflows change.

NHI Mgmt Group analysis

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.

Agent security exposes a runtime visibility gap, not just an access control gap: teams often know that an agent has credentials, but not whether the credential use is normal, excessive, or misaligned with the workflow. That is a distinct identity problem because access grants tell you what an agent can do, while telemetry tells you what it actually did. The implication is that monitoring must become part of the identity control surface, not a separate afterthought.

Runtime behaviour baseline: the new control concept here is not simply blocking, but establishing a defensible baseline of agent actions before enforcement begins. That baseline becomes the evidence layer for policy, incident review, and exception handling. Without it, every deny rule is a guess about what normal looks like, and guesses are a poor foundation for autonomous access governance.

Agent governance now sits between NHI and autonomous control concerns: even when the article does not describe fully autonomous decision-making, it shows why non-human execution must be governed as live runtime behaviour rather than static entitlement. That bridges classic NHI controls with the emerging agentic AI problem. Practitioners should treat this as an extension of identity governance, not a separate security silo.

From our research:

• 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.
• That gap makes OWASP Agentic AI Top 10 and NIST AI Risk Management Framework useful next reference points for policy and runtime governance.

What this signals

The practical signal for security programmes is that agent governance now has to be treated as a visibility-first discipline, not a policy-first exercise. Teams that try to harden first will keep discovering that they have no defensible baseline for allow, deny, or exception handling. The article's logic mirrors earlier control-plane rollouts, but the time available to learn is much shorter.

Runtime behaviour baseline: the identity control surface for agents now includes telemetry, not just entitlements. That means IAM, PAM, and NHI teams need shared ownership of how actions are observed, classified, and later enforced.

When an organisation cannot show which agent touched which system, the programme is already behind. The strongest next step is to pair monitoring with identity governance artefacts, then align the rollout to an external model such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

For practitioners

• 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.
• Keep the control plane under continuous review Treat agent governance as an ongoing programme because workflows evolve and the behaviour baseline will drift as integrations, permissions, and task scope change.

Key takeaways

• Agent policy fails when teams enforce before they observe, because runtime behaviour is the evidence needed to distinguish normal actions from risky ones.
• The scale problem is already visible in industry research, with AI governance widely viewed as critical but policy implementation still lagging behind.
• Practitioners should treat monitor mode, telemetry, and behaviour baselining as the precondition for safe blocking in agentic environments.

Key terms

• Monitor Mode: A transitional operating state in which actions are observed and recorded but not blocked. It is useful for discovering real agent behaviour, but it is not a production control because it does not prevent the action or limit the side effect.
• Runtime Behaviour Baseline: The expected pattern of activity for an identity while it is operating in production. It goes beyond entitlement lists by comparing actual actions, timing, and access paths, which is critical when valid credentials can still be abused.
• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Policy Enforcement Sequencing: The order in which a security team observes, tunes, and then blocks behaviour. Sequencing matters in agent security because premature enforcement can break legitimate workflows, while delayed enforcement can leave risky actions unchecked.

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.

👉 Ory's full post covers the monitor-first approach, runtime observation, and the policy logic behind safe blocking.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.