The Alert That Didn't Fire: How Mate Reasoned Past a Silent Credential Theft

Any AI system investigating a cloud incident is limited by the same thing a human analyst is: the data that actually got logged.

Sometimes that data has a gap, and the honest move is to say so instead of guessing. What separates a system that stops there from one that's actually useful is what it does next. An experienced analyst who hits a gap in the evidence asks sharper questions, pulls in whatever context she has that isn't available in any log, and reasons her way to an answer anyway. Here is a real case study from a Mate investigation, where agents hits such a gap

The alert

On June 24, 2026, two detections landed on the same resource within minutes of each other: a cloud CNAPP alert titled “Lambda Function Credentials Used Outside Of AWS”, and a same-severity XDR incident pointing at the same subject, a custom Lambda function. 

A second signal followed about 90 minutes later: an unusual GetCallerIdentity call, the kind of identity check an attacker makes to confirm stolen credentials still work.

Mate's autonomous investigation and triage agents picked up both alerts and ran end-to-end closing within nine minutes. That run wasn't a single model answering a prompt — it was an orchestrated workflow of specialized agents coordinating to one verdict: an alert decomposer, identity and asset profilers, a cloud-behavior analysis team, IOC analysis, a policy-insights step, and a final triage reviewer that weighs all of it into a single call. Between them, they did five things.

1. Decomposed the alerts into typed entities. Mate pulled the CNAPP issue, raw cloud events, XDR incident data, and posture and was able to identify the actor IP, the user agent, and the target role as well as determine blast radius to provide full context and priority for this incident.
2. Profiled the identity and the compute resource behind it, resolving the role to the specific Lambda function that owned it.
3. Ran identity-behavior analysis and reported, with low confidence, that it couldn't assess the account's behavior,  the correct answer for an IAM role. Sign-in and MFA telemetry simply doesn't exist for a service account the way it does for a human directory user. Flagging that gap plainly, rather than manufacturing a login history to fill it, is the harder and more useful thing to do.
4. Ran IOC analysis and pulled investigation history, which is where the case turned from a single alert into a pattern. Drawing on Mate's persistent investigation memory, it found the same source IP in credential-abuse activity against a different production account two days earlier, matching a signature that spanned 28-plus related investigations over roughly three months, none of them previously closed as benign. This is the part a rotating human shift almost always misses: Mate recognized a repeat actor across accounts and months instead of treating the alert as a first-time event.
5. Checked the knowledge base for an applicable auto-close playbook, found only a firewall-specific one that didn't fit the case, and left the investigation open instead of forcing a match to close it out.

Final verdict: suspicious, escalated for response. The decision anchor: Lambda credentials confirmed used from a non-AWS system with an unseen user agent, followed by an identity-verification call roughly 90 minutes later consistent with credential-theft reconnaissance.

That's cross-vendor correlation (CNAPP plus XDR), identity, behavior, network, and three months of history, reconciled automatically in under ten minutes. A human analyst doing the same thing by hand is pulling this out of two or three separate consoles and however many browser tabs it takes to hold the timeline in their head. It's also, by itself, not something you can act on yet.

The data that was missing

After running the investigation, three questions stood between “suspicious” and “resolved”:

• How did the attacker get this key?
• What actually succeeded, and what's the blast radius?
• Is the key or role still live?

These were left open because the signals did not exist in the investigation. This is a common investigation challenge. In this case, two days earlier, the EKS theft left a clear footprint: SSRF plus DNS rebinding against the metadata service, an OAST callback, an anomalous host header, a detection that fired the moment it ran. But this time, no equivalent signal existed in CNAPP, XDR, or CloudTrail. Most likely, attackers read environment variables inside the Lambda, or hit the metadata service directly from inside the function. This approach does not touch the AWS control plane and therefore does not generate cloud telemetry, which is required for automated correlation.

Most Agentic SOC systems would stop here - either hallucinate a verdict, or provide a blank “inconclusive”. Mate is designed to operate like an experienced analyst shadowing the customer’s SOC team. And what that analyst would say in this case would be “this is suspicious” and start a conversation - collaborating, filling in the blanks, to get to the root cause. This is exactly what happened in this case. The human analyst read the automated report and started a chat with the agent that produced it: same tools, same context, same investigation, continued as a conversation.

What the chat with Mate looked like:

Initially, the analyst asked: “check cloud events for all activity from the threat IP.”

The agent executed a live query against a three-day window in June 2026, and returned 28 event groups: one IP, two stolen identities, identical AWS CLI 2.31.13 tooling on both. The Lambda identity had run ListBuckets, GetPolicy against its own attached IAM policy, DescribeNetworkInterfaces, and ListAttachedRolePolicies. The identity from two days earlier had run a wider set of EC2 and network discovery calls against a different account. Same actor, two accounts, one campaign, laid out in a single query instead of a cross-referenced spreadsheet.

Then she asked: “which of these were successful and what has the actor been doing since June 22nd? Show full scope of all resources involved and all threat patterns.”

