Agent performed the wrong action: How to reconstruct the incident with logs, authorizations, and final state

When an agent sends the wrong email, alters a file, changes a permission, or performs an unexpected operation on a repository, just saving the conversation doesn't answer the most important questions about the incident. You need to find out who started the execution, what the agent tried to do, which calls were actually executed, what authorization was valid, and what state changed in the external system.

This approach is consistent with NIST guidance for post-deployment monitoring of AI systems, incident response and recovery, and post-deployment reviews. NIST's Generative AI Profile also recommends defining responsibilities for monitoring incidents, conducting after-action reviews, and maintaining relevant records retention policies.

Not every wrong action by an agent is, by definition, a security incident. It could be an orchestration bug, misinterpretation, poor policy, or operational failure. But, when there is a relevant impact, reconstruction must follow forensic principles: determining the sequence of events, preserving data and metadata, recording the actions taken during the investigation, and maintaining the integrity and provenance of these records. NIST SP 800-61 Rev. 3, published in April 2025, addresses these points explicitly in incident analysis.

The incident needs to be reconstructed as a causal chain

The error should not be investigated as a single log line. In an agent with access to Drive, email, GitHub, or other services, different components see different parts of the execution.

A practical way to organize the investigation is to reconstruct the chain request → agent execution → tool call → authorization → provider operation → resulting state. This framework is an operational synthesis: observability standards already distinguish agent calls and tool executions, while external providers maintain their own activity and authorization trails.

The distinction is important because a tool call does not alone prove that there was an external change. Likewise, possessing a token with a certain scope does not prove that a specific operation was authorized by all intermediate policies.

What to preserve once the wrongful action is discovered

If the incident is still producing harm, containment and preservation of evidence need to be coordinated. NIST notes that response strategies may involve a balance between deeper investigation and rapid recovery; You shouldn't keep a dangerous run active just to get a more perfect track.

A useful order is:

1. Stop further inappropriate actions when necessary and open a unique identifier for the incident. Record the time of detection and who initiated the response.
2. Preserve existing records in their original form. Export execution logs, traces, authorization events, and audits from external systems before retention policies delete relevant data.
3. Capture correlation identifiers. Trace ID, span ID, run ID, tool call ID, request ID, and resource identifiers allow you to link events recorded by different components.
4. Preserve the configuration that was currently valid. This may include agent version, workflow, tooling, authorization policy, and policy review used in the decision.
5. Collect evidence on target systems. Don't limit yourself to what the agent said they did; look for the operation in the audit trail of the service that received the call.
6. Separately record the state just after the incident and the current state. Another person or automation may have modified the same resource later.
7. Document your own investigation. Who collected each record, when, where, and what transformations were made are also part of the evidence.

SP 800-61 Rev. 3 recommends that actions taken during the investigation be recorded, that the integrity and provenance of these records be preserved, and that incident data and metadata be collected and retained in accordance with the organization's preservation and retention procedures.

How to determine who requested the action

“Who asked?” can have three different answers.

The first is the task initiator: the person, service, event or automation that originated the execution. The second is the agent or process that decided to call the tool. The third is the identity presented to the external service, which can be a delegated user, service account, OAuth application, or other principal.

Mixing these identities can lead to the wrong conclusion. If the provider log shows a technical account, it does not necessarily mean that that account originated the intent. It may simply have been the identity used to execute a request previously initiated by another person or system.

Therefore, the identifier of an execution needs to follow the chain as far as technically possible. External registries can also help. The Google Workspace Reports API, for example, includes actor fields and information about OAuth applications in its activity logs; GitHub's audit log can record actor, action, time and, depending on the event, information about the form of authentication used.

The objective is not to choose a single “culprit” in the log, but to answer precisely: who started it, who executed it and with what identity the operation reached its destination.

How to prove what the agent called

The agent observability layer must record the execution of the tool regardless of the conversation displayed to the user.

OpenTelemetry's current GenAI conventions, still classified as Development, define a specific span for tool execution. In the convention consulted, gen_ai.operation.name and gen_ai.tool.name are central elements; a caller ID can be registered when available, while arguments and results are opt-in fields.

This provides a useful template for a technical track:

agent execution → tool name → call ID → parameters → result or error.

There is, however, an important restriction. OpenTelemetry's own conventions warn that instructions, messages, arguments and tool results may contain sensitive information. Instrumenting everything indiscriminately can turn the observability system into a new repository of credentials, personal data or confidential content.

The solution is not to abandon useful parameters for investigation, but to define in advance what will be recorded, masked, truncated or deleted. Secrets and tokens do not need to be stored in open text for a call to be correlated.

It is also necessary to differentiate tool result from proven effect. A successful response may indicate that an API accepted the request, but confirmation of the status must come from the system responsible for the resource whenever this is relevant to the incident.

How to prove what was authorized

This is one of the easiest parts to reconstruct incompletely.

There are at least three different levels of authorization:

The available grant or credential. Shows the capability that an application has received. In Google Workspace, for example, OAuth records can show authorization, deny, and revocation events, as well as associated scopes.

The policy decision for that operation. In architectures that use an external authorization mechanism, the ideal is to retain a correlatable decision. The Open Policy Agent, for example, offers decision logs that can contain decision_id, trace_id, policy bundle revision, input provided to the policy, decision result, and time.

The target system's decision. Even if the application has a token and an intermediate policy returns “allowed”, the final API can still accept, reject, or handle the request differently.

