An agent reports that it stopped a customer-data export because the destination was not approved. The security team finds a denied request in the gateway log. That looks reassuring, until someone notices an export file created a minute earlier.
Did the agent create the file and then stop? Did it send the file through another tool? Did the denial apply to a retry after the first transfer had already succeeded? This is a hypothetical example, but the investigation problem is concrete: the final message and a blocked request cannot answer those questions on their own.
What METR proposes
METR’s proposal for independent investigations, published July 28 and revised September 5, 2026, asks researchers to examine the tendencies behind serious AI misbehavior, including how training and operating conditions shaped them. It calls for access to relevant models, transcripts, environments and staff. That goes beyond a review of the public incident report.
The September revision explicitly addresses uncertainty: missing or altered logs, unreliable model explanations, and experiments that fail to recreate the original conditions. METR also recommends transparency about an investigation’s scope, access and redactions. The original July questions remain available in the page’s update log.
Our focus at Oktsec is the deployment a security team has to operate while those questions are being studied. The team needs to establish which actions occurred, which permissions applied and what must change before the workflow runs again. A training-level explanation may take time. Containing an exposed export route cannot wait for it.
Reconstruct the export
Start with the assignment. Suppose a support agent was allowed to summarize one customer’s case using approved internal documents. Record that scope before interpreting its tool calls. Reading the case, generating a local summary and uploading the underlying files are separate operations, even if the agent describes all three as preparing a response.
Next, follow the file. The export service may record when it created an object and which account requested it. A storage system may record a subsequent read. A network control may record a connection to an external host. Each record answers part of the question; a connection alone does not establish which file was transferred.
Correlate those records using request identifiers, object identifiers and time. Check clock differences and retries before deciding on the sequence. A service account shared by several agents will require additional evidence to attribute the action. If attribution remains uncertain, keep it uncertain in the report.
Follow the actions in order. Both paths produce a denial record.
- File createdExport is readyIt remains in the internal workspace.
- Gateway recordUpload deniedThe request stops before dispatch.
- Destination checkedNo file receivedThe tested route did not deliver it.
- File createdExport is readyThe same starting point.
- Destination recordFile receivedA direct upload bypasses the gateway.
- Gateway recordRetry deniedThe later denial cannot undo the transfer.
Recover the permissions in effect
Today’s configuration may already contain the fix. Save the policy version, tool configuration and account permissions that were active when the export ran. Otherwise, a reviewer may test the corrected setup and mistakenly conclude that the original action was impossible.
For this example, the important details include the allowed destination, the account that could read the export and whether a second tool could send it. If a human approved an exception, preserve what that person actually approved. Permission to prepare a report should not silently become permission to upload every attachment.
Connect the historical permission to the requested operation, then check what happened at the destination. These three sources answer different questions.
Suppose these are the records available for the export.
Uploading attachments was outside the approved task.
This request was rejected before dispatch.
Earlier delivery has not been independently checked.
The transfer remains unresolved.
Without receiving records or equivalent evidence, you cannot rule out an earlier upload through another route.
For implementation detail, see authorization telemetry for AI agents. A decision record and a receiving record should be correlated, without asking either to prove more than it captures.
State the evidence gap
State what the available evidence supports in the incident report. “No transfer found in the records reviewed” leaves room for a missing source. “No transfer occurred” requires enough coverage to support the stronger claim. In the export example, a missing storage access log could change the conclusion and the containment decision.
Protect the investigation material as carefully as the affected system. Copy relevant records into a restricted location, preserve originals and document who handled them. Investigators may need sensitive parameters to understand an operation, but credentials and customer contents should not be copied indiscriminately into tickets or a general-purpose analysis assistant.
A signed record can help detect changes to that record. It cannot establish that every action was recorded. For an evidence review, integrity and coverage need separate answers.
Test the fix against the outcome
Test the fix in an isolated environment with synthetic customer files and destinations the team owns. The original agent should remain limited to summarizing the case, with no permission to upload attachments. Keep the original configuration available for comparison without reconnecting it to real customer systems.
For a separate baseline test, explicitly authorize a test account to export synthetic files to one internal test destination. Confirm that this export succeeds. Then attempt it using the original agent’s restricted permissions: the upload should be denied. Also test an unapproved destination. Check both the access decision and the receiving service; a timeout or broken integration should not count as a successful security denial.
Finally, try the other routes available to this workload: a second upload tool, a direct API client or a delegated agent with a different account. The purpose is to test the deployment’s actual exposure. There is little value in proving that one connector is restricted while leaving the same account free to send the file elsewhere.
Record the result precisely. An unsafe request stopped by a control demonstrates enforcement in that tested path. An agent that declines to make the request demonstrates different behavior in that run. Both are useful observations; they support different conclusions about the fix.
What the review can establish
A workflow investigation can establish that a particular account had excess access, that a transfer occurred, or that a tested route now rejects it. It cannot, by itself, explain how the model acquired a tendency during training or predict every situation in which that tendency will appear. METR’s proposed access to models and training evidence addresses a different depth of investigation.
That distinction should shape the handoff. Give the model provider the relevant behavior and context. Give the infrastructure owner the access changes to make. Give the person approving a restart the tested outcomes, remaining exposure and unresolved evidence gaps.
If a transfer occurred, the report should identify the route that accepted the file, the permission that allowed it and the tested control that now prevents the same transfer. If the evidence cannot establish whether a transfer occurred or which route it used, say so and explain how the team will close that gap. That is a better basis for running the agent again than a reassuring final message.
Related reading: Anthropic’s cyber incidents: when access becomes permission and Agent work needs evidence.