Why AI guardrails are not enough: the case for continuous agent monitoring

Most conversations about secure AI begin before deployment. Teams define approved data sources, limit tool access, add refusal rules, test representative cases, and require human approval for sensitive decisions. Those controls are necessary, but they answer only one question: how should the system work?

Production creates a second question: how will the organization know whether those controls continue to work across unfamiliar inputs, changing permissions, accumulated context, and thousands of decisions? An agent can remain inside its technical permissions and still make a poor decision. A human can click approve without conducting meaningful review. A workflow can drift gradually without producing one obvious failure.

This distinction is central to The Observability Gap in AI Agents: What to Fix Before Agents Scale, a new Partnership on AI report co-authored by Eric Mibuari, PhD and a multidisciplinary group of AI practitioners and researchers. The report evaluates what enterprises need to monitor and where leading agent frameworks still leave important telemetry gaps.

Testing cannot cover production reality

Traditional software testing works best when inputs and outcomes can be bounded. AI agents complicate that model. They interpret requests, select tools, retrieve information, delegate work, revise plans, and act in environments that change after testing is complete. The number of possible paths grows quickly.

Pre-deployment evaluation should therefore be treated as the beginning of assurance, not its conclusion. Runtime monitoring is what gives an organization a chance to identify behavior that a finite test suite did not anticipate.

Continuous monitoring is not a new operating model

Continuous agent monitoring extends an operating discipline Tabiri already knows through cybersecurity. In our work with CDP-MapSync, a network-sensor pilot grew into ongoing endpoint visibility, practical remediation, and human-governed investigation. The value came not from collecting every possible event, but from establishing a baseline, identifying meaningful deviations, assigning owners, and connecting alerts to action.

The operating principles transfer, but the signals do not map one for one. Cybersecurity monitoring focuses on systems, identities, vulnerabilities, and network or endpoint activity. Agent assurance must also examine what an agent was authorized to do, which tools and evidence shaped its action, whether delegation expanded its authority, how its behavior changed, and whether a person could intervene effectively. A security information and event management platform can contribute useful telemetry, but it is not, by itself, an agent assurance program.

Six questions a production monitoring program should answer

The report organizes enterprise monitoring needs around six goals. They provide a useful operating checklist for any team preparing to scale an agent.

Logs are not the same as assurance

A tool-call log can show that an agent opened a file. It cannot, by itself, show whether that agent was permitted to open the file for that case. A record of approval cannot show whether the reviewer had the right authority or whether approvals are becoming automatic. Telemetry becomes useful only when it is connected to organizational context.

That means joining agent activity to identity and access systems, tracing claims back to evidence, comparing outputs with policy or source material, and looking for patterns over time. The intent layer still belongs to the organization: policies, roles, deny lists, escalation rules, and definitions of unacceptable behavior must be explicit before monitoring can judge against them.

A record tells you what happened. Continuous assurance helps determine whether it should have happened and what to do next.

Human-in-the-loop needs its own monitoring

Human approval is often presented as the final safeguard, but the presence of an approval button does not prove meaningful oversight. Reviewers can become over-reliant on recommendations, approve too quickly, or lack the authority required for the decision.

Teams should be able to examine who reviewed a recommendation, what they decided, how long the review took, whether they sought more information, and how often they overrode the system. Those patterns help distinguish earned trust from rubber-stamping.

What organizations can do now

1. Start with one bounded workflow. Name the decisions, tools, data sources, handoffs, and people involved.
2. Work backward from failure. Identify the policy violations, unauthorized actions, oversight failures, and drift that would matter most.
3. Define identity and permissions. Give each agent a durable identity and make approval-mode changes visible.
4. Capture evidence proportionately. Use stronger records and alerts for high-impact, difficult-to-reverse actions; use lighter monitoring for routine work.
5. Connect signals to intervention. Assign owners, thresholds, escalation paths, and post-incident review before launch.

Do not confuse visible reasoning with reliable evidence

The report draws an important boundary between records of what an agent did and records of how a model reached its decision. Actions, permissions, memory changes, sources, and approvals are concrete operational records. Chain-of-thought summaries and confidence statements are less reliable and may not reflect the factors that actually drove the model.

For practical governance, organizations should begin with evidence they can verify: identity, authority, tool activity, source attribution, human intervention, and outcomes. Explainability claims should not outrun what the system can faithfully observe.