Security teams should investigate an unfamiliar sequence of tool use before deciding that an AI agent caused it. Wiz's October 29 report offers behavioral clues for that investigation, but the useful control is a correlated account of actions, identities and outcomes. A fast command sequence or a verbose script alone cannot establish the operator's identity or the degree of automation.
In The Rise of Agentic Attacks, Wiz describes three intrusions it investigated and proposes seven recurring fingerprints of agentic activity. Its account creates a practical question for defenders: can existing telemetry distinguish an authorized automation job from a changing attack sequence that uses the same tools?
Treat the report as an investigation source
Wiz describes cases involving an exposed Flowise service, a Java operations gateway and an AI agent backend reached through an MCP interface. Its proposed clues include sustained iteration, written reasoning inside tooling, adaptation after failures and broad exploration of possible paths.
These are Wiz's findings and interpretations. The report says the strength of evidence and degree of autonomy vary across cases. Its discussion of future attack scale and attribution is an assessment, not a measured industry-wide incident rate. Secondary coverage corroborates the report's publication and scope; it does not independently validate the underlying incident telemetry.
Maetra's recommendation is to use these clues as investigation hypotheses and test them against the environment's own records. Respond to demonstrated harmful behavior even when the AI label remains uncertain.
Reconstruct the sequence that changed direction
Begin with the earliest relevant action your records support. Connect the initiating identity, process, tool request, target and result. Then look for a meaningful change after an error or refusal. Did the next step follow an approved fallback, or did it seek a different resource or credential?
Suppose an authorized inventory task receives a permission error while listing a service. A later attempt to read credentials or inspect unrelated systems would warrant review because of the task boundary, regardless of whether a model selected it. This is a hypothetical detection example, not a claim about one of Wiz's victims.
Preserve enough of the returned result to explain the next action. A timeline containing requests alone may make ordinary retries look adaptive, while a timeline containing only alerts can hide the relationship between an initial failure and a later escalation. Use correlation references where available and record gaps where systems cannot supply them.
Compare suspicious activity with authorized automation
Machine speed is common in legitimate software. Build the comparison around what the workload was permitted to do: its job definition, owner, execution window, resource scope and expected destinations. Ask whether a particular action fits that context before treating volume as the decisive signal.
For an internal maintenance agent, the relevant baseline might include a small approved set of endpoints and a predictable recovery path. For a scanner, broader enumeration may be expected. A detection rule should explain why the observed combination is unusual for this identity and task, rather than assume every broad scan is malicious or AI-driven.
Written plans inside scripts can help an investigator understand intent, but their presence is evidence to interpret. Comments can be copied, misleading or unrelated to execution. Keep the original artifact, its provenance and the events showing what actually ran. Separate the artifact's statements from the investigator's conclusion.
Choose a response on observed risk
Define what evidence is sufficient to restrict a credential, isolate a workload or escalate to incident response under the organization's existing process. A response decision can depend on unauthorized secret access or unexpected writes without requiring certainty about the model or agent framework behind them.
Avoid converting an attribution guess into a broad automatic block. Correlate the resource, identity and action first, then apply the response authority appropriate to the demonstrated risk. If an automated response is permitted, the team still needs to know its target, scope and expected effect. Wiz's report does not validate any particular organization's response configuration.
The audit evidence guide provides background on retaining decision and runtime records. Limit sensitive payload collection to what the investigation requires, with appropriate access and retention controls. A security evidence store should not become another uncontrolled copy of credentials or private data.
Test one suspicious tool request in context
Take a sanitized example from an authorized exercise and write down the task, proposed tool action and expected destination. Review the unsafe behavior separately from the question of who generated it. That makes the exercise useful even if the same action could have been written by a person or a conventional script.
Maetra Secure scans prompts, tool calls and outputs for runtime threats. It does not identify an attacker or replace cloud telemetry. Use the Secure sandbox to examine one bounded tool request, then connect the finding to the evidence and response process your security team already operates.
Sources
- Wiz: The Rise of Agentic Attacks, October 29, 2026. Primary investigation report and proposed behavioral criteria.
- The Injection: report summary, October 29, 2026. Secondary coverage of the report, not independent incident verification.