Behavioral observability: Keeping a record of what every agent does

AI agents now do real work across the business, from writing and shipping code to moving data between systems, often several steps at a time with no one checking each one. Most of the tools a company relies on to keep a record of what happens on its systems were built around people, so when something goes wrong with an agent, the question leadership asks first is often the hardest to answer: what did the agent do, and why?

A large consumer marketplace we work with faced that question during a live security incident. A developer’s AI coding assistant ran a routine software update and pulled in a malicious package linked to Shai Hulud, a self-replicating worm that steals developer credentials. The company’s existing security tools had no record of what the assistant had done, while Geordie did, so the team could see every step the agent took in the order it took them.

That record is what turns an incident from guesswork into an account leadership can stand behind with its board, its regulators and its customers. It also shows what normal looks like for each agent, so the next unusual step stands out on its own. Behavioral observability was built to give every agent that kind of record.

What: A record of every agent session, from the prompt to the last tool call

Geordie records agent sessions through runtime monitoring as an immutable activity, following an agent’s decision chain from its instructions and the user’s request to the tools it calls and the results it acts on. Every activity is tied to the agent, its owner and the person who started it, and holds:

• The request: the prompt or message that started the work
• The steps: all tool calls in order, with their inputs and results, including shell commands and file operations
• The execution environment: the model, the harness, the user and the agent’s configuration at that moment, along with the classification of any data involved, such as financial or personal data
• The risks: all detections placed at the step where they occurred, with the evidence behind them

An agent’s permissions and configuration show what it can do, and the activity record shows what it did. The same record also holds Beam matches, which we covered in the first post of this series. When a policy runs in runtime monitoring mode, each match lands in the activity record with the full session around it, so a team can see whether the policy is catching real risk or getting in the way of legitimate work before deciding to guide or enforce.

From this perspective, the activity record also answers questions beyond security. Teams are increasingly asked whether their agents are doing the work they were deployed for, how well they do it and whether that work is worth what it costs. As that understanding builds over time it lets a team give agents more responsibility as trust is earned.

"My leadership team approved these [AI platforms] because I could show what the agents were doing with Geordie. Not what the model was doing. Not what the network was logging. What the agent was actually doing, step by step."

How: The record comes from the agent and is kept outside it

Agents run on laptops, in the cloud and inside SaaS platforms. Geordie collects activity wherever each one runs: a lightweight endpoint sensor on developer machines for coding agents such as Claude Code, Cursor and Codex, and API integrations with each platform for cloud and SaaS agents.

Over time each agent’s sessions form a baseline: which tools it uses, in what order, how often and on whose behalf, set against the purpose Geordie infers from how the agent is built. That baseline matters most when every tool is approved, every permission is valid and something is still wrong. A sanctioned agent can start using its approved tools in a new sequence or reach resources outside its usual scope while its configuration stays the same, so inventories and gateways have no reason to raise it. Geordie flags that departure as a behavioral anomaly with the sessions that show what changed and whether the pattern is spreading to other agents, and a Beam policy can be applied from the same view.

Every record is kept in Geordie, outside the agent and the platform it runs on, where neither the agent nor its user can clear or rewrite it. Detections travel onward to Microsoft Sentinel and other SIEM and SOAR tools through workflows, webhooks and the API, while the full session stays searchable in Geordie for the investigation. Getting that signal into their own pipeline was the first thing the marketplace’s IR and SOC teams asked for once they started working with Geordie directly, and Geordie has since become a key data source for the company’s AI SOC initiative.

Why: The activity record differs from the logs a team already has

Most teams already collect plenty of data around their agents, but each source sits at its own boundary and sees only the part of the agent’s work that crosses it. The activity record differs from those sources in four ways:

• It looks inside the session. Endpoint tools record what happens on the machine. The activity record also shows what the agent thought and did.
• It’s tied to the agent. Much of a coding agent’s work happens inside its sandbox or harness and never reaches the network that gateway tools watch. The activity record follows the agent there, handoffs to other agents included.
• It knows what normal looks like. Each session is read against the agent’s own history, which no single log source keeps.
• It’s platform-agnostic. Platform logs cover only their own agents in their own format for as long as they keep them. Geordie keeps one record across all of them.

Geordie runs alongside the EDR, network controls and SIEM a team already has and adds the agent’s own account of the work to them.

Evaluation: Questions to ask about behavior observability, agent audit trail, and anomalies

Before an incident puts it to the test, we recommend asking these questions of any tool that claims to record agent activity, including the ones your team already runs:

• If a coding agent installed a package on a developer machine, could you see the session and the prompt behind it?
• Does the tool know what normal behavior looks like for each of your agents, or only what your rules say is wrong?
• If an approved agent with valid permissions started using its tools in a new way, which of your tools would notice?
• When one agent’s behavior changes, can you see whether other agents are changing in the same way?
• When a risk is detected, can you see the steps around it or only the alert?
• Which of your agent platforms keep session logs, for how long and who can clear them?

Teams that want to see the activity record on their own agents can get in touch.

References

1. CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem, September 23, 2025
2. Beam: Guiding agents as they work, with tiered escalation