AI Breaches Look Like Outages First: Why Your On-Call Engineer Is Now a Security First Responder

Last updated: July 14, 2026

‍

Direct Answer

AI-powered breach response increasingly starts with the on-call engineer, not the security team. AI-driven attacks compress intrusions that used to take weeks into hours, and their first observable signals are operational: CPU spikes, latency, config drift, and unexplained pipeline runs. Those signals page whoever is on call for infrastructure. That engineer becomes the de facto security first responder, usually without a security context, a security runbook, or a defined escalation path. Fixing that seam is now part of incident readiness.

‍

Overview

• What two new attack reports revealed this week
• Why machine-speed breaches surface as infrastructure alerts
• Human-speed vs. machine-speed intrusions, compared
• The First-Pager Problem
• Signs that an "outage" is actually a breach
• What NOT to do when an outage smells like an attack
• Five steps to prepare your on-call rotation for AI-powered breach response
• FAQ

‍

Two Reports, One Pattern

On July 14, 2026, CSO Online published an analysis of two recent incidents that should reorder how engineering teams think about incident response.

The first, investigated by security firm Sygnia, was an AI-assisted cloud compromise in which attackers chained weaknesses across application services, AWS resources, source-control repositories, CI/CD workflows, runtime components, and data stores. Credential harvesting, cloud enumeration, pipeline abuse, and database access were executed in what Sygnia called "a compressed time frame," with forensic traces consistent with AI-assisted automation adapting to each new system it touched.

The second, documented by Sysdig and dubbed JadePuffer, was an intrusion and extortion campaign conducted end-to-end by an autonomous AI agent: harvesting credentials, mapping internal services, establishing persistence, and demanding a ransom, with no human at the keyboard. The entry point was not a zero-day. It was a year-old vulnerability (CVE-2025-3248) in Langflow, ironically a tool for building AI agents. Attacks targeting AI tooling itself are a growing trend; our breakdown of model extraction vs. model inversion covers attacks aimed at the models.

Look at the list of systems touched in both cases. Application services, AWS instances, CI/CD runners, databases, and runtime components. That is not the SOC's turf. That is the territory your SRE and platform teams own, monitor, and get paged for.

‍

Why AI-Powered Breach Response Starts On Call

Traditional incident response assumes a division of labor: security tooling detects attackers, the SOC investigates, and the infrastructure team steps in if remediation affects production. That model was built on an assumption Sygnia's researchers say the new attacks break: that "attacker progression will generate enough observable signals for defenders to investigate and contain activity before access materially expands."

Human attackers spend weeks moving carefully to avoid tripping detection. AI agents don't bother being careful; they move faster than the detection review cycle. And fast, noisy activity inside your infrastructure produces operational symptoms first: resource consumption, latency, configuration drift, and disrupted services. Those symptoms flow through your observability stack, trip the same thresholds as any reliability problem (our guide to SLO-based alerting covers how those thresholds work), and page your on-call engineer, who begins investigating what looks like a routine outage.

Human-speed intrusions gave security teams weeks of dwell time and surfaced through security tooling; AI-driven intrusions compress to hours and surface first as infrastructure alerts routed to on-call engineers.

As Gidi Cohen, CEO of Bonfy.ai, told CSO, the organizations that will struggle "aren't the ones lacking AI defenses; they're the ones still relying on human-speed security in a machine-speed threat environment."

‍

The First-Pager Problem

The First-Pager Problem: who responds first to an incident is determined by alert routing, not by the incident itself. When a breach causes infrastructure symptoms, the pager assigns an SRE, and the incident is investigated as an outage until someone realizes otherwise.

The First-Pager Problem is not a tooling gap; it is an organizational seam. The SRE has admin access, deep system knowledge, and a mandate to restore service fast. What they usually lack for a security incident is exactly what matters most: the instinct to preserve evidence, the awareness that "fixing" a compromised system can tip off an attacker or destroy forensics, and a rehearsed handoff to the security team.

Meanwhile, the economy is moving in the wrong direction. Dray Agha of Huntress put it plainly in the CSO piece: "The skill floor for running a ransomware operation dropped to the cost of running an agent." More attackers, more often, against the long tail of unpatched infrastructure. More 2 am pages that are not what they appear to be.

‍

Signs an "Outage" Is Actually a Breach

On-call engineers should treat the following combinations as escalation triggers, not curiosities:

• Performance degradation plus credential activity. Latency or CPU anomalies coinciding with unusual IAM events, new access keys, or logins from unexpected principals.
• Config drift, you didn't deploy. New roles, modified security groups, unfamiliar scheduled tasks, or changed runtime settings with no matching change record.
• Pipeline runs, nobody triggered. CI/CD jobs, especially those that touch secrets or deploy targets, are outside normal patterns. Both recent attacks abused deployment workflows.
• Egress spikes from data stores. Databases or object storage are suddenly transferring volumes inconsistent with application behavior.
• Problems that return after remediation. You fix it, it comes back. Both documented attacks planted multiple persistence points specifically to survive recovery efforts.

Any one of these alone can be innocent. Two or more together during what appears to be an outage is a security escalation.

‍

What NOT to Do When an Outage Smells Like an Attack