This separation avoids a recurring error: stating that “the action was authorized” just because the token had a broad scope. The scope helps explain the capacity limit of that credential; the investigation of the specific operation also needs to verify the decision applied at that moment and the target's response.

A truly useful authorization record should allow you to answer: which principal requested access, to which resource and operation, using which policy, which policy version, which decision was made, and which execution originated the query.

The external provider is the reference to know if the action happened

After identifying the agent call, look for the same operation on the connected system.

In Google Drive, the Drive Activity API provides activity history with elements such as action, actor, target, and time. The documentation also warns that not all activity will necessarily be visible to every authenticated user: visibility may depend on permissions on the object. Therefore, absence from a specific query should not automatically be interpreted as proof that the action never occurred.

For managed Google Workspace environments, Drive Activity Report can provide event creation, editing, sharing, and other activities and documents a query window of up to 180 days.

In GitHub Enterprise Cloud, the org audit log records activities that affect the org and can include actor, action, repository, time, authentication method, and other fields depending on the event. The documentation consulted reports a retention of 180 days for the organization's general trail, while Git events have specific conditions and retention of only seven days for certain accesses to the audit log.

These deadlines show why collection should not be delayed. The useful investigation window may be shorter than the team expects, and policies or products may change. Retention, licensing and availability of certain events must be verified with the provider used at the time of the incident.

The end state requires more than finding a success event

Find the operation in the audit log responds “a change happened”. It still remains to answer “what was the relevant result?”.

To do this, separate four points in time:

• the last known state before the operation;
• the change event attributed to the investigated execution;
• the state observed immediately afterwards, when there is a record;
• the current state.

This separation avoids assigning the agent a later change made by a person, webhook, workflow or second agent.

Imagine a case in which a repository maintenance agent tries to change a configuration. The trace confirms the tool call; the authorization decision confirms that that request was permitted; the audit log confirms a change to the repository; hours later, an administrator modifies the configuration again. The current state no longer represents, on its own, the original effect of the agent.

When the system provides versioning, change history, event IDs, or resource revisions, these references can increase rebuild confidence. When the previous state cannot be recovered, the report should say so explicitly rather than reconstructing it by assumption.

Assemble the chronology by evidence, not by the agent's narrative

The incident report should order events by normalized timestamps and use identifiers to link them.

A hypothetical sequence could show that the task was started in an authenticated session, that a specific execution of the agent generated a tool call, that a policy returned permission, that the provider received the operation, and that a subsequent read confirmed the new state.

What matters is that each passage is demonstrated by its appropriate source. Some combinations change the conclusion a lot:

• There is a tool call, but there is no corresponding operation in the provider and the resource has not changed: There may have been a failure, blocking or no effect operation. The call alone does not prove the change.
• There is a change in the provider, but there is no corresponding agent trace: there is a telemetry gap or the change may have another origin. Do not attribute causality just to the proximity of the time.
• There is “allowed” decision, but the call failed: authorization existed, but this does not prove successful execution.
• There is a change attributed to the agent and another subsequent change made by another actor: preserve both; the current state should not be attributed entirely to the first event.

Current NIST guidance for incident response places an emphasis on determining the sequence of events and the assets involved, rather than relying on a single source of evidence.

Rebuild confidence should appear in the report

Not all incidents will end with the same quality of evidence.

A high-confidence completion can combine authenticated identity, correlated trace, tool invocation, authorization decision, provider event, and state confirmation.

A medium confidence conclusion may have a gap — for example, the provider confirms the operation and the trace confirms the tool, but the policy decision at that time is not preserved.

A low confidence conclusion depends primarily on approximate time, conversation, or inferences without common IDs across layers.

Recording this difference is more useful than filling the gap with artificial certainty. NIST recommends preserving the integrity and provenance of incident data and also recognizes that collected evidence must be handled according to the organization's retention and preservation procedures.

Saving everything is also a risk

Forensic observability does not mean permanently recording every prompt, document, tool argument, and API response.

The richest data for debugging is precisely that which may contain personal information, confidential content, secrets or business data. OpenTelemetry's GenAI conventions explicitly flag the risk of sensitive information in messages, instructions, arguments, and results.

Log design needs to balance investigation and exposure: identifiers and metadata may remain available longer, while sensitive content may require masking, restricted access, or lower retention. The investigation records themselves also need confidentiality and integrity protection, as recommended by SP 800-61 Rev. 3.

Closing the incident should produce controls for the next execution

A useful investigation does not end with “the agent made a mistake”. It needs to identify at which layer the control failed.

If the cause was a misinterpretation, it may be necessary to review validation of intent. If the tool call received inappropriate parameters, the fix may be in the tool contract. If the policy authorized more than it should, authorization review comes in. If no one can tell what happened because the identifiers don't cross the layers, the problem is also one of observability.

This is where the forensic agenda meets the preventive agenda. Once you know which permissions contributed to the incident, the next step is to review how to limit permissions before the incident by linking this article to Agent with Drive, Email, and GitHub: How to Enforce Least Privilege Without Breaking Automation.

In the opposite direction, the preventive article can point to this content with the anchor how to investigate a wrong action by the agent. The URL of the existing article was not provided in the agenda, so the link must be inserted into the CMS without inventing an address.

The incident can be considered technically reconstructed when the team can answer, with evidence and an explicit degree of confidence: who initiated the execution, what the agent called, what was authorized, what the provider actually executed and what state resulted from the operation.