The AI SOC Stopped the Attack. A Human Decided It Could.

Series: Building the Agentic SOC – Part 4

Where We Are

Part 2 showed the attack with nobody watching: one leaked key, and under half an hour later an admin identity with account-wide access. Part 3 showed how to organize an AI SOC so it sees that attack as one case instead of a scatter of alerts. This part is what actually happens inside that SOC when the case is real, taken from a fresh run of that same attack, this time with Stream.Security watching. Then the question that decides whether you can run any of this in production: how much do you let the AI do on its own?

The attack begins, in an account Stream.Security is now watching. The AI attacker's first ~9 minutes: it validates the leaked key, hijacks the management Lambda, and starts to escalate.

When the Alert Fires, the AI Pulls the Thread

The first detection was not dramatic. A newly created IAM user, neo, was doing something. What the AI SOC did next is the part a human queue cannot do in time.

It pulled every log tied to that identity and built the picture from them. The source of the activity: a single internet IP geolocated to Singapore, not AWS infrastructure, not a VPN. The toolchain: a Python and Boto3 client on Linux. Then it pulled the identity's own history and found the tell. The user had been created only minutes earlier, by an administrator, through Terraform, from a completely different IP and toolchain. So the credential was minted by an automation pipeline in one place and, minutes later, was being driven by hand from an internet address on the other side of the world. That mismatch, provisioned by Terraform, operated by Boto3 from Singapore, is not something a rule spells out for you. It is something an investigator concludes by putting two logs side by side, and the AI concluded it in seconds.

‍

From there it followed the chain the way Part 3 promised, on one case rather than four alerts. It saw the same identity enumerate its own permissions, discover the management Lambda, and then modify that Lambda's configuration and code, which it flagged as an active change, not reconnaissance. It followed the Lambda itself and watched it execute under its privileged role, attempt to read secrets and parameters and instances (all denied), and then succeed at the step that mattered: creating a new IAM user and attaching a console login profile to it. The AI named that for what it was, a persistence backdoor, planted so the attacker could walk back in through the console after the original key was gone. A human analyst reading these as four separate tickets could easily close the login-profile ticket as routine automation. In this case, one of the AI's own sub-checks initially read that new user in isolation as benign. Working the whole case, with the Lambda weaponization in view, it did not.

‍

Then it delivered a verdict, and escalated it as the evidence mounted: first suspicious, then malicious, high confidence, critical severity, with the reasoning attached. Structured enumeration from a foreign internet IP within minutes of provisioning, a non-Terraform toolchain, a confirmed Lambda code modification, a planted console backdoor. This is the investigation a good analyst produces after an hour with five consoles. The AI produced it in a couple of minutes, while the attack was still going.

Inside Stream.Security's CDR platform: the detection firing, the correlated logs, the attack graph, and the AI-driven investigation reconstructing the chain.

The Response: One Decisive Action

Investigation that arrives too late to matter is just a very good post-mortem. The point of doing it in minutes is to act while acting still helps.

The attack was still running while the AI worked. The hijacked Lambda kept spinning up, the brute-force kept hammering IAM. And then, a few minutes later, it stopped. The attacker's calls started coming back invalid. The key it had ridden in on no longer worked.

Back on the attacker's side: around the ten-minute mark, the neo user is blocked, its keys are rejected, every call fails. The attack is dead, and from here the attacker has no idea why.

Here is what killed it. StreamForce, Stream.Security's agentic SOC, had finished its investigation, reached a malicious verdict, and taken a single response action on its own: it deleted the compromised access key. Not the user, not the account, not a broad lockdown. The one credential the entire attack ran on, removed.

Stream.Force, Stream.Security's agentic SOC layer: working the case end to end and executing the response, deleting the compromised key.

That was enough. With the key gone, the attacker's path back into the privileged role was cut, and it never reached the admin identity it was hunting for. From the attacker's first API call to the key going dead: about ten minutes, and no human in the loop. StreamForce detected, investigated, decided, and acted on its own. Set that against Part 2, where the same attack with nobody watching took the whole account in under half an hour. Here it died at ten minutes, mid-brute-force, well short of maria.

