AI Agent Monitoring: What Every Agent Actually Did, With Proof (2026)

Your identity team can tell you that the Claude OAuth grant for Alice carries drive.readonly. Your DSPM tool can tell you that the Payroll folder she can reach holds 193 files with SSNs in them. Neither can tell you whether the agent opened a single one of those files on Tuesday, and if it did, where the contents went.

AI agent monitoring is the part of AI agent security that answers that question. It is the activity pillar. For every AI agent and AI-enabled automation in the company, it keeps a per-action record of what the agent actually did, which principal it acted as, which resource it touched, which sensitive data classes were involved and where the output was sent, with every line pointing back to the evidence that proves it.

This guide covers the rule that separates a credible activity record from a theory, the evidence sources available today and what each can and cannot prove, how monitoring differs from observability, the join to sensitive data, SIEM streaming, freshness and backfill, and the metrics that show the program is working. It also walks through the hardest case in the field: an agent that drove a human's browser session and left no trace of itself in the provider's API.

✨ How to monitor and audit AI agent activity: never infer "did" from "can"

Authorization answers what could happen. Audit and runtime telemetry answer what actually happened. They come from different sources, carry different confidence, and belong in different stores. You join them only through evidence, and you show the join.

Here is the shape of a single finding done correctly:

• Authorization. Claude OAuth grant → Alice → scope drive.readonly. Alice is a member of Finance. Finance has Reader on the Payroll folder.
• Activity. Google token audit: client_id=Claude called the Drive API on behalf of Alice at 10:04. Drive audit: Alice's identity viewed and exported payroll.xlsx.
• Data. Strac's inventory: payroll.xlsx contains SSNs and compensation data.

Three sources, one line on the timeline: 10:04, read payroll.xlsx [SSN, compensation], evidence: Google token audit + Drive audit, attribution: provider-native.

Programs that skip this rule fail in one of two directions. The first is reporting exposure as usage: every agent with reach to sensitive data shows up as if it had already read it, every dashboard turns red, and the team stops looking. The second looks like rigor and is worse. A tool sees a user-only Drive event a few seconds after an agent's token activity and credits the agent. It feels like correlation. It is a guess.

The discipline has to be applied event by event:

• A Drive event carrying Alice, the Claude client ID and the file is app-attributed. One carrying only Alice and the file is principal-attributed, and nearby token activity for Claude does not upgrade it.
• Two Bedrock AgentCore runtimes sharing one IAM role: a CloudTrail GetObject with sessionIssuer set to that role proves the role did it. Without a session or runtime trace, both runtimes stay candidates, and the event is never duplicated as a confirmed read by each.
• A Copilot agent session that opened a pull request in a repo where Strac found 17 active secrets wrote to a repo containing secrets. It did not "access a secret" until event, content or runtime evidence shows it.

The rule cuts the other way too. No observed use is not proof of no use. A granted-but-unexercised scope is a review candidate with a window and a telemetry caveat. When CloudTrail data events are off for a bucket, the honest activity state is "not configured," and no tool should claim "no sensitive reads" from silence.

✨ AI agent monitoring vs AI agent observability

AI agent observability is built for the team that ships the agent. It answers "is the agent working?" with traces and spans, token counts, latency, cost per run, tool-call success rates and eval scores. It is OpenTelemetry for LLM applications.

AI agent monitoring, in the security sense, is built for the team that has to answer for the data. It answers "what did this agent do with our data, as whom, and can I prove it?" The unit is the action: an identity performed an operation on a resource that contains certain data classes, and the result went somewhere.

Four reasons the engineering kind does not cover you:

1. It only sees agents you instrumented. The Zapier automation holding a live HubSpot token, the Agentforce bot a Salesforce admin enabled, and the Cowork session driving a user's browser are in nobody's tracing pipeline.
2. It identifies the run, not the principal. A trace knows the session ID, not that the session delegated through Alice's OAuth grant, so it cannot be joined to permissions or ACLs.
3. It has no idea what the data is. A span says "read file X." A security record says "read file X, which holds 8 SSNs and 4 secrets."
4. It is owned by the thing it would be auditing. The audit trail has to be independent of the team and code that run the agent.

