A Cursor agent changed files I did not approve. How do I see the changes?
Work from the record, not the editor's memory: list the job's steps, mark each step that ran without a recorded approval, and read the files those steps touched from their saved results. Review the receipt and actual deliverable before accepting a handover.
An agent changing files silently is two failures, not one: the change itself, and the absence of any decision point where a human could have stopped it. Git will show you the diff, eventually, mixed with everything else. The work record answers the sharper question: which steps ran, in what order, with what approval state attached to each.
Where the work ran through the connection, build the unauthorized-change list directly: the job's steps in order (each committed in an AER-1 receipt, IETF Internet-draft-zambo-aer1-21, at execution), the files named in each step's saved result, and the approval column, recorded sign-off or none. The list separates three cases that feel identical in the moment: approved work you forgot approving, work inside the agent's standing instructions, and genuinely unapproved changes. Each case has a different correct response, and only the record can sort them.
Then the gate, because a list without a gate is an autopsy habit. For repositories that matter, file-changing steps above your threshold wait for a recorded human sign-off in the job before they execute; the sign-off is a step, the execution is a step, and the pair is what reviewers read. Where the agent ran entirely outside any record, this incident is the tuition: the fallback is git archaeology, and the fix is routing the next session through the connection with the gate on.
Checklist: the unauthorized-change review
1. Pull the job's step list for the session in question. 2. Mark each file-changing step: file, change summary from its saved result, approval state (recorded sign-off, standing instruction, or none). 3. The none list is the unauthorized set: review each change on its merits; keep, revert as a new recorded step, or escalate. 4. Record the review itself as a step in the job. 5. Turn on the gate: sign-off steps required before file changes in this repository. 6. Note the incident in the access record (which agent, which repo, what changed in the rules).
Worked example
Sample: a Monday review finds eleven file-changing steps from a weekend session: seven under the standing instruction to update tests, three approved in the job, one configuration change with no approval at all. The list takes ten minutes from the record; the one true problem is fixed, gated, and documented before standup. (Sample scenario; no live record is cited.)
Frequently asked questions
The agent ran in a plain Cursor session with no connection. What can I see?
Git history, editor local history, and file timestamps: enough to reconstruct the changes, not enough to see approvals or steps. Reconstruct this once, then route future sessions through the connection with the gate, so the next review is a reading exercise.
Does the sign-off gate slow the agent down badly?
It slows the consequential changes, deliberately, to human reading speed, and leaves investigation and drafting ungated. Most teams set the threshold by file type: production configuration and migrations gated, tests and docs free.
Should I revoke the agent's access after an incident like this?
Review access as part of the incident record: narrow it to the repositories the work needs, and let the gate carry the rest. Blanket revocation usually lasts a week; a gate plus a narrowed scope lasts.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai