How to audit AI agent activity

Give an AI agent too many permissions on your systems, and sooner or later it does something nobody asked for. In a SailPoint survey of 353 IT professionals with enterprise security responsibilities, 80% said their organization’s AI agents had taken unintended actions like accessing unauthorized systems or resources and downloading sensitive content. When that happens, the question that reaches you is why, and “the agent decided to” won’t satisfy a client or an auditor.

AI agent observability is what lets you give a real answer. Here’s how you can audit your own AI agent activity and keep your organization audit-ready year-round.

» Make sure you know the differences between automation and Autonomous IT and if AI agents are actually autonomous

Why standard logs leave agent activity unexplained

The logging most environments already have was built for a world where a person or a fixed script made every decision and could tell you what happened. It answers who did what, where, and when.

An agent adds a step those records were never designed to hold. When it interprets a request and chooses an action autonomously, the choice is the part that goes unrecorded.

According to Dominique Locksley, Linux System Administrator at Adapt IT Holdings Limited:

What they didn’t have was a single audit record explaining why the agent decided those additional modifications were necessary, which instruction led to each change, or how those actions related to the authorized task. Git gave them excellent evidence of what changed, but not why the agent changed it.

The same gap shows up in operations. Windows Event Logs and API logs will confirm that a script executed on an endpoint or that an account was modified, but they won’t tell you which ticket, alert, or instruction led the agent there, what documentation it relied on, or whether anyone approved it.

System state can be reconstructed from those records. AI accountability can’t, because the decision that produced the state was never written down.

Why periodic log reviews come too late

In 2025, AWS disclosed that malicious code had shipped inside an official release of its Amazon Q Developer extension for VS Code. An inappropriately scoped GitHub token let a threat actor commit the code to the extension’s open-source repository, and it was automatically included in version 1.84.0. According to AWS, it failed to execute only because of a syntax error.

The entry point was an over-scoped credential, the same problem this article opened with. The malicious code then traveled through the vendor’s normal release process, so the distribution itself looked routine. The attacker’s own mistake was the only thing between distribution and execution.

An agent that has been hijacked through prompt injection or compromised upstream works at machine speed, using the credentials it was legitimately given. To an access log, that activity looks authorized, and a weekly log check only finds it days after the damage is already done.

What an auditable agent trail looks like

Closing the gap takes a different kind of record, plus a rule for how much of it a person has to read. The record has to carry the decision alongside the action.

A useful AI agent audit needs two layers of data:

1. Conventional operational telemetry: Timestamp, agent identity, authenticated user or service identity, target system, tool or API invoked, command or parameters, authorization result, execution status, and resulting system change. That establishes who did what, where, and when.
2. Context: This goes beyond ordinary access and execution logs, which comes down to four fields:

• Request context: A redacted record of the prompt, ticket, alert, or event that started the task, with credentials and unnecessary sensitive data excluded. If the unredacted request has to be kept for investigation or compliance, access to it should be separately controlled and audited.
• Decision context: The instructions, policies, retrieved documentation, and other information the agent used to choose its action.
• Authorization context: The agent’s assigned scope, whether approval was required, and the human approval record where it was.
• Action rationale and outcome: The agent’s recorded explanation for the action, backed by its inputs and tool evidence, plus the expected and verified result. This is an auditable explanation of the decision, not a window into the model’s private internal reasoning.

What turns these fields into AI agent observability is a shared correlation or trace ID on every record that links the request and the decision to the API calls, scripts, endpoint events, and system changes that followed.

Review depth set by risk

Routine actions should receive 100% automated telemetry coverage, while manual auditing should be determined by risk, not by a fixed sampling percentage. Routine and reversible actions are monitored automatically. Exceptions, policy violations, unusual behavior, and changes affecting sensitive systems move into manual review. Actions requiring human authorization receive 100% approval verification.

For example, take 1,000 agent actions in a month:

All 1,000 actions are covered by automated telemetry, and 100 of them (10%) reach a person. Change the mix and the percentage moves with it, which is why it works as an output of the model and not as a target.

Robin by Atera is an AI technician that resolves Tier-1 and complex Tier-2 technical incidents end to end, within guardrails your technicians define. Technicians describe a workflow in plain English, and Robin turns it into a structured Playbook that includes approval steps. As it works, Robin logs requests, actions, approvals, and outcomes, and it verifies the resolution before closing the incident.

When a request needs a technician, Robin escalates with the conversation history and a summary of the actions it performed, so the technician starts from the record and not from scratch. That covers the request, authorization, and outcome parts of the trail, and Step 4 shows how to corroborate it against records the agent doesn’t control.

» Don’t miss the best enterprise AI platforms for IT management

How to audit agent activity step by step

The trail gives you something to audit, but each audit task needs its own checks. The steps below cover the four you’ll run most often, from a routine sign-off review to reconstructing an incident.

Step 1: Verify sign-off and scope on high-impact actions

A sign-off audit checks each high-impact action against its approval record. That only works if the original request, agent identity, proposed action, approval requirement, approver identity, approval timestamp, execution timestamp, and resulting change all share one trace ID.

With those records linked, run the same sequence every audit period:

1. Pull every high-impact action for the audit period by trace ID, so the request, approval, and execution records come back together
2. Confirm that the approval timestamp comes before the execution timestamp
3. Confirm that the approver had authority for that type of action
4. Compare the executed action with the approved action, including the target, parameters, and resulting change
5. Compare the agent’s tool calls, target systems, and parameters with the scope of the authorized task. For example, approval to restart a server doesn’t authorize changes to its services, its firewall rules, or neighboring hosts

Any one of these three conditions fails the audit outright:

• Execution happened before approval
• The approver lacked authority
• What ran materially differed from what was approved

Step 2: Watch for a compromised or rogue agent while it runs

No single threshold proves an agent has been compromised, so infrastructure monitoring has to combine two kinds of signal. The first is a set of policy violations that call for a response the moment they happen:

Those rules catch an agent that steps outside its permissions. Spotting one that behaves strangely while staying inside them needs a baseline, measured while the task is still running so a runaway task gets caught before it finishes.

Token consumption is the clearest place to start. More specifically:

• Compare cumulative tokens for a running task with comparable tasks over a rolling 30-day baseline, and alert when usage exceeds the historical mean by three standard deviations
• Compare the tokens used in each five-minute window with historical five-minute windows for the same agent and workload to catch sudden bursts

The same baselining applies to tool-call frequency, retries, authorization failures, and outbound connections. Treat these rules as starting points to tune for each agent, not as universal standards.

Two more things to account for:

• Correlation is better than a single anomaly: Suppose an agent that normally uses 8,000 to 12,000 tokens per endpoint task suddenly consumes 31,000, calls a tool it has never used, and targets an external destination outside its allowlist. The token spike alone warrants investigation. Together with the unfamiliar tool call and the destination violation, it should raise a high-severity alert and stop execution until someone reviews it.
• Runtime signals can’t catch a compromise that ships inside the agent’s own software: After the Amazon Q Developer incident, AWS published the SHA-256 hash of the affected 1.84.0 release. Checking installed artifacts against a hash like that tells you whether a known-compromised release is present, but it doesn’t confirm that what you’re running is clean.

Step 3: Separate reasoning failures from execution errors

When an agent’s action breaks something, split the investigation into separate execution and decision timelines.

Start with the execution timeline

Follow these steps:

1. Pull the script’s exit code from the agent’s tool-execution record for that trace ID, or from whatever launched the script. A non-zero code means the script itself failed
2. Read the stdout and stderr output captured in the same record. Don’t stop at an exit code of 0 since a PowerShell script can write errors and still exit 0 if those errors were non-terminating, so look for error text and for signs the script only partly completed
3. On Windows endpoints, open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > PowerShell > Operational, then filter for Event ID 4104 in the execution window. If script block logging is enabled, this shows the exact code that ran, which you can compare with what the agent recorded executing
4. Check the System log for Service Control Manager Event ID 7036 in the same window to see which services stopped or started
5. On Linux endpoints, run journalctl –since “<start>” –until “<end>” using the execution window from the trace
6. Check the current state of the broken dependency, for example with Get-Service <name> on Windows or systemctl status <service> on Linux, and compare it with its last known-good state
7. Compare the parameters in the agent’s tool-call record with what the request actually asked for, including the target host, file paths, service names, and flags. Correct code run against the wrong target (or with the wrong flag) is a decision problem, not an execution error

If the script failed, you have an execution error. If it ran correctly but did the wrong thing, the problem sits upstream.

» Learn more about analyzing Windows Event Viewer logs

Then reconstruct the decision path

This starts from the request and moves through the context the agent retrieved, the tool it selected, the permissions it was presented with, the approval state, and the action that resulted.

Test for these three causes:

Note: Permissions need one more distinction. The agent’s reasoning is evidence, not authorization. If the agent claimed a permission that never existed, that is a reasoning failure. If the downstream system allowed an action it should have denied, that is an authorization-control failure.

Step 4: Corroborate the agent’s own trail

An agent’s trail is where an investigation starts, not where it ends. With Robin, the starting point is its logged requests, actions, approvals, and outcomes, plus the summary of performed actions it hands a technician on escalation:

1. Confirm the trail forms a complete chronological chain of original request, actions, required approvals, approver identity, execution timestamps, outcomes, and technician escalation
2. Review any recorded interpretation or proposed actions, where the trail includes them, as context for the decision
3. Flag any gap, any execution before approval, and any difference between what was authorized and what was executed
4. Establish whether the records can be altered, and who has permission to alter them
5. Confirm how long the records are retained
6. Check that the trail’s timestamps are synchronized with the systems under investigation
7. Pull independent evidence from endpoint, identity, API, cloud, network, and version-control logs
8. Normalize timestamps across the agent trail and those systems, then correlate records using transaction, request, session, or trace identifiers

Correlation tells you whether an endpoint event, API call, identity event, or configuration change actually corresponds to an action the agent recorded, or merely happened around the same time. The trail becomes trustworthy once records the agent doesn’t control back it up.

Accountability starts with a trail you can reconstruct

An AI agent stops being a black box when its trail lets you reconstruct the chain from request to verified outcome and that trail agrees with what your endpoint, identity, and network records say. Everything else in an IT governance audit, from approval checks to anomaly thresholds, exists to prove one of those two things.

For IT teams and MSPs, the end-user support queue is the practical place to begin. Robin, Atera’s Autonomous IT agent, works within the guardrails your technicians set, and its logged requests, actions, approvals, and outcomes give you a trail to check against your own endpoint and identity records.

» Try Atera for free