Sit with the action it chose, because it is the whole point. It did not delete the user, detach every policy, or lock down the account. It deleted one key, the precise credential the attack depended on. Deleting a key is not free, someone has to issue a new one, but that is a reissue, not a rebuild, and it lands on exactly the thing that was compromised and nothing else. A defender that reaches for a targeted action that decisively breaks the chain, not a teardown, is one you can actually let run. That instinct did not come from nowhere. Someone put it there.

The Real Question Is Trust

Here is the thing nobody selling AI security likes to say plainly: the hard part of autonomous response is not the response. It is trusting it.

Detecting and investigating with AI is comfortable, because the worst an investigation can do is be wrong on a screen. Letting an agent change your cloud is a different kind of risk. The action that stops an attack and the action that causes an outage are often the same action, pointed at a different resource. Deleting a compromised access key, the move that stopped this attack, sits toward the safe end: it is targeted and recoverable. Deleting the wrong key, one a production job quietly depends on, is an incident you caused. Isolating a compromised host is textbook containment. Isolating a host that anchors a payment flow is a headline. Deleting a rogue identity is clean. Deleting the wrong one is a rebuild and an apology.

‍

There is a sharper version of this you should not miss, because our own demo walks right up to it. Deleting the key was not the gentlest move on the menu. Setting it inactive would have stopped the attack just as fast and been reversible with a single click, no reissue needed. We deliberately let the agent delete, because this is a disposable lab where being wrong costs nothing. In a production account I would draw the line differently: authorize the agent to set a key inactive on its own, and keep permanent deletion behind a human, or reserve it for the highest-confidence cases. That is not a contradiction. It is the point. The safest autonomous action is not a fixed answer the vendor ships; it is a choice the architect makes for their environment, and ours was a lab.

‍

So you cannot hand an AI agent a blank check on production, and you should not want to. But you also cannot make it ask a human before every action, because then you are back to the human-speed loop the attacker already beat. The answer is neither "let it do anything" nor "let it do nothing." It is a decision, made carefully and in advance, about exactly which actions the agent may take on its own, which it may only recommend, and which it may never take without a person on the line.

That decision cannot be made by the AI vendor, because it depends on your environment. It cannot be made by the SOC analyst, because it depends on architecture they do not own. It is made by the person who knows that isolating this host is fine and isolating that one takes down billing, that this key is a dead lab credential and that one is load-bearing, that a deny-all on this identity is reversible and safe while deleting that one is not. It is made by the Security Architect.

‍

This is Part 1's argument arriving at its most concrete form. Designing response is not writing runbooks for humans anymore. It is defining the response authority of an autonomous agent: the menu of actions, the blast radius of each, the line between what it does alone and what it brings to a person, and the reasoning behind where that line sits. Draw it too tight and the AI investigates beautifully and stops nothing. Draw it too loose and your defender becomes the outage. Drawing it correctly, per action, per environment, is an architecture problem, and it is the one that decides whether an AI SOC is something you can actually turn on.

An Open Question for Your Environment

Our attack took about ten minutes and was contained comfortably. A fair question is what happens when an attack is faster than your own detect-and-respond loop, one that finishes in a couple of minutes, before your telemetry has even surfaced it. The honest answer is that it depends on your telemetry, your log delivery, and the response authority you have granted, and those are specific to you. So rather than assert a number, I would rather you find your own: deploy the CDRGoat scenarios in your account, point your AI SOC at them, and measure where your line actually falls. That measurement is worth more than anyone's claim.

What This Series Was About

Four parts, one argument. Part 1: response has to be designed alongside defense, and the Security Architect is the one positioned to design it. Part 2: a modern attacker is fast enough that a human SOC cannot keep up. Part 3: organizing agents around one shared case is what lets them see the attack in time. Part 4: an AI SOC can then detect, understand, and stop that attack on its own, but only inside the response authority a human granted it.

The agentic SOC is not a product you switch on. It is a system someone has to architect: what the agents see, how they share it, how the case stays coherent while it changes, and, above all, what the agents are trusted to do without asking. That someone is the architect. That was the whole point.

The attack scenarios in this series are open source. Try CDRGoat.