Agent Security › Observability
Your agent says the task completed successfully. Did it? The difference between agent-reported success and verified outcomes: silent failure, false success, checker failure and cascading failure.
Your AI agent reports: task completed successfully. Great. But did it?
Did it check every source? Did it update the database? Did the API call succeed? Did the file actually get created? Did the customer receive the email? Did the website really change? Did it quietly skip half the task? Did it encounter an error and work around it incorrectly? Or did it simply reach a point where it believed the job was finished?
This is one of the most frustrating realities of working with AI agents today. An agent can fail without obviously failing. Worse: it can fail and tell you it succeeded. So one of the most important questions in agent operations isn't "what did the agent say happened?" It's "what actually happened?" That's the AI agent observability problem.
AI agent observability is the ability to understand and reconstruct what an agent actually did while completing a task: what task it received, when it started, which systems it accessed, which tools it used, what actions it attempted, which succeeded, which failed, what was blocked, which other agents were involved, what approvals occurred, what changed, what output was produced, and whether the intended outcome actually happened.
Monitoring tells you something happened. Observability helps you answer what happened, how it happened, and whether it actually worked.
Traditional software often has relatively clear outcomes. Request: save record. System: 200 OK, record saved. Agent tasks can be much messier. Ask an agent to "research our five largest competitors, identify any significant product changes this week, update our competitor tracker and alert me if anything important happened", and it might check four competitors, fail to access one website, misunderstand another, update three records, decide nothing important happened, and return "task completed successfully". Technically, the workflow ran. Operationally, the task may have failed.
Workflow completed is not the same as job completed.
If an agent says "I updated the CRM", don't automatically treat that statement as proof. Check whether the CRM changed. If it says "I sent the email", verify the send event. If it says "I published the article", check the published URL. If it says "I backed up the database", verify that the backup exists and is usable. If it says "I checked all 50 records", verify the expected coverage. The agent's report is useful, but the agent's claim of success should be treated as another data point, not the source of truth.
Don't ask the agent whether it succeeded. Verify the outcome.
In practice, this changes how agent systems should be designed. Instead of TASK to AGENT to "DONE", you want something closer to TASK to AGENT to ACTION to SYSTEM to OBSERVABLE RESULT to VERIFICATION to COMPLETE. The agent saying "done" isn't the end of the workflow. Evidence is.
A dramatic AI security scenario might involve an agent deliberately circumventing controls. A much more ordinary scenario is that the agent simply doesn't do the job properly, and nobody notices. It might skip a step, miss a source, misread information, fail to call a tool, use stale information, time out, encounter an API error, misinterpret a result, update the wrong record, stop early, or believe an incomplete task is complete. No malicious behaviour required. Just imperfect automation.
Imagine an agent whose job is to check every customer support ticket for urgent complaints and escalate them. It processes 950 of 1,000 tickets and the workflow reports SUCCESS. What happened to the remaining 50? Perhaps nothing important. Perhaps one contained a serious customer issue. The question isn't only "did the agent do anything dangerous?" It's also "what did the agent fail to do?" Agent control needs visibility into absence as well as action.
An AI agent may not recognise that it has failed. It may produce a plausible explanation, a polished report, a completed checklist and a confident summary. The output can look much more convincing than the underlying work deserves. With traditional software, an error often looks like an error. With an AI agent, an error can look like a beautifully written success report.
Modern agents can browse, write code, query databases, modify files, send communications, call APIs, operate software, delegate tasks and interact with other agents. But capability doesn't guarantee judgement. An agent may be technically capable of changing 500 records while being unable to recognise that its interpretation of the task was wrong. It may be capable of sending thousands of emails while failing to recognise the unusual case where it should stop. It may be capable of fixing code while failing to realise that its fix broke something else.
Capability can exceed judgement. That's one reason agents need control even when nobody believes they're secretly plotting against us.
It's easy to frame agent security around malicious agents, compromised agents, prompt injection, attackers and agents escaping controls. Those risks matter. But there's another, much more immediate problem: unsupervised confidence. An agent doesn't have to be malicious to create a serious consequence. It can simply be wrong.
Give an unreliable agent no tools and it's annoying. Give it READ and it can misinform you. Give it CHANGE and it can alter your systems. Give it SEND and customers can see its mistakes. Give it SPEND and mistakes can cost money. Give it DELETE and mistakes can become difficult to reverse. The less reliable the agent, the more important its authority boundaries become.
Anyone who has run enough autonomous agents may recognise the feeling. You give each one a job. One wanders off halfway through. Another confidently brings back the wrong thing. One insists it has finished when it hasn't. Another hits an unexpected obstacle and gives up. So you create another agent to check the first agent. The checker says "everything looks fine". It isn't. Meanwhile, you're running between all of them trying to establish what actually happened.
The analogy isn't perfect. AI agents aren't children. But it illustrates something important. The reason you put a gate on the stairs isn't because you believe a toddler is malicious. It's because capability exceeds judgement. The solution isn't to stand in the middle continually shouting better instructions. You change the environment: which doors are open, what they can touch, where they can go, which actions require you, how you know when something happened, what proves the task succeeded, and how you stop something going wrong.
You don't control agents by watching every move. You control the environment they're allowed to operate in.
This sounds like an obvious solution. Agent A completes a task, Agent B checks Agent A, done. Except Agent B is also an agent. It can misunderstand, miss something, accept weak evidence, fail to inspect the real outcome, or simply agree with Agent A. Now you have Agent A: SUCCESS and Agent B: VERIFIED while the task is still wrong. Adding another model call doesn't automatically create independent verification.
Imagine Agent A says "I updated all 250 customer records." A weak checker asks Agent A "did you definitely update all 250 records?" A slightly better checker reads Agent A's report. A much better checker asks the CRM "how many records were actually changed?" and compares: expected 250, actual 247, difference 3. Now you have evidence. The checker isn't judging another agent's confidence. It's verifying reality.
Where possible, verify an agent's claim against the system where the consequence occurred. Agent claims email sent, verify the mail provider confirms the send. Agent claims database updated, verify the expected records changed. Agent claims website published, verify the production page contains the expected version. Agent claims backup completed, verify the backup exists, has the expected size and can be restored. Agent claims payment prepared, verify the payment system contains the correct pending transaction. Agent claims all sources checked, verify the expected source list against actual source activity. The closer verification gets to the real-world outcome, the stronger it becomes.
Imagine a publishing agent calls the CMS API, receives a success response and reports success. But the page isn't visible because deployment failed, the cache didn't clear, the wrong environment was updated, or publishing status remained draft. "API call succeeded" isn't necessarily the same as "page published successfully". Ask: what real-world condition proves this task actually worked? That should become part of the task design.
One of the best ways to improve observability is to define what success means before execution. Instead of "update our product database", define: "update the 312 records in Batch 142. On completion, all 312 must contain the new category field, no other fields should change, and a verification query must return 312 matching records." Now success is measurable, and the agent doesn't get to invent its own definition of "done".
Where possible, make success criteria machine-verifiable: record counts, checksums, database queries, file existence, API responses, published URLs, transaction IDs, timestamps, test results, status codes, system events, audit records, expected-versus-actual comparisons. These are stronger than "the agent says it completed the task".
Not everything can be verified mechanically. Some tasks are subjective: write a strong article, research whether an emerging market is interesting, identify the most important developments this week. There may be no simple pass or fail. In those cases, observability can still show which sources were accessed, how many were checked, which expected sources were missed, whether required steps occurred, which tools were used, whether another review happened and whether a human approved the final output. You may not be able to prove quality automatically, but you can verify that the expected process occurred.
Imagine a monitoring agent is supposed to check 20 websites every morning. It checks 18. Nothing technically crashes. The agent produces its report. The missing two sites are invisible unless you track expected coverage. So observability should sometimes compare expected versus observed: expected sites 20, checked 18, failed 1, skipped 1, report status INCOMPLETE, not SUCCESS.
Agent systems shouldn't always collapse outcomes into SUCCESS or FAILED. Useful statuses include SUCCESS (everything completed and verified), PARTIAL (some objectives completed), INCOMPLETE (expected coverage not achieved), BLOCKED (agent correctly stopped at a boundary), NEEDS REVIEW (outcome uncertain) and FAILED (task did not achieve the required result). That is much more informative than a green tick.
And a blocked task isn't necessarily a failed agent. If an agent reaches "human approval required" and stops, that's not failure, the security system worked. If an agent encounters confidential information outside its authority and stops and escalates, that's good behaviour. So observability should distinguish "agent couldn't complete the task because something broke" from "agent correctly stopped because it reached its authority boundary".
Now add multiple agents. Agent A produces incorrect information. Agent B trusts it. Agent C uses it. Agent D checks the final result poorly. The workflow reports SUCCESS. Nobody colluded. Nobody was hacked. Nobody went rogue. Each component simply performed imperfectly. This is cascading failure, and it may be one of the most important practical risks in multi-agent systems.
Suppose a Research Agent finds information, an Analysis Agent interprets it, a Writer Agent creates an article and a Fact-check Agent checks the article. The existence of the Fact-check Agent can create confidence. But did it check every factual claim? Did it use independent sources? Did it simply compare against the Research Agent's notes? Did it have web access? Did it encounter an error? Did it skip claims? Did it report success despite incomplete checking? You need observability for the checker too. A monitoring agent is still an agent.
There's an obvious trap: Agent A does the task, Agent B checks A, Agent C checks B, Agent D checks C. At some point you've created an expensive tower of unreliable supervision. Instead, move verification closer to objective evidence: system state, deterministic checks, permissions, tests, logs, limits, and human approval where justified. Not another agent for everything.
Where consequences matter, separate execution from verification. But independent verification doesn't necessarily mean another AI agent. It might mean an automated test, a database query, an API check, an external monitor, a transaction reconciliation, a human approval or an expected-state comparison. The strongest verifier is often the underlying system.
08:00:00 task scheduled. 08:00:05 expected targets loaded: 25. 08:04:12 target 17 failed, timeout. 08:04:46 retry failed. 08:04:48 agent continued. 08:06:21 target 25 completed. 08:06:23 coverage 24/25. 08:06:27 agent reported task complete. 08:06:28 verification detected missing target. 08:06:29 status INCOMPLETE, review required.
For consequential agents, consider recording the task, the agent, the owner, the start time, what should happen (expected), systems accessed, tools used, actions attempted, results, errors, blocks, approvals, delegation, output, evidence that proves completion, coverage (was everything expected actually attempted), cost and a final status (success, partial, incomplete, blocked, review or failed). That gives you a much richer picture than "agent ran at 08:00, SUCCESS".
Record everything and you may create millions of events nobody ever reads. The goal isn't to collect maximum data; it's to make important behaviour understandable. A good interface might show: normal (237 tasks completed and verified), needs attention (4 incomplete), blocked (2 stopped correctly at permission boundaries), failed (1 workflow error), unusual (1 agent attempted a system outside normal scope). Now a human knows where to look. And evidence should be attached to the task, so clicking "Competitor Monitor, 2 October" shows status PARTIAL, expected sources 25, checked 24, failed 1, agent report "no significant changes detected", verification "incomplete coverage, one source unavailable". Now you can decide whether the result is trustworthy.
Observability also helps answer security questions: why did Sales Agent access Finance? Why did Content Agent attempt DELETE? Why did Research Agent contact a new external domain? Why did Support Agent suddenly call another agent 400 times? Why did Finance Agent run at 3am? You don't need to assume malicious intent, but unusual behaviour deserves visibility. Watch what happens at the edge of the agent's authority.
Suppose an agent normally checks a backup, runs verification and records a result. One day it runs but never performs verification. No forbidden action occurred and the security log may look completely clean, but the absence matters. So useful observability considers missing steps, missing tools, missing sources, missing verification, missing approvals, unexpectedly short runs and unexpectedly low activity. Silence can be a signal.
Baselines help. Over time you may learn that Research Agent normally checks 30 to 40 sources, Finance Agent normally performs 10 to 20 actions, Support Agent normally contacts CRM and email, and Content Agent normally runs for 8 to 15 minutes. Then suddenly Research Agent checks 3 sources, Finance Agent performs 600 actions, Support Agent contacts an unfamiliar API, Content Agent completes in 14 seconds. None of these automatically proves something is wrong, but each deserves attention.
Agent failure can be expensive without creating an obvious security incident: an agent enters a retry loop, repeatedly calls an expensive model, launches unnecessary subagents, repeatedly queries an API, runs for eight hours, duplicates work, or fails and restarts indefinitely. Observability should include model usage, API usage, tool calls, runtime, retries, subagents and spend. Cost is another consequence.
Today you use one model, tomorrow another, next year something substantially more capable. Your basic operational questions remain: what task ran, which agent, what systems, what actions, what changed, what failed, what was blocked, what evidence proves success. Those questions don't depend on a particular model provider. Build observability around the work, not merely around the model. And you don't need an agent's private internal reasoning to do it. Focus on observable operational evidence: task, inputs where appropriate, tools, actions, permissions, approvals, system events, outputs, errors, delegation, results and verification.
These concepts fit together. Monitoring: is something happening that needs attention? Observability: can we understand what actually happened? Control: can we change what happens next? For example, monitoring flags that agent spending increased dramatically; observability reveals the agent entered a retry loop after a supplier API began failing; control pauses the task and disables the payment action. That's the complete loop.
DEFINE (what should happen) to AUTHORISE (what may the agent do) to OBSERVE (what actually happened) to VERIFY (did the intended outcome occur) to INTERVENE (does a human or system need to act) to LEARN (should the agent or boundary change). Then repeat.
This is where Agent Control becomes much more than an agent inventory. Imagine opening the dashboard and seeing 43 active agents, 1,284 tasks today, 1,241 verified successful, 18 partial, 9 incomplete, 7 blocked correctly, 5 failed, 4 needing review. Then, under "needs attention": Competitor Monitor expected 30 sources, checked 26, reported SUCCESS, verification INCOMPLETE; Backup Agent reported "backup complete", external verification found no new backup, status FAILED. That answers the question people running agents actually have: can I trust that my agents did their jobs today? And crucially, Agent Control itself shouldn't just ask "agent, did everything go okay?" and put a green tick on the dashboard. Where possible it should use observable events, system responses, independent checks, expected outcomes, permission events, activity logs, external verification and deterministic tests. The agent's own report can be included, but it shouldn't automatically be treated as truth, otherwise we've simply created another agent checking the agents.
Agent Control is in build. Leave your email and we will let you know when it is ready.
For each important agent, ask:
If the answer to many of those is no, you may know that your agents are running, but you don't necessarily know what they're doing.
We're not building agent observability because AI agents are secretly plotting against us. We're building it because they're imperfect. They miss things. They misunderstand. They stop early. They fail quietly. They confidently report success. And sometimes the agent checking the first agent fails too.
As agents gain access to increasingly consequential systems, those ordinary failures matter more. The solution isn't to manually supervise every agent forever. It's to build an environment where authority is bounded, actions are visible, outcomes are measurable, failures are detectable, claims can be verified, and humans are brought in when they're actually needed.
The most important question after an autonomous task isn't "did the agent say it finished?" It's "did the thing we wanted to happen actually happen?" That's the difference between running agents and controlling them.