Reported FTC AI Safety Probe: What Teams Should Record

The reported FTC investigation makes a familiar operational question more urgent: can your team explain what an agent was allowed to do, what it actually did and how you responded when something went wrong? Keep those records useful for running the system. The report does not establish a new universal compliance checklist or a finding of wrongdoing.

Written October 1, 2026 and dated September 30, 2026, using the dated announcements cited below. Later product developments are outside this article’s scope.

Semafor reported that an FTC official confirmed a probe involving OpenAI, Anthropic and the evaluation organization METR. It said civil investigative demands were expected in the following weeks and that the investigation predated the earlier Hugging Face incident. The companies had not immediately responded to its requests for comment. This article relies on that attributed reporting; we did not locate a standalone FTC release establishing the detailed scope.

An investigation asks questions. It is not itself a conclusion that the organizations violated a law, and an expected demand is not a demand we have inspected. Avoid turning reported timing into a deadline for every business that uses an AI agent. If your organization receives an actual legal request, its response should be handled with qualified counsel based on that request.

The recommendations below are operational practices for teams running agents. They are not presented as FTC-mandated retention periods, reporting deadlines or a legal safe harbor.

A useful task record identifies the model and version, the instruction set, the available tools, the account used and the environment in which execution occurred. Those facts make it possible to understand why an action was technically possible. A saved prompt alone cannot show whether a worker inherited a credential or could reach an external service.

Keep the record close to the work. A task identifier that connects the instruction, tool activity and accepted output is more useful than several disconnected logs. Record material permission changes during the task as well as the starting configuration, because an approval can expand what the agent is able to do.

Define the acceptance criteria before running the evaluation. Save representative failures, not just the examples that support adoption. If a test measures whether an agent stops at an approval boundary, retain what action it attempted and how the boundary handled it. An answer saying that the agent understands the policy is not evidence that enforcement worked.

Compare the actual deployment with the tested setup. A model evaluation conducted without production tools cannot establish the behavior of the same model with write access to customer records. The permission-default guide explains why tool authority needs its own review.

For an incident, record the observed behavior, discovery time, affected scope, immediate containment and the decision about resuming work. Distinguish what is known from what remains under investigation. If an alert fired but execution continued, preserve both facts rather than describing the event simply as “detected.”

The OpenAI DNS incident is a useful example of why detection and stopping are different properties. A response drill should verify that the task and relevant child processes stopped, pending work was cancelled and revoked credentials no longer worked. Record the drill result separately from the written procedure.

Do not solve traceability by keeping every secret indefinitely. Choose access controls and retention appropriate to the material, and avoid storing raw credentials in task logs. Preserve the evidence needed to reconstruct the event, with sensitive material handled through the organization’s established process.

Review phrases such as “always asks,” “cannot leave the sandbox” and “fully autonomous.” Each makes a stronger claim than a limited evaluation may support. Describe the tested configuration and the remaining limitations. Our GLM capability analysis shows why benchmark results, safeguards and access are separate claims.

The runtime boundary comparison can help structure a technical review. Our AI transformation service supports task evaluations and operational controls; legal conclusions about a specific investigation require its actual facts and legal context.

The question in the lede is simple: what was the agent allowed to do, what did it do, and how did you respond? The illustrative records below each existed and each failed to answer it. They are patterns the operational checklist is built against, not accounts of any organization.

Each record was kept in good faith and still could not reconstruct the run. The structure in the next section is the difference between records that exist and records that answer.

The four failures share a cause: each record was kept for its own purpose, by a different team, without a way to join it to the others. The prompt library belonged to the people writing instructions, the evaluation results to the people shipping, the alert history to operations and the public page to marketing. Each was correct on its own terms and none could be joined to the others when a single question arrived.

The configuration section says to keep the record close to the work, and the mechanism is a task identifier that every other record carries. The scope record: the requested outcome and the actions authorized for it. The access record: the model and version, the instruction set, the tools available, the account used, the environment, and every material permission change during the task, because an approval mid-run can expand what the agent is able to do. The evaluation record: the acceptance criteria defined before the run, the checks for missing inputs, denied permissions and interrupted execution, and the representative failures kept beside the successes, versioned so a model, tool or policy change shows which checks were invalidated. The incident record: observed behavior, discovery time, affected scope, immediate containment, what stopped and what continued, and the decision about resuming, with what remains under investigation marked as such.

An illustrative set for a hypothetical agent that updates records in a sales system: scope, update the status field on records the user names, no deletions, no outbound messages; access, the named model version, the instruction file by hash, three tools, a service account with write access to one object type, a run in the staging environment, one approval granted mid-task to read a second object type; evaluation, twelve defined checks including a denied-permission case, two failures retained in which the agent proposed an outbound message and was stopped at the boundary; incident, none. Every line carries the same task identifier, so the four records read as one.

The set does the public-claims section’s work as well. A sentence such as always asks before writing can be checked against the evaluation record for that configuration and no other. Where the record does not support the sentence, the sentence narrows to the tested setup and the remaining limitations, which is what the section asks for and what an actual legal request, handled with counsel, would need to be answered with.