Hunt Multi-Agent Intrusions With a Velocity-and-Identity Timeline

Why machine-speed coordination changes the hunt

TrendAI published an October 23 analysis of three attacker-controlled environments targeting organizations in Japan. The researchers described different levels of AI involvement, from automation through 44 agents to human-led work assisted by AI. Their evidence came from exposed attacker infrastructure, not complete victim telemetry, so the claims should be treated as a well-documented observation rather than a universal attack pattern.

Independent coverage on October 27 amplified the finding, creating a current attention signal without proving market prevalence. The practical lesson for a SOC is narrower and more durable: coordinated automation can compress many identity, discovery and tool actions into a short window. Existing controls still produce the evidence needed to catch it.

This workflow is for SOC analysts, incident responders and cloud identity teams with access to identity-provider, endpoint, cloud control-plane, source-control and network telemetry. It does not require an AI-native SIEM, and it does not assume DeepSecurity.io sells or operates any named vendor product.

• Problem: dozens of individually ordinary events can form one high-risk chain.
• Tools: SIEM or query platform, identity logs, cloud audit logs, endpoint telemetry and an approved AI assistant.
• Output: a cited timeline, affected-identity list, open questions and analyst-owned response decision.

Define velocity signals before involving a model

Start with a bounded time window and a small set of signals that your environment can produce reliably. Useful candidates include one source touching several identities, rapid creation or use of short-lived credentials, unusual repository-secret access followed by cloud API calls, and a public-facing workload reaching internal administration services.

Normalize every event into five fields: timestamp, actor, action, target and result. Add source-log ID and trust boundary. Keep the raw record immutable and put only a redacted working copy into any AI system. A model should never receive live credentials, private repository content or customer data merely to make the timeline easier to read.

Use time synchronization and service-account ownership as prerequisites. Clock drift and shared accounts can create the appearance of automation where none exists.

• Create a baseline for each service account and automation identity.
• Flag cross-system sequences, not single high-frequency events.
• Preserve raw evidence IDs so every summary claim can be checked.
• Label inferred links separately from directly observed events.

Run a reproducible evidence-first analysis

Export a minimal case table for the scoped window, remove secrets and unnecessary personal data, then calculate deterministic groupings before asking an AI assistant to interpret anything. Group by source, identity, target and five-minute interval; mark boundary crossings and first-seen tool sequences.

A useful prompt is constrained: “Using only the supplied event rows, build a chronological table with event ID, actor, action, target, result and confidence. Group events only when a shared identifier or explicit timing relationship supports the link. Cite the event IDs for every conclusion. List contradictions and missing logs. Do not recommend containment commands.”

The expected output is a draft analyst packet, not a verdict. Reject any statement without a source ID. Re-run the same frozen input with the same prompt version if a reviewer needs to reproduce the result.

• Step 1: freeze and hash the redacted event export.
• Step 2: create deterministic velocity and boundary-crossing flags.
• Step 3: ask the model for a cited chronology and uncertainty list.
• Step 4: have an analyst verify each high-impact conclusion against raw logs.
• Step 5: record the final disposition and rollback owner.

Separate explanation from containment

Machine-speed activity creates pressure to automate the response, but the same uncertainty that makes a case difficult also makes blind containment dangerous. Keep the AI assistant read-only. It may identify which evidence supports a credential-rotation recommendation, but it should not rotate credentials, disable identities or block networks.

For each proposed action, require an accountable owner, blast-radius estimate, rollback method and preservation step. If the evidence points to a shared service identity, containment may break production faster than the intrusion itself.

The safest early actions are often evidence-preserving and reversible: increase logging, snapshot volatile context, restrict one confirmed path, or issue a short-lived session revocation with a tested recovery plan.

Measure the workflow and know its limits

Track evidence citation accuracy, time to produce a reviewable timeline, number of unsupported claims, analyst correction rate and containment reversals. These are local pilot metrics; this article reports no tested result for DeepSecurity.io or any customer.

The workflow can miss activity when logging is incomplete, identities are shared or an attacker slows down to resemble ordinary administration. High event velocity is not proof of AI use, and low velocity does not rule it out. TrendAI itself cautioned that the exposed attacker data could not validate every claimed victim outcome.

Close the case with a compact packet that future responders can audit. Keep the model version, prompt version, redaction rules and evidence hash with the analyst decision.