You want both. Where a platform exposes hooks or OpenTelemetry, as Cursor does, that telemetry flows into the same graph as extra evidence, but the security record cannot depend on it. If you already do AI usage monitoring for employees using ChatGPT and Claude, agent monitoring is the same discipline applied to software that acts on its own.

The evidence sources, and what each one can and cannot prove

Every provider exposes some activity signal. None exposes enough on its own, and each has a specific blind spot. The rule we hold to: the UI must distinguish provider-attributed from Strac-correlated from inferred, and never present weak attribution as fact.

Each row maps to a confidence tier on the finding. GitHub's explicit agent fields are very high. A unique OAuth client ID or a dedicated workload role is high. A shared principal where the provider still supplies an app field, as Salesforce does with ConnectedAppID, is medium. A temporal, device and network correlation from the browser and endpoint sensors is low to medium, and it is labeled as correlated. Behavioral inference under a shared username and password is low until another sensor confirms it.

The source tiles at the top of the activity stream are the honest version of a coverage claim: they show how much of the record would vanish if a sensor were removed or a provider feed went dark.

✨ Worked example: who exported the Salesforce report?

Alice is logged into Salesforce in Chrome. A computer-use agent, in this case Cowork, takes control of that tab and exports a report. This is identity pattern E, the browser-session agent, and it is the case that breaks every API-only product.

Here is everything Salesforce knows: Event Monitoring records a ReportExport by Alice, 2,310 rows, no connected app, no bot ID, no session attribution. The provider is reporting accurately. No OAuth grant was created, no integration user exists, and nothing in the admin API can attribute the action to anything but her.

Here is what Strac's sensors saw in the same window:

1. The endpoint sensor observed the Cowork process take control of an existing Chrome tab.
2. The browser sensor recorded the agent's tool call, browser.click("Export"), in Alice's authenticated session.
3. A CSV was downloaded to the device, and endpoint file lineage shows the agent process reading it.
4. Outbound traffic from the agent process went to api.anthropic.com.

The correlation engine joins the two columns on three factors it displays on the finding: a 43-second overlap between the Salesforce event and the browser action, the same tab and account context, and the file lineage from download to agent read to external destination. The verdict is a High finding with attribution marked correlated, and the factors are shown so a reviewer who disagrees can say which one fails.

Two findings fall out of one event. The first is observed movement of 2,310 customer records out of Salesforce to an external destination through an agent that holds no identity of its own there. The second is a hygiene finding, a shared human session used by an agent, which is the reason AI agent identity governance recommends dedicated identities for anything that acts autonomously.

Without the sensors, the record reads "Alice exported a report." This is the same gap that lets shadow AI agents run for months: the agent still has to execute somewhere, and that somewhere is a browser or an endpoint you can see.

✨ Every activity line carries the data it touched

An activity stream that stops at "agent read file X" is a log. It becomes monitoring when the line also says what was in file X.

Strac normalizes every provider event into one shape: provider, timestamp, the agent or session if attributed, the principal and credential, the action mapped to a canonical category (read, write, delete, send, execute, admin, auth) with the provider's own action name kept verbatim, the resources involved, the destination, the attribution confidence and a pointer to the immutable raw evidence. The resource ID is the join key into the sensitive-data inventory Strac already maintains across Drive, S3, GitHub, Slack and Salesforce. So "Drive audit: Alice viewed fileId 1aB3…" becomes "Read payroll.xlsx [SSN, compensation]."

Three rules keep that join honest:

• A successful read of a classified resource supports "read a resource classified as sensitive." It does not by itself support "read 8 SSNs." The classification is context, and the finding says so.
• "Sent sensitive data externally" requires payload or lineage evidence and a demonstrated destination. An agent being connected to a system is not exfiltration. The Salesforce example qualifies because the sensors captured file lineage and the outbound destination. A Drive read with no onward evidence does not.
• Current classifications cannot prove past content. If a file was reclassified after the event, the historical read is labeled as touching a currently classified resource, unless the object version or a valid classification interval matches the event time.

