iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Audit an AI agent by correlating its session or trace records with the files, repository history, and external-system logs that actually changed. Preserve the session ID, timestamps, tool calls, approvals, outputs, diffs, and service records before reverting anything. Then undo only the unwanted scope: an individual edit, a session checkpoint, or repository changes. Deployments, network requests, database writes, and other external effects require recovery in the systems where they occurred; a workspace checkpoint cannot reverse them.
The workflow below covers OpenAI Agents API traces, GitHub Copilot session and enterprise audit records, VS Code agent checkpoints, Git, and Microsoft Purview. Their coverage and retention differ, so treat each record as evidence with a defined boundary rather than as a complete history of everything the agent did.
What does an AI-agent audit need to prove?
A useful audit answers four questions: which agent and user acted, what the agent attempted, what actually changed, and which recovery action returned the affected systems to an acceptable state. A model response alone is not proof of execution. Match the agent’s record to observable results such as file diffs, commits, command output, deployment history, API logs, database audit entries, or service activity.
- Identity and timing: record the user, agent or subagent, session and turn identifiers, and a time range with timezone.
- Intent and execution: preserve prompts or requests where your product records them, model outputs, tool calls and results, approvals, delegated work, and status.
- State evidence: capture modified, staged, deleted, and untracked files; repository diffs and commits; and logs from systems the agent contacted.
- Recovery evidence: document the exact undo, restore, revert, or service-side remediation and verify the resulting state independently.
Keep the original records read-only or export them before changing the workspace. Otherwise, the recovery operation can overwrite the evidence needed to explain what happened.
#1 Best Overall
Which records can show what an agent did?
OpenAI Agents API traces and observability
OpenAI’s observability documentation describes session logs, saved history, turns, tool calls, subagents, and recorded usage. Its tracing documentation describes spans that can include inputs, outputs, duration, and status. Use the session and trace identifiers to connect a model turn to each tool invocation, then compare the recorded result with the target system.
In the documented tracing interface, traces are built after a turn ends. Live events are available for progress while a session is active, but an in-progress view is not the same as a finalized trace. OpenAI also notes that a turn can identify a subagent, while command-output truncation is not reported; an absent or abbreviated output therefore does not prove that a command failed or did not run.
See OpenAI Agents API observability and OpenAI Agents API tracing for the fields and interface available in your deployment.
GitHub Copilot cloud-agent records
For GitHub Copilot cloud agent, the session log shows progress and tools used, and commits link back to the session logs. Stopping a session ends its Actions run but does not remove commits already pushed. Stopping is therefore a containment step, not an automatic rollback.
GitHub’s enterprise audit log is a separate record. It covers agent activity on GitHub’s website, but the documentation explicitly says, “The audit log does not include client session data, such as the prompts a user sends to Copilot locally.” Do not claim a complete prompt history from that log.
Enterprise owners or users with the Read enterprise audit logs custom role can access the log when Copilot Business or Enterprise is in use. GitHub documents a 180-day event history and recommends streaming events to a SIEM for longer retention and anomaly alerts. Details and current access requirements are in GitHub’s Copilot audit-log documentation. Session controls are described in GitHub’s session-management documentation.
Rank #2
- Used Book in Good Condition
VS Code agent review records
VS Code’s agent review experience exposes per-change Keep and Undo controls and can create checkpoints. Its change list is not necessarily a complete activity log: edits made only through terminal commands or scripts may not appear in tool-specific change tracking. Always inspect the filesystem and repository, including untracked files.
Microsoft Purview audit records
Microsoft Purview documents audit entries for user interactions with Copilot and AI applications, including who interacted, when and where, and references to resources accessed. For non-Microsoft AI applications, those interaction logs use pay-as-you-go billing and retain records for 180 days when the required billing feature is enabled. Microsoft states that billing is based on the number of audit records ingested. Read the current scope at Microsoft Purview audit for Copilot and AI applications.
How do I preserve evidence before undoing anything?
Contain further damage first, but do not destroy the record you need to investigate. If the agent is still running, use its stop or cancel control and note the time and resulting status. Then make an evidence bundle before restoring files or reverting commits.
- Identify the activity. Write down the agent name, user, session ID, turn or request ID, subagent IDs, repository or workspace, and the start and end times with timezone.
- Export native records. Save the session timeline, trace or audit events, tool inputs and results, approval decisions, delegated-agent records, and any live-event transcript your product exposes.
- Snapshot local state. Run a non-destructive status check and save the output. For Git, capture
git status --short,git diff,git diff --cached, and a list of untracked files before any restore or clean operation. - Capture external state. Record deployment IDs, CI or Actions runs, API request IDs, database transaction or audit IDs, cloud-resource versions, and service timestamps. Ask the owning service for an export when the agent’s log does not include the effect.
- Hash or permission the bundle. Store exports in access-controlled, append-only storage when possible, and record who collected them. This protects the evidence from accidental edits during recovery.
Do not infer success from a green agent status or a missing error. A tool may have run through a script, produced truncated output, or changed a service that the local session cannot see.
How do I trace an agent action to the resulting change?
Start with the session record and work outward to the state that changed. Use timestamps and identifiers as joins, not as a substitute for inspecting the result.
- Open the session timeline. In OpenAI’s documented interface, use Logs → Agents, find the session, open its timeline, expand the relevant turn, and inspect its spans. Follow root-agent and subagent spans to each tool call and result.
- Build an action list. For every tool call, record the requested operation, arguments, approval decision, returned status, and any resource identifier. Mark whether it was read-only, workspace-changing, repository-changing, or external.
- Compare with diffs. Inspect working-tree, staged, committed, and untracked changes. Include files created or deleted by shell commands and scripts, because they may not appear in an agent-specific list.
- Match external records. Search deployment, CI, API-gateway, database, cloud, and SaaS audit logs using the time window, user, request ID, commit SHA, or resource ID. Confirm whether an apparent command actually reached the service.
- Classify confidence. Label each finding as recorded execution, corroborated state change, attempted but unconfirmed, or not observed. “Not observed” is not the same as “did not happen” when logs are incomplete.
For GitHub Copilot, follow a commit’s link back to its session log, then compare the commit and any working-tree residue with the tools shown in that session. If the session was stopped, inspect pushed commits anyway; stopping does not retract them.
Rank #3
Which rollback should I choose?
Choose the narrowest action that removes the unwanted state without erasing legitimate work. The recovery scope, not the convenience of the button, should drive the decision.
| Recovery method | Best for | What it changes | Important limit |
|---|---|---|---|
| Per-edit Keep/Undo | One or a few reviewed file edits | Selected local changes | May not cover terminal or script effects. |
| VS Code checkpoint restore | Broad workspace rollback to a recorded point | Affected files and subsequent conversation turns | Temporary; does not reverse terminal commands, network requests, deployments, or external-service changes. |
| Git restore or a revert commit | Tracked repository changes with a durable history | Selected files, paths, or commits, depending on the operation | Does not undo an already executed deployment or external write. |
| Service-native recovery | Deployments, database writes, cloud resources, SaaS records, or API side effects | The affected external resource | Requires that service’s permissions, retention, and recovery features. |
VS Code states, “Checkpoints are temporary and don’t replace Git version control.” Use checkpoints for quick local experimentation, and use Git or the owning service’s history for durable recovery and collaboration.
How do I undo unwanted file changes in VS Code?
Use per-change undo when only specific edits are wrong; use a checkpoint when the whole agent turn must be discarded. Inspect the removal set first, especially if you edited files yourself after the agent ran.
Undo selected edits
- Open the agent’s review or change view for the active session.
- Inspect each diff, including additions, deletions, and modifications.
- Select Undo only for changes you have verified as unwanted; select Keep for edits that should remain.
- Reopen the files and check the working tree after the operation.
Restore a checkpoint
- Open the session’s checkpoint or restore control and review which files and conversation turns will be removed.
- Export or copy any legitimate edits made after that checkpoint.
- Restore the checkpoint, then inspect the workspace, untracked files, and repository status.
- Handle every external action separately and verify it in the external system.
A checkpoint is a workspace and conversation operation. It cannot retract a command that already ran, a request sent over the network, a deployment, or a write to an external service. The VS Code guidance on review and revert is at Review and revert agent code edits.
How do I recover repository changes safely with Git?
First preserve the diff and identify work that belongs to a person rather than the agent. Then choose a path-specific restore, a commit revert, or a branch reset only when its scope is understood.
Uncommitted changes
After saving evidence, review git status --short and git diff. A path-specific git restore -- path/to/file discards unstaged edits in that path, so use it only after confirming the file contains no wanted work. To remove a staged change while keeping the file edit, unstage it with the appropriate source-control control, then review the resulting diff. Treat commands that clean untracked files as destructive and do not run them until untracked evidence is preserved.
Rank #4
Agent-created commits
If an unwanted commit is already shared, prefer a new revert commit so collaborators retain a visible history. A history rewrite such as resetting a shared branch can strand other work and requires coordination. Before either operation, record the commit SHA, parent, diff, checks, and any deployment that consumed the commit.
After the Git operation
- Re-run status and diff checks and confirm that expected files, permissions, and generated artifacts are present.
- Run the project’s normal tests, linters, or build checks before reopening the agent.
- Check CI, deployment, and package-publishing systems for jobs already triggered by the original commit.
- Record the recovery commit or restore operation in the incident timeline.
How do I undo deployments, API calls, and database writes?
Use the affected system’s own rollback, restore, or compensating-action mechanism. A local file restore changes neither a server already deployed nor a record already written.
Deployments
Identify the deployment ID, commit or artifact version, environment, and completion time. Use the platform’s supported redeploy or rollback to a known-good artifact, then verify health checks, configuration, migrations, and traffic routing. If a migration changed data, coordinate application and database recovery rather than rolling back code alone.
Network and API calls
Use request IDs and service audit logs to distinguish attempted calls from accepted ones. If the API supports deletion, cancellation, or idempotent reversal, perform that operation with the service owner’s authorization and record its result. Where no inverse exists, document the irreversible effect and apply a compensating update under change control.
Databases and external records
Use transaction logs, point-in-time restore, row history, or an application-level correction according to the database’s recovery policy. Test a restore on an isolated target when possible, and verify referential integrity and downstream consumers before replacing production data.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should an audit and rollback record contain?
Create a concise timeline that another operator can replay without relying on the agent’s final message.
Best Value
| Field | Example content | Why it matters |
|---|---|---|
| Actor | User, agent, subagent, service account | Separates human, model, and automation responsibility. |
| Correlation | Session, turn, trace, request, commit, deployment IDs | Joins records across products. |
| Time | UTC timestamp and local timezone context | Aligns logs with retention windows and scheduled jobs. |
| Action | Tool, arguments, approval, result, status | Shows what was requested and what was reported. |
| Observed state | Diffs, untracked files, service and database entries | Proves the resulting change independently. |
| Recovery | Undo, checkpoint restore, revert, service rollback, verification | Shows exactly how and whether the state was corrected. |
| Evidence boundary | Missing prompts, truncated output, unavailable service logs | Prevents an incomplete record being treated as definitive. |
How long are agent audit logs retained?
Retention is product- and configuration-specific. GitHub documents 180 days for its Enterprise Cloud Copilot audit-log history. Microsoft documents 180-day retention for enabled, pay-as-you-go audit logs covering non-Microsoft AI applications. Neither figure is a universal retention period for AI agents.
Export records to a SIEM or compliant archive when your investigation or policy requires a longer history. GitHub recommends SIEM streaming for long-term storage and anomaly alerts. OpenAI’s Codex safety guidance describes exporting OpenTelemetry events such as user prompts, tool-approval decisions, tool-execution results, MCP-server use, and network allow or deny decisions to SIEM and compliance systems; those events and fields are specific to that telemetry setup, not guaranteed across products. See OpenAI’s Codex safety guidance.
How can teams prevent an agent rollback incident?
Make evidence and recovery part of the agent’s operating boundary before it changes anything.
- Run agents in isolated branches, worktrees, sandboxes, or disposable environments when practical.
- Require approval for destructive commands, production credentials, deployments, database writes, and external API operations.
- Assign correlation IDs that travel from the agent session into CI, deployment, API, and database logs.
- Stream high-value events to centralized logging with access controls and a documented retention policy.
- Separate read, write, deploy, and administrative credentials; grant the least privilege needed for the task.
- Use repository protection and required review for shared branches.
- Test checkpoint and service rollback procedures on non-production data so operators know what each control actually reverses.
These controls reduce the gap between an agent’s narrative and the state it changed, but they do not eliminate the need to inspect diffs and external logs after every high-impact run.
Frequently Asked Questions
Can stopping an AI agent undo work it already committed?
No. Stopping normally prevents additional execution, but a commit that was already created or pushed remains. Review the linked session and commit, then use a normal Git revert or the repository’s approved recovery process.
Why is a tool-use log not enough to prove what changed?
Logs can omit local prompts, truncate command output, or miss edits made by scripts and terminal commands. Compare the record with filesystem, repository, deployment, API, and database evidence before declaring an action successful or harmless.
What if the agent changed a file I edited afterward?
Do not restore the entire checkpoint blindly. Export your later work, review the affected hunks, and undo only the agent-owned lines or files; preserve both versions in the evidence bundle.
How do I investigate an agent action after the log retention window?
Look for exports in your SIEM or compliance archive, repository commits, CI and deployment records, service audit logs, and local operating-system history. If none exists, document the missing evidence and avoid presenting an unverified reconstruction as fact.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