The agent ran live queries against both stolen access keys in parallel and broke every call down by outcome:

The attacker's actions here show a clear progression. First, they used `GetCallerIdentity` to confirm that the stolen credentials via the SSRF attack were still valid and active. But the last row of the table shows the more advanced stage: the attacker read the policy attached to the role. By enumerating and pulling the full `CustomLambdaAccessPolicy` document, they mapped exactly what that role could do—a level of targeted reconnaissance far more deliberate than what an automated verdict alone would surface.

The next question: which role does the new key belong to and is it active?

The stolen key had a one-hour session and had already expired by the time she asked. The role behind it hadn't. It had existed since 2023, was last used that same morning, was still active, still high-privileged, and its trust policy allowed only AWS Lambda Functions to assume it - which confirmed the attacker's usage came from entirely outside the legitimate path. Revoking an expired temporary key accomplishes nothing when the role that issues fresh ones on every invocation is still live.

The next question: in the previous attack, the attacker used SSRF to get the key - but this time, no alerts were triggered, how did the attacker get the key?

The agent worked the question by elimination, each step backed by a query. Had the June 22 EKS key been used to pivot into the Lambda account: zero events. Had the same SSRF-plus-DNS-rebinding technique run again this time: no detection, no callback domain, no anomalous host header. Had the Lambda's own configuration been read externally before the key surfaced: zero calls. Three plausible explanations, three queries, three negatives.

The analyst wasn't satisfied with “ruled out” and pasted in the full June 22 incident writeup - the one with the OAST callback and the DNS-rebinding host header - and pushed back directly, just like a conversation with a human:
I still don't get it, I need to know how the attacker got this key.

With that context loaded, the agent gave a sharper answer: 

The June 22 attack required DNS rebinding because the EKS pod had SSRF protections in front of it, which is why the attacker had to probe with an OAST callback first. 

Lambda functions have no equivalent protection by default. The metadata endpoint is directly reachable from inside a Lambda execution context, and AWS injects the access key, secret key, and session token into every invocation as environment variables.

So if the function processes any user-supplied input, the credential can leave in one of two ways: a direct call from inside the function to the metadata service, or code that simply reads the environment variables and sends them out. Neither produces a DNS-rebinding pattern. Neither produces an anomalous host header. Nothing about either method resembles the detection rule that caught the June 22 attack - which is the specific, mechanical reason nothing fired this time.

The agent stopped at an honest limit

The agent named the one piece of evidence that could settle between the two vectors, SSRF-to-IMDS or environment-variable exfiltration: CloudWatch Logs for the function in the window before the key surfaced. It said directly that it didn't have access to check them. That narrowed an open-ended unknown down to a single, specific, checkable thing, and told the analyst exactly what to go look at next. That's the difference between a system built to sound confident and one built to be useful to someone accountable for the next decision.

Three points where Mate refused to “fake with confidence”

• Mate honestly reported it didn’t have supporting data to assess the IAM role's behavior - flagging the gap with low confidence instead of making up a sign-in history that doesn't exist.
• Mate declined to auto-close the case when no playbook actually matched, rather than forcing a fit.
• Mate called the theft vector “most probable”, not “proven”, and named the exact log source that would confirm it so it could collaborate with the human analyst to resolve the case.

Automation delivered speed, chat delivered root cause

In this unique case, the agentic investigation provided speed and breadth: correlating alert sources, resolving an identity, checking behavior honestly instead of fabricating it, and — through persistent investigation memory — recognizing a repeat actor across accounts and months instead of treating the alert as a first-time event. Within nine minutes, Mate provided a defensible verdict, and did not try guessing where data didn't exist.

Then, chat completed reasoning, as an iterative process, and it did it without leaving the investigation or starting over in a new tool. Getting to “how” took a human directing targeted, hypothesis-by-hypothesis questions to the same agent, aiming the same tools it already had: ruling out a cross-account pivot, ruling out a repeat of the June 22 technique, ruling out pre-compromise config calls, then reasoning through the mechanics of how a Lambda's credentials leak once the analyst pushed with her own context from the June 22 report. It ran the actual queries an analyst would otherwise write by hand across CloudTrail, IAM, and STS, and built toward a mechanism, not just a label. It answered “how bad”, “how did it happen”, and “what do I do right now”, in the same window, using the same context the automated run had already built.

It drew an honest line where the evidence ran out. Mate didn't tell the analyst it was certain about a vector it couldn't ground in data. Mate explained which was the most probable vector, why, and precisely which log source confirms it. 

For a technical audience, that's a more credible claim than “fully autonomous”: the system knows what it knows, reasons hard on the data it has, and confidently hands off to a human and collaborates to complete the “last mile” rather than concluding the incident as “inconclusive”.

That's the same sequence an experienced analyst runs when the report in front of her doesn't have the answer: ask sharper questions, pull in context that was never in any log, and reason to a conclusion. The telemetry gap was real, and the investigation kept going anyway.

‍