• Don't restore first and ask questions later. Rebuilding an instance or rolling back a deploy can destroy the forensic evidence needed to understand the intrusion, and it doesn't remove the attacker's other footholds.
• Don't assume the security team already knows. The signals that paged you may never have crossed the SOC's tooling. Explicitly notify; don't infer.
• Don't treat recovery as containment. The Sygnia attackers established persistence in multiple locations precisely so recovery would fail. A restored service with an attacker still inside is not a resolved incident.
• Don't investigate alone to avoid a false alarm. The cost of paging security unnecessarily is minutes of someone's time. The cost of not paging them is measured in exfiltrated data.

‍

Prepare Your On-Call Rotation for AI-Powered Breach Response: 5 Steps

1. Add a security branch to your incident runbooks

Every major operational runbook should include a short "if this looks like a breach" branch: the specific signs to check, who to page, and what to stop doing. It costs a page of documentation and removes the 2 am judgment call.

2. Define the SRE-to-security handoff before you need it

Agree in advance on a joint severity level, a shared channel, and who runs the incident when it's both an outage and a breach. An incident commander model works here; the point is that the handoff is a rehearsed step, not an improvisation.

3. Build evidence preservation into remediation steps

Snapshot before you rebuild. Capture volatile state (running processes, connections, recent logs) before restarting. Make these steps part of the standard rollback procedure so they happen by default under pressure.

4. Run tabletops that start as fake outages

Most security tabletop exercises start with "we've detected a breach." Start one with a latency alert instead, and see how long it takes the responding engineer to consider compromise. That gap is your real detection time, and it belongs in the exercise's postmortem; our guide to AI-assisted postmortems covers how to capture it without extra toil.

5. Route correlated alert classes to both teams

Alert combinations from the signs list above (infra anomaly plus IAM activity, pipeline runs plus secrets access) should page security and on-call simultaneously. AI-assisted triage can pre-assemble the cross-system context an on-call engineer would otherwise gather manually while the attack progresses; our post on AI incident management explains how that investigation layer works.

‍

FAQ

What is an AI-powered breach response?

AI-powered breach response is the practice of adapting incident response for attacks that are executed or accelerated by AI agents, which compress intrusion timelines from weeks to hours. It emphasizes machine-speed containment, cross-team escalation between on-call engineers and security, and preparation for attacks that first surface as operational symptoms.

Why do AI breaches look like outages first?

Because AI-driven attacks move fast and noisily through infrastructure, their earliest observable effects are operational: resource spikes, latency, config drift, and service disruption. Those signals route through observability tooling to on-call engineers before security tooling flags an intrusion.

Should SREs be responsible for security incidents?

No, but they should be prepared to be first on scene. The realistic goal is not making SREs security analysts; it is giving them the recognition signs, escalation paths, and evidence-preservation habits to hand off cleanly and quickly when an "outage" turns out to be a breach.

How fast do AI-powered attacks move?

Recent documented cases compressed multi-stage intrusions into hours. Sygnia's July 2026 investigation found AI-assisted workflows executing credential harvesting, permission analysis, and attack-path mapping across multiple cloud systems in a compressed time frame, and Sysdig's JadePuffer case showed an autonomous agent running an entire intrusion and extortion campaign without human operators.

‍

Glossary: Key Terms in AI-Powered Breach Response

• On-call engineer: The engineer designated to respond to production alerts during a given rotation, typically responsible for restoring service when something breaks.
• SRE (Site Reliability Engineer): An engineer focused on the reliability, performance, and operability of production systems, usually the owner of monitoring, alerting, and incident response for infrastructure.
• SOC (Security Operations Center): The team (or function) that monitors security tooling, investigates suspected intrusions, and coordinates the response to confirmed security incidents.
• Dwell time: The period between an attacker's initial access and their detection. Human-led intrusions historically averaged weeks or months; AI-driven attacks compress dwell time to hours.
• Lateral movement: An attacker's progression from the initially compromised system to other systems in the environment, typically by harvesting credentials and exploiting internal weaknesses.
• Persistence: Mechanisms an attacker plants to retain access after detection or recovery, such as new access keys, added roles, or scheduled tasks. Persistence is why restoring a service does not equal containing a breach.
• Credential harvesting: The automated collection of passwords, API keys, and tokens stored on compromised systems, used to unlock access to further systems.
• IAM (Identity and Access Management): The layer of a cloud environment that controls identities, roles, and permissions. Unusual IAM activity during an apparent outage is a key breach indicator.
• Config drift: Differences between a system's actual configuration and its intended, version-controlled state. Drift with no matching change record can indicate attacker modification.
• CI/CD pipeline: The automated workflow that builds, tests, and deploys code. Pipelines hold secrets and deploy rights, which makes unexplained pipeline runs a high-value attack signal.
• Egress: Data leaving your environment. Sudden egress spikes from databases or object storage during an incident suggest exfiltration rather than an operational fault.
• Zero-day: A vulnerability unknown to the vendor and defenders, with no patch available. The attacks covered here did not need zero-days; they exploited known, unpatched flaws.
• Incident commander: The single person who coordinates an incident response, makes escalation decisions, and keeps responders aligned, without doing the hands-on investigation themselves.
• Tabletop exercise: A structured walkthrough of a simulated incident used to test processes and handoffs before a real event, without touching production systems.

This glossary defines the security and operations terms used in this article; unusual IAM activity, config drift, persistence, and egress spikes are the four terms most useful for recognizing a breach disguised as an outage.