How to notice trouble and stop it in time

NIST's incident-response guidance recommends correlating information across multiple log sources and applying defined criteria when declaring an incident. A log is a record of system activity; correlation means examining related records together. 2

Our proposal is to give each authorized agent job a traceable identity that follows it through tools and supporting services. A responder should be able to establish who started the job, what permission it had, which resources it contacted, and whether later activity belonged to it.

Security operations and the agent-platform team should jointly own this record. Keep authoritative copies beyond the agent's ability to edit. The record need not contain every sensitive document the agent reads. Capture enough information to investigate actions while limiting unnecessary collection of private content.

For a safe exercise, introduce a documented sequence of synthetic events into a testing environment: an unexpected resource request, repeated permission denials, and a dummy cross-project access attempt. Check whether the monitoring system connects them and sends the result to the right responder.

The tradeoff is noise. An isolated failed request might be ordinary troubleshooting. Review the sequence, its permitted purpose, and its potential consequence, then tune the rules against both missed incidents and needless interruptions.

Our proposed stop procedure has a concrete outcome: affected agents and their delegated jobs can no longer perform the operations under investigation. That may require pausing new dispatches, stopping active workers, revoking access, and preventing automatic relaunch.

The incident lead should have authority to activate this procedure. Platform owners should maintain the mechanisms and account for every system involved. Establish substitutes for unavailable staff before running unattended work.

A safe test uses harmless jobs that repeatedly update a dummy resource. Activate the stop and verify that updates cease, access is withdrawn, and queued retries do not restart the activity. Measure the time from activation to the last successful action. A button labeled “stop” is not the evidence; the observed result is.

Stopping has costs. It may interrupt legitimate users or discard unfinished work. Define in advance which activities can be paused automatically and which require a human decision. Where the possible consequence is serious, uncertainty should trigger a prompt assessment by someone empowered to restrict the activity.

Preserve investigation records as part of the procedure. A rapid response should avoid turning the only useful evidence into collateral damage. Teams need a practiced way to restrict access while retaining the records needed to understand what happened.

A proposed AI assistant for responders should begin with limited authority to organize evidence and suggest next steps. Treat text inside an attack log as evidence to inspect, even when it contains commands or apparent instructions. The assistant should not be able to execute those instructions merely because it encountered them during analysis.

The security team should choose an approved environment for sensitive logs and restrict access to credentials and private content. Test the assistant on synthetic hostile messages, missing records, and misleading explanations. A separate policy check should govern consequential actions such as revoking access or changing a live service.

This creates additional review work. Measure whether the assistant reduces the total effort needed to reach a verified response, rather than just producing more findings for people to investigate. If the assistant becomes unavailable, responders still need an accessible record and a practiced manual procedure.

NIST recommends checking restoration assets, addressing incident root causes before production use, and verifying restoration actions. It also calls for criteria governing recovery and documentation when recovery ends. 2

For an agent service, our proposed restart review should involve the incident lead, the system owner, and a security reviewer who did not implement the repair. They should examine what failed, what changed, and which test demonstrates that the affected capability is now appropriately restricted.

If the failure involved excessive access, demonstrate the reduced permission. If it involved a processing feature, demonstrate the corrected behavior and its surrounding limits. If the responder could not stop delegated work, repeat the stop exercise with those dependencies included.

Restart with dummy or low-sensitivity resources before expanding the affected capability. Give each expansion a named owner and an observable reason to proceed. Gradual restart may still miss problems.

The tradeoff is slower restoration. Business pressure to resume will be real. Documenting the unresolved uncertainty lets decision-makers weigh that pressure without pretending an incomplete investigation has produced certainty.

Our proposed recurring exercise should follow one harmless scenario from detection through restriction and restart. Record when the signal appeared, when someone acknowledged it, when affected activity ceased, and what evidence supported recovery. Include an unavailable primary responder so the exercise tests the backup arrangement.

The resulting improvement might be a clearer responsibility or a missing service in the stop procedure, rather than another detector. The essential question is whether a person can turn a warning into an effective, verifiable restriction, including when the system is running unattended.