Enterprise takeaway: The important change in recent intrusion reporting is not a new kind of credential theft. It is the speed with which automated tooling can connect ordinary weaknesses across identity, cloud, applications and data. Security leaders should test whether their monitoring and containment work across that sequence, not simply whether a single suspicious event produces an alert.
On October 30, 2026, Google Threat Intelligence Group (GTIG) and Mandiant described observed misuse of agentic offensive frameworks including ARTEX and PentAGI in real investigations. Wiz had separately documented ARTEX-linked activity against software vendors on October 22. These are observations of specific campaigns, not proof that every attack now runs autonomously or that all enterprises face the same timeline.
What the incident evidence changes
GTIG reports that some ARTEX activity occurred in bursts of roughly two to 25 seconds. Its report describes an operation with 27 events in 23 seconds, while other phases included pauses. The same report cites investigations in which an actor progressed from initial account compromise to deep access in around four hours and, in one case, 15 minutes. Those numbers belong to the observed cases; they should not be promoted into an industry-wide average.
Wiz found repeated probing across identity providers and business applications, with requests that adapted after failed attempts. Many actions used normal interfaces. This is why a rule that watches only for a known executable or one source IP is insufficient. A legitimate account may make several legitimate-looking calls that form a dangerous sequence.
Our earlier cloud credential-harvesting playbook examined rapid compromise from an incident-response perspective. The additional question here is operational: can defenders join signals from several systems quickly enough to prevent the next action?
Five tests for the security operations team
1. Detect an unusual chain, not merely a high count
In a controlled exercise, simulate an approved identity signing in from a new source, enumerating permissions and then attempting access to a sensitive data service. Verify that identity, cloud-control and data-access events can be correlated into one investigation. The alert should show the sequence and affected principal, not three unrelated tickets. Establish a normal baseline first so legitimate deployments do not trigger constant false alarms.
2. Measure containment time against the attacker path
Start the clock when the first actionable event becomes observable. Record time to detection, time to analyst acknowledgment, time to credential revocation and time to confirmed denial of further access. A fast alert is of limited value if a stolen service principal remains valid for another hour. Use authorized tabletop or isolated tests, not live exploitation of production systems.
3. Test nonhuman credentials and delegated permissions
Inventory service accounts, workload identities, deployment tokens and API keys. Check where each can authenticate, which resources it can enumerate and whether its permissions can be escalated indirectly. Prefer short-lived, scoped credentials and constrained network origins where feasible. Our service-account token security tests show why audience binding, rotation and least privilege need separate evidence.
4. Place guardrails around ordinary business functions
GTIG described misuse of legitimate application capabilities, including a notification feature that sent messages to more than 1,300 internal recipients in one observed case. A system does not need malicious code to cause damage when a compromised identity can initiate bulk actions. Test recipient ceilings, unusual-volume alerts, approval for sensitive changes and immediate suspension paths for messaging, account creation and data export.
5. Prove that response survives cross-system handoffs
Have the incident team rehearse an event that starts in a public application, crosses into identity infrastructure and reaches cloud storage. Confirm who owns the case, which logs are retained, and whether responders can disable a workload identity without waiting for a different team to locate the owner. The same dependency problem appears in our external guardrail outage analysis: a control is only useful if its failure and escalation paths are understood.
A practical detection-to-containment model
Identity, API and data-plane events
Principal, sequence and unusual volume
Revoke, isolate and limit high-impact actions
Confirm subsequent requests are denied
Proposed operational test model; not a vendor benchmark.
Which measurements are worth reporting?
For each exercise, record the percentage of test sequences detected, median and worst-case detection delay, containment delay, the percentage of compromised credentials successfully disabled and the number of legitimate workflows interrupted. Record false positives per normal workload volume, not just the number of alerts. A single average can conceal a dangerous long tail: the slowest containment cases may be the most consequential.
Separate visibility from prevention. A security tool that identifies suspicious storage access after the download is complete did not prevent the data loss. Likewise, a clean alert dashboard does not establish that missing application logs are covered. Use a coverage matrix listing every identity provider, cloud account, critical application and sensitive data store, with the telemetry actually received.
What the reporting does not establish
The cited research describes specific investigated campaigns and expected evolution. It does not establish a universal attack-speed distribution, prove that every actor uses autonomous tooling, or show that any particular security product prevents the behavior. GTIG itself notes that current campaigns can be noisy and that established practices such as segmentation, short-lived credentials and behavioral detection remain relevant. The procurement decision should therefore focus on demonstrable coverage and response time, not a new label on the threat.
Enterprises reviewing their own agent permissions can also apply the ownership and authorization framework in our least-privilege automation identity guide. Defending against machine-speed misuse begins by ensuring that a single identity cannot reach everything.
Sources and scope
- Google Threat Intelligence Group and Mandiant, October 30, 2026 — observed intrusions, timelines, defensive layers and limitations.
- Wiz Research, October 22, 2026 — independently described identity and application probing patterns.