With the join in place, the monitoring layer produces the findings about what happened rather than what could:

Severity is deterministic and the factors are on the finding: sensitivity, action capability, breadth, sanctioning, observed use, attribution confidence.

Monitoring also feeds the controls in protect AI agents. Granted-versus-used is a monitoring output. So is the decision to drop gmail.readonly after 30 days of silence, and so is redacting a secret inside an MCP tool response before it reaches the model, the data-layer control covered in MCP DLP.

✨ Streaming AI agent activity to your SIEM

Your SOC lives in the SIEM, your human identity events are already there, and your retention policy is enforced there. Agent activity belongs in the same place, in a shape the SOC can correlate against login events, DLP alerts and endpoint telemetry. A useful agent event, when it lands in Splunk, Sentinel or Datadog, carries:

• The normalized fields above: agent, session, principal, credential type, canonical action plus the provider's verbatim action, resource IDs, destination, success flag.
• The evidence source and attribution confidence, so a detection rule can treat a provider-native event differently from a correlated one.
• The sensitive data classes touched, as classes and counts: "PII: 2,310 rows," never the rows.
• A stable dedupe key from the provider's event ID, or a hash of provider, account, actor, action, resource and source timestamp when the provider supplies none.

Prompts and content do not go to the SIEM by default. Metadata answers almost every monitoring question, and content ingestion, where you need it, follows the controls you already apply to AI DLP.

Route Critical findings, meaning observed sensitive data sent to an external destination or an observed secret read on a principal that can also execute, to the pager. Route High to the queue with the owner attached. And treat a change in coverage state as an alert in its own right: a connector flipping to not_authorized or an audit feed going quiet is bad news, because silence looks exactly like safety.

If you are weighing API feeds against deployed sensors, agent vs agentless monitoring covers the tradeoff. API feeds give you identity patterns A through D with provider-native confidence; sensors are the only way to get patterns E and F at all.

Retention, freshness and backfill

A monitoring feed is only as trustworthy as its gaps are visible. The cadences Strac runs: inventory and permissions refresh every 6 to 24 hours plus change events, activity polled every 1 to 5 minutes or streamed where the provider supports it, and vendor feeds ingested continuously. The provider side sets hard limits. OpenAI's compliance logs are retained at the source for 30 days, so they must be ingested before expiry. Anthropic's activity feed is cursor-driven, queryable within about a minute and retained long-term after enablement. GitHub's enterprise web audit keeps 180 days, and Git event retention is shorter.

The engineering rules behind those cadences are the ones to ask any vendor about:

• At-least-once ingestion, idempotent normalization. Every event stores its source event ID or a deterministic hash plus the source timestamp, and dedupe happens during normalization. Ingestion time is never part of the key.
• Checkpoints per tenant and connector, advanced only after durable commit. A crash between fetch and commit replays the batch; it never skips a cursor past uncommitted data.
• Inventory before activity. Backfill principals and resources first so the joins exist when events arrive. If activity shows up first, it is kept with unresolved references and repaired after the inventory sync. The system never invents an ID to close the gap.
• Overlap windows sized to measured provider delay, with dedupe absorbing the repeats.
• A failed page or revoked collector scope never deletes identities or closes findings. Objects are marked absent only after a complete snapshot of the same visibility scope.
• Gaps are reported, never smoothed. Source lag and collector lag are shown separately because they have different owners. If a provider expired events before ingestion, the hole is on the record.

The provider's retention is not your retention. Keep the normalized event and its sanitized evidence as long as your control frameworks require, which is well past 30 days.

📊 AI agent monitoring metrics that show it is working

Most agent monitoring dashboards show event counts, which measure volume. These measure whether the record can be trusted:

• Coverage by source. For every connector, the activity capability state (complete, partial, unsupported, not authorized, not configured) and the covered window. Events by evidence source, as in the stream above: 4,812 provider audit, 1,140 compliance APIs, 633 MCP tool calls, 2,207 browser and endpoint.
• Correlated attributions. The count of actions that have an agent attached only because a Strac sensor correlated them (38 in the example). This is how many agents exist for your organization that do not exist for your providers. Track direct versus correlated as a ratio.
• Share of activity with agent attribution. Rising principal-only volume from a known AI client ID means a provider's audit fields changed or a sensor went quiet.
• Unresolved joins and lag. Events waiting on an inventory record should trend to zero after every backfill. Source lag and collector lag, per feed.
• Sensitive data touched, by class: 5,273 PII records, 31 PCI, 4 secrets, 2 repositories, 1 sent externally. The last number should be rare enough to investigate individually.
• Time from observed Critical to remediation. Teams get this from over nine days to about two by attaching the owner at finding creation rather than at triage.

The first two are also your honest answer when an auditor asks how you know the inventory is complete. You do not. You know what fraction rests on which evidence, and where the holes are.

How Strac monitors AI agents

Monitoring is one of the three operating practices in an AI agent governance program, alongside discovering agents and protecting them. Strac runs all three on one graph, and the activity layer works like this:

• Collect from every source listed above, with each connector publishing a capability manifest saying what it can and cannot see for your tenant.
• Normalize into one timeline with the canonical action taxonomy, the provider action kept verbatim, and a pointer to immutable raw evidence on every line. Secrets, cookies and bearer tokens are redacted before anything is persisted.
• Attribute with explicit confidence. Provider-native where the provider names the agent or client. Correlated where the sensors supply the join. Inferred, and labeled as such, where only behavior supports it.
• Join every action to the sensitive data it touched, using the classified inventory Strac already maintains for DLP and DSPM, and produce findings about what happened with the six severity factors visible and remediation that is read-only by default and opt-in per provider.
• Stream to your SIEM with evidence source, confidence, data classes and a stable dedupe key on every event.

Deploy it read-only against the provider APIs in an afternoon. Add the sensors where you need patterns E and F attributed. The first activity report usually contains at least one agent nobody knew was running.

👉 Book a demo and we will connect your Google Workspace token and Drive audit feeds read-only on the call and show you the last seven days of AI agent activity, tagged by evidence source and sensitive data class.

🌶️ Spicy FAQs on AI agent monitoring

What is AI agent monitoring?

AI agent monitoring is the continuous collection of what every AI agent and AI-enabled automation actually did: which identity it acted as, which action it took, which resource it touched, which sensitive data classes were involved, and where the output went. It is the activity pillar of AI agent security, built from provider audit logs, AI vendor compliance APIs and endpoint, browser and MCP sensors. It is distinct from authorization, which only says what an agent could do.

What is the difference between AI agent monitoring and AI agent observability?

Observability is an engineering discipline: traces, latency, token cost and tool-call success, instrumented by the team that built the agent. Monitoring is a security discipline: an independent record of who or what acted, as which principal, on which data, with what result. Observability only covers agents you instrumented and never knows what the data was.

What should an AI agent audit trail contain?

Every line should carry the agent or session, the principal and credential type, the canonical action plus the provider's verbatim action, the resources touched, the destination, the sensitive data classes involved, the evidence source, the attribution confidence and a reference to the immutable raw evidence. It should not contain prompts or content by default.

Can you monitor AI agents without installing anything on endpoints or browsers?

Partly. Provider APIs and audit logs cover agents that use delegated OAuth, their own app or bot identity, a cloud workload identity, or an API key, which is the majority in most environments. They cannot see an agent that drives a human's existing browser session or signs in with a shared login, because the provider records the human. For those two patterns, endpoint and browser evidence is the only way to attribute the action.

Do you need to log prompts to monitor AI agents?

No. Almost every security question about an agent is answered by metadata: which identity, which action, which resource, which data classes, which destination. Strac collects content only where the customer's policy allows it and through the same controls that govern DLP, and a finding records the data classes detected rather than the content.

How do you monitor an agent that uses a shared login?

The provider's audit log will show the shared account, and a monitoring tool should never manufacture a direct agent link from that alone. If endpoint, browser or MCP evidence exists, Strac creates a correlated attribution with lower confidence and shows the factors behind it. Either way it raises a hygiene finding, "shared human credential used by an agent," because the right fix is a dedicated identity.