A company can hold every agent log under its own encryption keys and still be unable to answer a basic operating question: who acts when a signal arrives at 2 a.m.?
Log custody matters. It does not assign the person who interprets an alert, the identity allowed to pause the agent, the evidence that must survive an incident, or the decision required to resume service.
Customer-owned agent telemetry is therefore an architecture boundary, not a complete operating model. A production deployment needs a named chain from signal generation through custody, detection, adjudication, containment, investigation, and resumption.
A new architecture makes the seam visible
On September 1, Anthropic announced Enterprise Frontier Safeguards, or EFS. The announced design responds to a real tension. Detecting misuse that unfolds across sessions and accounts may require retaining and correlating activity. Regulated enterprises may be unable or unwilling to place that retained activity with another data vendor.
Anthropic says EFS will let customers store monitoring data in their own cloud accounts under their encryption keys, access policies, and audit logging. Anthropic's automated systems analyze a rolling traffic window and send flags to the customer. The customer's people perform the human review; Anthropic says its own human review is not required. The controls are opt-in and are planned to roll out in phases, with broader availability targeted for later this fall.
That is an important division of technical responsibility. It also reveals three different meanings of “owner.” The customer may control storage and keys. The provider may operate detection. A customer employee may adjudicate a flag. None of those assignments automatically identifies who contains a live problem, preserves evidence, communicates impact, approves a change, or returns the workflow to service.
Storage ownership is not operational ownership
Agent telemetry has more work to do than populate a dashboard. It should let an operator reconstruct which identity initiated a run, what context the system retrieved, which policy decisions occurred, what tools were invoked, which arguments and permissions were used, and what state changed.
Microsoft's agentic-AI observability guidance recommends capturing identity context, run identifiers, retrieval provenance, tool calls, permissions, and outputs. It says capture and retention should be governed by a data contract that balances forensic needs with privacy, residency, minimization, retention, access, and encryption requirements. It also argues that telemetry should support incident reconstruction, not only latency and token dashboards.
That distinction is useful across vendors. A telemetry pipeline can be healthy while the response system is absent. The logs arrive. The dashboard renders. The alert fires. Nobody has accepted the pager. Nobody can revoke the executing identity. The investigation team may not even be cleared to see the underlying prompt and tool data.
Microsoft's separate secure-agent guidance makes the connection explicit: pair real-time monitoring with an incident-response plan that names who is alerted, how the agent is paused or revoked, and how the event is investigated.
Write the signal-to-resumption chain
For one consequential agent workflow, record each link and the proof it will produce before launch:
| Link | Decision to record |
|---|---|
| Telemetry | Which identity, input, policy, retrieval, tool call, approval, output, and resulting state must be captured? |
| Custody | Where does the record live, who holds the keys, who can read it, how long is it retained, and what is minimized or redacted? |
| Detection | Which patterns are evaluated across which account and time window, and what known blind spots remain? |
| Adjudication | Which cleared role reviews a flag, what context arrives, and what separates a false positive from a suspected incident? |
| Containment | Which identity can pause the agent, revoke access, isolate a connector, or route work to a safe fallback? |
| Evidence preservation | Which records become investigation evidence, how is integrity checked, and who can place or release a hold? |
| Resumption | Who accepts remediation, which regression and negative tests must pass, and how is authority restored gradually? |
This is my proposed operating record, not a description of Anthropic's, Microsoft's, AWS's, or NIST's internal process.
Every row also needs acceptance evidence: a captured test event, an access decision, a delivered and correctly routed flag, a successful pause, an integrity result, or an approved return to service. An owner without exercised proof is still an assumption.
The record should assign different roles when the control requires separation. The team that tunes a detector should not silently dismiss its own high-consequence flags. The agent identity should not be able to delete the record used to investigate it. Review access, redaction, and emergency elevation should be designed before an incident, not negotiated while the agent is still acting.
Test the blank spaces
Walk a synthetic alert through the chain before production, using authorized test data. Confirm that the signal reaches the right queue, the on-call role sees only the evidence it needs, containment works, unrelated workflows continue, and the evidence remains reconstructable.
Then introduce failure. Delay the flag. Remove a required field. Make the primary responder unavailable. Break the correlation between the agent trace and the authoritative application event. Attempt to modify or delete a retained record with every credential available to the deployed workflow.
Audit tooling offers a useful warning against checkbox thinking. AWS CloudTrail documentation explains that signed digest files can reveal modification or deletion of delivered logs. It also says enabling log-file integrity validation causes digest delivery but does not itself validate the files. Someone still has to run or automate verification and handle failure.
The same distinction applies here: a feature can make evidence available without making it operational.
NIST SP 800-61 Rev. 3 frames preparation, detection, response, and recovery as connected parts of cybersecurity risk management. An agent alert should enter that organizational system through named interfaces. It should not become a separate experimental queue left with the team that built the pilot.
Put the operating boundary in the FDE handoff
The receiving team needs more than a monitoring endpoint and dashboard link. The handoff should include the telemetry data contract, responsibility record, alert routes, response expectations, containment and revocation procedures, evidence-integrity check, access-review schedule, retention and deletion rules, and resumption gate. It should distinguish the parts held by the model provider, cloud platform, deployment team, customer security function, workflow owner, and permanent operator.
Run the synthetic alert with that permanent operator in control. The field team can observe and answer questions, but the operator should triage the flag, execute containment, preserve the record, accept remediation, and restore service. Any step that still depends on the original builder is unfinished transfer work.
Customer-controlled storage can solve a hard trust and data-boundary problem. It cannot decide who wakes up, who is cleared to review the evidence, who stops the workflow, or what proof permits it to run again.
Before expanding an agent's production authority, choose one serious monitoring scenario and exercise the full path from signal to resumption. If the permanent team cannot complete the chain without the original builder, it does not yet operate the safeguard. It stores the logs.