Agent Security › Monitoring
A successful result doesn't mean every action was acceptable. What to record once an agent can act, how to watch the edge of its authority, and how to reconstruct what actually happened.
You give an AI agent a task. It searches several sources. Opens some files. Calls an API. Updates a record. Asks another agent for help. Sends a message. And finishes the job.
Everything appears to have worked. But what actually happened between the instruction and the result?
As AI moves from answering questions to taking actions, businesses need visibility into more than the final output. They need to know what their agents are actually doing. That is the job of AI agent monitoring.
AI agent monitoring is the process of observing and recording the important actions an AI agent takes while it works.
Depending on the agent and the systems it uses, that might include tasks started, systems accessed, tools called, records changed, external communications, approvals requested, permissions granted or denied, blocked actions, other agents contacted, money spent, errors, unusual behaviour, task completion and agent status.
The purpose isn't to watch every tiny movement an agent makes. It is to maintain enough visibility to answer a much more important question: what happened?
Traditional software can be complex, but much of its behaviour follows paths developers have explicitly programmed. Agents introduce greater flexibility. An agent can decide which tools to use, break a task into steps, respond to new information and change its approach when something doesn't work.
That's part of their value. But it also means the path between goal and result can become much harder to predict. Two successful runs may not necessarily follow exactly the same route. So checking only the final result doesn't always tell you enough. You also need visibility over the actions that produced it.
Imagine you ask an agent: "find the latest sales figures and prepare the management report." Twenty minutes later, the report appears. Correct figures. Correct format. Task complete. Success.
Except the agent tried the normal reporting system, couldn't access it, searched another shared drive, found a copy of the data, downloaded it, uploaded it to an external analysis tool, and used the result to produce the report.
The final answer may be completely correct. The process may still have broken your security policy. That's why agent monitoring needs to look beyond "did the agent finish the job?" and ask "how did it finish the job?"
Not every organisation needs the same level of monitoring. But there are several areas worth considering.
Every recorded action should tell you which agent performed it. Not "AI system updated customer record" but "Customer Support Agent 03 updated customer record." Ideally you should also know the agent ID, owner, purpose, status and relevant session or task. If multiple agents are operating, identity becomes essential. Otherwise logs quickly become a collection of anonymous AI actions.
Record what the agent was actually asked to accomplish, with the task, start time, agent, requester and status. This provides context for everything that follows. An action that makes perfect sense for one task may be completely inappropriate for another.
Which systems did the agent interact with: CRM, Google Drive, email, website, database, GitHub, accounting, an external API, another agent? This helps identify situations where an agent suddenly accesses something outside its normal working pattern.
Agents increasingly work through tools. Monitoring should record important tool activity: search web, read file, query CRM, update record, send email, execute code, create payment, publish page, delete file. From a business perspective, you want to understand which capabilities the agent actually used.
Tool use alone isn't always enough. You also need the action. CRM READ is very different from CRM DELETE. Gmail DRAFT is different from Gmail SEND. Monitoring should preserve those distinctions.
When an agent attempts an action, record what happened: ALLOW (had permission), DENY (did not), APPROVAL REQUIRED (reached an authority boundary). A completed action tells you something. A denied action can tell you something too.
For consequential actions, record what the agent requested, why, who approved it, when, and what happened afterwards. Instead of "AI paid invoice" you have "Finance Agent prepared £2,400 payment, approval requested from Finance Manager, approved 14:04, payment executed 14:05." Much more useful.
If an agent can communicate outside your organisation, consider monitoring the recipient, domain, channel, action, relevant approval and data classification. You don't necessarily need to store every piece of sensitive content, but you should know an external action happened.
One of the most important things to understand is where information goes. An agent might legitimately read confidential information. The security question changes when that information is sent, uploaded, copied, exported, published or passed to another system. Monitor both what the agent accessed and where information subsequently went.
If an agent can spend money, monitor it separately: transaction value, supplier, new supplier, daily spend, cumulative spend, refunds, API and compute costs, unexpected increases. A finance agent spending £40 may be normal. A research agent suddenly spending £4,000 probably isn't.
Multi-agent systems create another requirement. If Agent A asks Agent B to perform an action, record the requesting agent, receiving agent, requested action, authority used, result and data returned. Without it, an investigation may stop at "Finance Agent accessed the record" when the important fact is "Research Agent asked Finance Agent to access it."
Don't throw denied actions away. They can be some of your most useful security signals. If an agent tries Finance (denied), then Payroll (denied), then HR Drive (denied), none succeeded and technically your controls worked, but the behaviour still deserves attention. A good monitoring system records both what happened and what was attempted.
A single event can be meaningless. Patterns are often more useful. One denied request may be an innocent mistake. Twenty denied requests in two minutes is different. One API call may be normal. Five thousand calls may indicate a loop, a malfunction, an attack or unexpected behaviour. Monitoring should look for changes in behaviour over time.
Potential signals include repeated denied actions, accessing systems outside normal scope, unexpected external domains, unusual tool-call volume, sudden increases in API usage, unexpected spending, repeated attempts after rejection, unusual operating hours, unexpected agent-to-agent communication, long-running tasks, large data transfers, new recipients, attempts to use higher-risk tools and unexpected changes in authority.
The important word is unexpected. Not every unusual action is malicious. But unusual activity can tell you where to look.
One of the most useful ways to think about agent monitoring is: watch what happens at the edge of the agent's authority.
Imagine an agent's job normally involves READ CRM, READ Drive and SEARCH WEB. Most of those actions don't need your attention. But suddenly it requests SEND EMAIL. That is interesting. Or ACCESS FINANCE. Interesting. Or CREATE CREDENTIAL. Very interesting. Rather than drowning businesses in every routine action, monitoring can concentrate attention around boundaries.
There is little value in producing 20,000 agent events every day if nobody can understand them. Businesses need different levels of visibility: routine activity stored for audit with no notification; notable activity visible in a dashboard; unusual activity flagged for review; high-risk activity triggering an immediate alert; critical activity triggering a potential automatic pause and alert. This is much more useful than treating every tool call as an emergency.
The terms are often used interchangeably. There is a useful distinction. Monitoring asks: is anything happening that I need to know about? It watches known signals, actions and boundaries. Observability asks: can I reconstruct and understand what happened? It becomes particularly important during investigation.
Monitoring might tell you an agent attempted an unusual external action. Observability helps answer which task triggered it, which systems were involved, which agent initiated it, whether another agent was involved, what happened before and after, and whether anything left the organisation. Both matter.
When something goes wrong, one of the most useful things you can have is a simple timeline.
10:01 Research Agent started task. 10:03 CRM accessed, allowed. 10:04 customer record read, allowed. 10:07 external website accessed, allowed. 10:08 request to access Finance, denied. 10:08 second Finance request, denied. 10:09 Finance Agent contacted, blocked. 10:09 boundary anomaly detected. 10:10 agent paused.
That tells a human what happened extremely quickly.
There is an important distinction between operational visibility and trying to store every internal reasoning step produced by an AI model. Businesses need useful records of tasks, actions, tools, systems, permissions, approvals, results, errors and security events. They should be cautious about unnecessarily storing sensitive internal model reasoning or confidential information inside logs. Operational auditability should focus on what the agent did and what authorised it to do it. Not collecting everything simply because it might be technically possible.
Monitoring data can itself become sensitive. Logs may contain customer identifiers, system names, file paths, transaction details, API responses, internal URLs or error information. So agent monitoring needs its own security controls: access restrictions, retention periods, encryption, redaction, data minimisation, log integrity and separation between customers or users. The system designed to help investigate a data leak shouldn't become another source of one.
Agents can also create financial problems without touching a bank account. A looping agent might repeatedly call a model, search the web, invoke APIs, run code or call other agents. That can create unexpectedly high compute or API costs. Monitor token usage, model cost, tool cost, API calls, task duration, retries, agent-to-agent calls and spend limits. Unexpected cost can be a security or operational signal in its own right.
An alert needs an action. Depending on severity, that might be record, flag, notify, request approval, restrict tool, pause task, pause agent, revoke credentials, stop all agents, or escalate to security or management. The response should be defined before the incident occurs. Otherwise the alert simply tells you that something interesting happened.
Imagine monitoring detects that an agent has attempted to export customer data to three previously unseen external domains. A useful system shouldn't require someone to spend 45 minutes working out how to stop it. There should be a clear route to PAUSE AGENT and, for serious situations, REVOKE ACCESS. Monitoring tells you something is wrong. Containment stops it continuing.
A business may use one AI model today and another next year. The monitoring policy shouldn't disappear when the model changes. You still need to know who acted, what they accessed, what they did, whether it was authorised, what changed and what was blocked. This is another reason agent monitoring should increasingly exist at the control and execution layer, not only inside the model.
For every agent, ask:
If the answer to several of those is no, you may have an agent that can act faster than you can understand what it has done.
Monitoring is one of the core problems we're designing Agent Control to address: bringing together agent (who acted), task (what it was trying to achieve), system (where it went), action (what it attempted), authority (was it allowed), approval (did a person authorise it), result (what happened) and alert (was anything unusual).
Instead of checking separate dashboards across every agent platform and integration, businesses need a clearer operational view. The long-term goal is simple: one place to see what your agents are doing.
Agent Control is in build. Leave your email and we will let you know when it is ready.
Agent security starts before an agent acts: identity, permissions, authority, guardrails, approval. But it cannot end there. Once agents are operating in real businesses, we also need to know whether those controls are working in practice.
That means watching what agents do, what they attempt, where they go, what they change, who approves them, and where they push against their boundaries. Because there's an important difference between "we think this agent is operating safely" and "we can see that it is."