Once the corporate network stopped being defensible, the control had to move to the device, as SentinelOne® has long argued.

That move carried one assumption with it. Wherever the laptop sits, name resolution tells it the truth and the agent can reach its own cloud. Almost nothing in the stack checks either half.

In July 2026, Microsoft disclosed a campaign that breaks both and named it CaptiveCrunch. A captive portal is the sign-in page a public Wi-Fi network pushes in front of you before it lets you online. Hotels, airports, conference centres, the splash screen you click through without reading. That is where this campaign starts.

CaptiveCrunch is the work of APT29, the cyber-espionage arm of Russia's Foreign Intelligence Service. Microsoft tracks the group as Midnight Blizzard, and elsewhere it is Cozy Bear. Outside the industry it is best known for the SolarWinds compromise.

We saw the same operation from the endpoint, across multiple environments we protect in three regions. We also found the adversary answering from inside the victims' own networks, which no public account of the campaign describes.

The Adversary Was on the Victim's Own Network Segment

Public accounts of CaptiveCrunch describe compromised captive-portal infrastructure, but our telemetry shows something narrower. The DnsPoison indicator recorded LLMNR responses on UDP/5355 carrying the adversary's address on roughly a third of affected hosts.

The queries carried randomised canary hostnames. LLMNR is link-local multicast that does not traverse routers. Anything answering those queries had to be sitting on the victim's own broadcast domain.

A Responder-style spoofer was sitting on the shared network, and no DNS server anywhere in the chain was compromised.

The techniques in play:

• T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay)

• T1557 (Adversary-in-the-Middle)

• T1659 (Content Injection), for the fake updates served in response to connectivity checks

• T1584.008 (Compromise Infrastructure: Network Devices), per public accounts, for the captive portal gateways

From the same layer-two segment as the laptop, the spoofer raced the legitimate resolver and won often enough to matter. Across affected hosts, clean and poisoned answers for the same domain interleaved seconds apart.

Success rates ranged from 5.6% to 84% depending on the network. The spoofer replayed the genuine CNAME chain and rewrote only the terminal A record.

Then Windows delivered the lure itself. To check whether a network needs a sign-in page, Windows fetches a known file over plain HTTP. If the reply is not what it expects, it assumes a captive portal and opens the default browser for sign-in. All of that is documented behaviour.

An adversary who rewrites the reply on-path gets the operating system to open the browser at their page. The lure needed no email and no link, but everything after that still needed a person at the keyboard.

The payload was a browser updater matched to the victim's own browser. Microsoft documented ClickFix-style lures for this campaign. In those, the victim is walked through running a command. We saw no such lure on our endpoints, where downloading the file and launching it was manual every time.

Nothing you own sits in the path on someone else's LAN, so the control has to live on the host.

Disable LLMNR. It is the best host control and also the bluntest. It takes away the protocol the adversary is answering on, which no detection rule can do. LLMNR's fallback is rarely load-bearing in a managed estate.

Why the Usual Controls Were Not In the Path

The attack runs on someone else's network, so your network controls are not involved. Your DNS filtering is not involved either, because the spoofer forges answers on the wire before trusted resolvers respond.

The browser renders the lure because Windows told it to. The chain has no email, link, attachment, or scripting host in it.

There is also almost no behaviour to detect, because everything dangerous about this payload happens after a process is created. Before that, nearly every step belongs to the operating system or the network. That is not the kind of behaviour a detection engine is built to catch.

The payload is CornFlake, a Go remote access trojan. CornFlake in turn deploys ChocoShell, a PowerShell infostealer that runs entirely in memory. Microsoft's analysis of the same payload itemises what each of them does.

CornFlake, on the host:

• Surveillance: A raw-input keylogger, clipboard monitoring, on-demand screenshots, microphone and webcam capture, and USB monitoring.

• Persistence: Service registration, Run keys, and scheduled tasks, with a watchdog to restore whatever a defender removes.

ChocoShell, deployed by CornFlake and resident only in memory:

• Cookie theft: Live cookie extraction from browser process memory and a defeat for Chrome's App-Bound Encryption.

• Token theft: Microsoft 365 and Entra ID tokens lifted from the Token Broker cache.

• Evasion: It disables AMSI through .NET reflection and runs a timing-based check for sandboxes and virtual machines before collecting anything.

• Escalation: It chains three UAC bypasses in fallback order through the SilentCleanup task, wsreset.exe, and sdclt.exe.

Until it runs, the file sits inert in Downloads.

Deciding Locally, On the File, Before it Runs

The adversary controlled the network the laptop sat on and had cut the agent's path to its cloud. That left the file, judged on the agent with nothing else in the loop.

The agent convicted every copy that landed, each before it could execute. That is one hundred percent of delivered payloads in one hundred percent of affected environments. We verified both figures twice against the telemetry. One endpoint ran an agent nearly a year out of date and reached the same verdict as current ones.

Then we tested for the things that would mean we were wrong. Every check came back empty:

• No process creations from the Downloads folder on any affected host

• No adversary-attributable persistence

• No lateral movement

• No post-incident C2 contact

• No payload hashes remaining

What It Looked Like in the Console

The investigating analyst recorded his screen while walking the Storylines on the endpoint where the payload came closest to running.

Because the Storylines are scattered across the campaign, he worked in two views. One was the management console, and the other was the Threat Operations Center, which clusters the same events more legibly.

Storyline 1: Delivery, With the Poisoning Visible On One Screen

It opens with Windows launching Edge with the connectivity-check URL as its argument.

Scroll into the DNS events on that same Storyline and the race is sitting there in plain view. One request for a domain resolves to a legitimate address. Scroll down, same domain, and it resolves to the adversary's address.

The same name was answered both ways, minutes apart, on one machine. Only injection racing a real resolver produces that pattern. Later comes the download, a browser updater with a (5) suffix on its filename.

The suffix means the browser had already written four earlier copies to the same folder. Our analyst took that to mean someone kept going back for it and tried to run the last one.

Deep Visibility does not record mouse clicks. Manual launching is an inference from the filename and the process chain, and we are flagging it as one.

Storyline 2: A Token Request While the Login Domain Was Poisoned

A different Storyline shows connections out to the adversary's address. Follow the URL events and the timing lines up with the delivery window.

The request is a POST to the OAuth token endpoint. Open the DNS events on that same Storyline, and the Microsoft login domain is already resolving to the adversary's address.

We can confirm token requests were issued while the poisoning was active, to a login domain resolving to the adversary. We cannot confirm what happened to them. Endpoint telemetry records the intended destination of a request, not the outcome of the TLS handshake. That handshake content is not something we have or can obtain.

Across the campaign there were 49 such requests. On one endpoint they began roughly 24 hours before any payload arrived, on another ten minutes before. Roughly half of the affected endpoints saw poisoning and no payload at all. That is a reasonable sign the malware was never the sole objective.

Storyline 3: The Verdict

It starts with the launch attempt, from the same browser process that had carried the operation from the start.

Static AI caught the download attempts, and the agent quarantined the file. On the launch attempt, the console records the payload blocked before launch and quarantined in under 100 milliseconds. It names the engine and the detection type on that event.

Earlier in the same sequence, Static AI convicted a .crdownload, the partial file a browser writes mid-download. That file was not named .exe, was not complete, and carried a partial hash rather than the payload's finished one.

Static AI read its structure and reached a verdict while the file was still arriving. It needed no signature, finished artifact, or lookup. The later (5) suffix shows the downloads kept coming. Nothing that landed ever ran.

Hunting for the Pattern, and the Identity Question the Endpoint Cannot Answer

Every behavioural signal missed at least one confirmed victim. Only two signals fired on every affected endpoint: the adversary's address and the poisoned DNS answer. Both depend on one address the operator can rotate at will.

Run these steps as a scheduled threat hunt rather than as a detection rule. Most of the work is correlation that costs something to run.

Primary Hunt: One Address Answering for Unrelated Domain Owners

Count distinct registrable domains (eTLD+1) spanning unrelated vendor ecosystems that resolve to the same public address. In our test against roughly ten thousand IPs and domains from affected environments, two surfaced, and both were the adversary.

1. Take DNS resolution events across the hunt window, keeping the queried name and the answered address.

2. Drop answers in private and carrier-grade ranges.

3. Reduce each queried name to its registrable domain using the Public Suffix List.

4. Group by answered address and count distinct registrable domains.

5. Map each registrable domain to its owning organisation and count distinct owners per address.

Step five separates a CDN from the adversary. An address answering for many domains owned by one organisation is a CDN. An address answering for many unrelated owners is not anything legitimate.

Counting raw answers instead fires on 389 of 9,375 addresses at a threshold of five. Azure Front Door and Cisco Umbrella top that list, and this hunt must never alert on that traffic.

Azure Front Door answers for azure.com, office.com, live.com, and microsoft.com. The adversary's address answered for Adobe, Apple, Akamai, AnyDesk, BeyondTrust, Brother, Microsoft, and roughly 128 others.

This hunt surfaced nearly a third of the endpoints we confirmed. No alert had flagged any of them. It runs across whole accounts, so it reaches machines beyond the ones you have already been handed.

Supporting inputs, weaker alone and useful in combination:

• An LLMNR response carrying a non-RFC1918 address. Expect travel noise, since some hotel and carrier networks hand out addressing outside RFC1918 that is odd but harmless.

• wpad.[your domain] resolving to a non-RFC1918 address.

• The connectivity-check URL in a browser command line, followed within sixty seconds by an executable or .crdownload in Downloads.

• Failed _ldap._tcp SRV lookups for your own domain controllers in the same window, placing the machine outside your own network.

If your staff roam, review the identity side for any suspected exposure window. Look for sign-ins from unfamiliar infrastructure, anomalous token issuance, and unexpected device registrations. Check there for what happened to the token requests.

Why the File Verdict Held

The agent convicted every copy of the file, on current and year-old agents alike. It did so while the adversary answered DNS for our own cloud endpoints in two regions. The network was the adversary's, down to the answer the agent received when it tried to reach its own console.

Static AI ships inside the SentinelOne agent. It reads a file's structure and reaches a verdict on the endpoint, without a signature update or a cloud round-trip. The Singularity™ Platform is built that way on purpose, because an agent cut off from its cloud needs a verdict.

APT29 showed here that it can cut an agent off from its cloud. Test what renders a verdict on your endpoints when the network is hostile and your console is unreachable. If it requires a lookup, that is your gap.

Third Party Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

Executive Summary

• Evaluating a security agent begins with defining the work it should perform and the evidence required to consider that work complete and accurate. Domain experts establish reference answers and grading criteria. 
• A successful approach must combine evaluations of complete runs alongside tests of individual competencies to both demonstrate whether a system is useful and help engineers identify what exactly to improve.
• Every material change to a model, prompt, tool, or workflow needs a measured comparison with the previous system. Operational failures supply new test cases, and fresh cases test whether improvements generalize.

In Part 1 of LLMs in the SOC, SentinelLABS examined the gap between cybersecurity benchmark scores and operational usefulness. In the months that have followed, we’ve observed those same design gaps in the flood of agentic systems hitting the market. This fail-fast development trend treats evaluation as a process that emerges after the proof-of-concept. In other words, teams build the system, demonstrate that it can work, and defer the harder task of establishing how reliably it performs and where it fails for a later date. 

This makes sense in the new world of rapid prototyping and AI experimentation. However, these systems are often brittle or only work until something in the environment changes or fails to generalize. This raises the urgent question, "How do I fix or improve this one behavior?" inside of a monolithic, non-deterministic pipeline.

For a system that will support security decisions, we believe the most important design choice is to make its performance measurable from the start. That means building the agent so that engineers can identify where an investigation goes wrong, test a correction, and verify that the change improves the complete workflow.

Consider a grounded example: an investigation agent that reviews an alert, queries the SIEM, and returns a verdict that matches an experienced analyst's. That looks like a success. On closer inspection, however, the query used the wrong device identifier and retrieved unrelated events. The verdict may be correct, but the records gathered during the investigation do not support the decision.

How would the team building that agent discover the mistake? And after fixing it, how would they know that the next model or harness update had not brought it back?

Start With the Work the Agent Should Complete

When building agents, attention often goes to the visible machinery: which model, which prompts, which tools, and so on. Those matter, but they're also some of the easier parts to modify. The part that's hardest to retrofit is the ability to answer two questions: is the system effective? And if not, what exactly do I change to make it better?

The industry has converged on this from several directions. Frontier lab engineering guidance observes that teams get surprisingly far on manual testing and intuition, but once an agent is in production, building without evaluations breaks down. Users report that the agent "feels worse" after a change, engineering scrambles to find out whether the claim has any validity, and it becomes difficult to tell real regressions from noise or to test changes against realistic scenarios before shipping [2]. For some the answer is what they label eval-driven development, scoped tests at every stage, before and during implementation, the way test-driven development writes tests before the code exists [3].

What that guidance usually leaves implicit is that evaluation discipline is an architectural decision. If you want to measure components individually with rigor, the agent has to be built out of individually exercisable competencies.

Before we choose a model or write a prompt, we need to define the work we expect the agent to do. For an investigation agent, that means reviewing an alert, gathering the evidence needed to understand what happened, and reaching a conclusion that the evidence supports. When it cannot resolve the case, it should give an analyst a clear account of what it found and what still needs investigation.

On Evaluations

"The first principle is that you must not fool yourself, and you are the easiest person to fool." – Richard Feynman

An evaluation is a way to measure a model's performance against a given scenario. More formally, every evaluation decomposes into a task (the point of indecision the system must reason through), a scenario (the environment wrapped around that task), and rubrics (how completion gets judged). This may seem simple on the surface, but LLM evaluations are an emerging discipline that every industry is struggling with. As the Pydantic team puts it, "Anyone who claims to know exactly how your evals should be defined can safely be ignored" [4]. A good eval set asks "what will a team use this for?" and ensures that the system gives them sufficient answers, and that it does so consistently.

End-to-End Evaluation: Does the System Perform?

An end-to-end evaluation runs the whole system on a realistic workload with grades as the final outcome. For an investigation agent, the natural frame is the human baseline it augments. A SOC analyst starts the day with a queue. Over a shift they work some number of alerts, dispositioning them into buckets (benign, suspicious, escalate, respond), and they end the day with a measurable amount of work left over. One metric that matches is burndown: of everything the system started with, how much still needs human attention? Alongside it sit the metrics that keep this burndown honest, such as disposition accuracy versus expert ground truth, time-to-verdict, stability, consistency, and cost per alert.

End-to-end metrics like these are often seen as the only metrics that matter. They tell a compelling story, they demonstrate that a system is worth building, and they're exactly the narrative that users want to hear. They also catch emergent failures such as compounding errors, context loss, and mis-sequenced steps that only show up when every component runs together against realistic inputs [2,6].

However, end-to-end metrics can aggregate away the information an engineer needs. When the overall performance is bad, or when it degrades after a change, it doesn’t provide any context about what went wrong. A regression in burndown could indicate one of many problems, meanwhile, all we can measure here is that suddenly we aren't performing. In a monolithic system, the only answer is to start reading traces and hunting for sources of failure.

Competency Evaluation: What Exactly Do We Fix?

To tackle that question we use the competency evaluation (elsewhere called component-level [6]). A competency evaluation isolates one skill and tests it directly, with its own specific inputs, definition of success, and a wide variety of different cases. These evaluations are helpful because they tell you whether a single part of a larger system is functional and capable across many scenarios. The inverse is also true, which is to say that it tells you which exact skills are underperforming.

End-to-End and Competency Evaluations: What Each Reveals

A mature program runs both continuously, and many teams add additional layers. For example, trajectory or trace evaluation, which grades the path the agent took rather than only the endpoints [2,6]. These evaluations are also critical, but this article specifically serves to spotlight the two defined above.

A Real-World Example

Take our Purple AI® Agentic Investigation agent as an example. When invoked, the system runs the investigation in the same way an analyst would. It pulls the surrounding evidence for an alert, enriches that evidence with additional data, forms and submits queries against the organizations telemetry, reasons over what comes back, and lands a verdict with the findings to support it. The tempting way to grade that answer is obvious, does the verdict match what an expert would have decided?

Very tempting, and also very dangerous. Suppose an agent agrees with the expert 95% of the time. That sounds strong, but the agent could just be pattern-matching on alert characteristics instead of actually retrieving evidence and building intermediate conclusions. A correct verdict reached for the wrong reasons is a failure, and only having a verdict-level score doesn’t tell us how we arrived at a conclusion. This is the same blind spot SentinelLABS identified in Part 1 - the unit of evaluation was more than often the answer to a question, as opposed to the path taken to reach it.

Decomposing the Problem

So, how do you evaluate competencies in this example? Start from the job you're trying to solve and decompose. On inspection, investigation hinges on many competencies. The agent has to form hypotheses worth testing given alert data and state from previous steps. It has to translate those hypotheses into correct and efficient queries against each data source, and it has to understand the schema of that source and what the fields it's filtering on actually mean. It has to interpret result sets, pick the next pivot, and know when the evidence is sufficient to stop. 

Each of these is a distinct competency that may be evaluated on its own. 

An (extremely abbreviated) tree:

Investigation 

├─ Hypothesis generation

├─ SIEM query construction (per-source eval suites)

├─ Investigation efficiency (tool-call budget)

├─ Adherence to organizational policy

├─ Confidence & evidence sufficiency judgment

└─ etc.

Now our evaluations can become concrete. "SIEM query construction" means many cases, each specifying an investigative intent, a target data source, and ground truth for what a correct query returns, graded automatically by running the query against representative data and comparing results, and backed by experts who wrote their own queries for the same asks.

For example, consider the device-ID failure we mentioned above. A competency case could give the agent an alert with a device ID and ask it to retrieve the related authentication events from a representative SIEM dataset. The case already defines which events a correct query should return.

If the agent queries the wrong identifier, it fails the case. The query may run successfully and return plausible data, but it does not return the expected events. This turns a failure that was previously hidden inside a successful investigation into something the team can measure directly.

Once the team fixes the problem, the case stays in the evaluation suite to ensure future changes to the system are consistently measured.

Even just a few dozen well-chosen evaluations per capability, drawn from real failures, can provide a strong initial signal. Each of these competencies gets its own suite since we know they are areas where models may struggle.

Where to Invest Evaluation Effort First

Not every node in the tree deserves equal attention. When setting up your own evaluations we suggest asking two questions:

Is this actually hard for models? Some competencies are commodities today. Summarization is the canonical example. Modern LLMs summarize nearly anything competently and the difference between a good and a great summary rarely moves outcomes. Contrast that with SIEM query construction, a real technical hurdle, with objective failure (the query is wrong, slow, or returns the wrong rows), high downstream impact (a bad query corrupts the whole investigation), and known model weakness on dialect and schema-specific syntax. An area that exhibits similar challenges is where your evaluation cases should go.

Can you define a defensible standard? Some competencies rely on direct checks against known facts, while others require expert judgement about whether an agent’s decision was justified by the evidence available. Evaluation effort pays off where success is decidable. Query construction has crisp ground truth (run it, compare results). Evidence-sufficiency judgment is softer, but experts mostly agree on clear cases, so a rubric plus expert-labeled examples works. Where even experts can't agree what "good" means, an eval suite just encodes noise. Before evaluating, you must first have a clear definition of success [10,11].

A useful heuristic is to simply combine the two and prioritize competencies by impact of failure × probability of model failure × decidability of ground truth. Wherever possible, look to grade binary pass/fail per case instead of arbitrary quality scores as binary judgments are easier for experts to make consistently, easier to trend, and harder to argue with [10]. If your system is already in the wild, you can still build cases - but we recommend you prioritize observed failures over successes [2,3].

The Value of Domain Expertise

Every competency evaluation needs to answer the question "what does good look like?" The person who can say whether a generated query succeeded (not just executed, but "all things considered, this is equal to or better than what I would have written in my day job") is the person who writes those queries well.

This is why many companies are spending heavily on contracted expert annotators. They're buying, at market rates and arm's length, the domain judgment that their evaluations require. In reality, most AI engineers are not domain experts, and many teams building agents don't have these resources in abundance. This is where being a company of cyber professionals is our advantage: for nearly any skill a security agent needs, someone here already performs it at an expert level daily. That expertise is the standard every one of our evaluations is built against.

When you identify a competency, identify its experts, understand how the work actually functions, and co-author cases with them. Evaluations built this way are true to real life, benefiting generalization when it reaches the field as it was tested against reality rather than the builder's imagination of what the field might look like.

Prove It Before Production

A well-built competency tree carries a risk because it makes the evaluation effort feel finished. However, evaluation is a constant game of discovering scenarios, hill climbing performance, and monitoring for regressions. Inside SentinelOne®, once an agent has been well-evaluated, it earns the chance to prove itself alongside real security work. 

At this stage, we actively execute solutions in parallel with working analysts in our internal SOC and Wayfinder Managed Services teams. When runs are flagged for review, an expert re-investigates the alert from scratch and establishes ground truth before reading the agent's verdict, so the reference standard can never be anchored by the machine it's meant to judge. 

Every interesting divergence becomes a new case, and every fix then has to beat the case that motivated it while not regressing against the larger suite. Only after our internal teams have thoroughly vetted an agentic offering in production does it reach anyone outside SentinelOne.

Underneath all of this effort sits one standard: in security response, unmeasurable capability is unshippable capability. An agent that cannot demonstrate exactly where it is weak cannot be trusted where it is strong. Autonomy in a SOC must be earned competency by competency, evaluation by evaluation, and finally in production, in front of the people who do the job.

References

[1] G. Bernadett-Shapiro and E. Garcia Lazo. LLMs in the SOC (Part 1) | Why Benchmarks Fail Security Operations Teams. SentinelLABS, January 2026.

[2] Anthropic. Demystifying Evals for AI Agents. Anthropic Engineering, January 2026.

[3] OpenAI. Evaluation Best Practices. OpenAI API Documentation.

[4] Pydantic. Pydantic Evals. Pydantic AI Documentation.

[5] OpenAI. Advancing the Price-Performance Frontier with GPT-5.6. OpenAI, July 2026.

[6] Confident AI. LLM Agent Evaluation Metrics: Tool Calling, Task Completion, Reasoning, and Trace-Based Evals. Confident AI, 2026.

[7] R. Aleithan et al. SWE-Bench+: Enhanced Coding Benchmark for LLMs. arXiv:2410.06992, 2024.

[8] Anthropic. Writing Effective Tools for AI Agents — Using AI Agents. Anthropic Engineering, 2025.

[9] Anthropic. Building Effective AI Agents. Anthropic Research, December 2024.

[10] H. Husain. Your AI Product Needs Evals. hamel.dev, 2024.

[11] A. Szymanski et al. Limitations of the LLM-as-a-Judge Approach for Evaluating LLM Outputs in Expert Knowledge Tasks. Proceedings of the 30th International Conference on Intelligent User Interfaces (IUI), 2025.

Third Party Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

The Endpoint: Why AI Must Be Governed By Something It Cannot Reach

This morning NVIDIA announced the NVIDIA Open Agent Safety Platform, with SentinelOne named as key collaborator. This new initiative is directly aligned with what I firmly believe is the key to effective security and governance of AI. It’s also what I believe will be required to truly secure an AI powered world. 

Every guardrail that exists today lives in software the model itself can reach.

The problem is simple to state and hard to solve. Models are aligned once and then run non-deterministically thereafter, increasingly at the endpoint and increasingly with the authority to act: in vehicles, industrial systems, humanoid robots, and agents with access to enterprise systems. Model alignment is checked before release, but nothing independently monitors the system at runtime.

Last week showed the risks. An AI agent in training at a frontier lab bypassed its network restrictions. Monitoring flagged it within 15 minutes. The automated kill switch failed, and it took two and a half hours to stop the run by hand. Watching is not enough if nothing independent can act.

An organization cannot reliably delegate consequential work to an agent without knowing what it is doing, whose authority it is exercising, and whether the boundaries around that authority actually hold. Those assurances require foundations throughout the infrastructure. One cannot depend solely on a model following instructions.

Out of the Model's Reach

Security has had a standard for this problem since 1972, when James P. Anderson's study for the U.S. Air Force defined the reference monitor. The mechanism that enforces policy must be tamperproof, must always be invoked, and must be small enough to verify. It remains the gold standard for enforcement architecture. A guardrail the model can reach fails the first test by definition. NVIDIA's own security engineers noted: "A control that the agent can decline to invoke is not an effective security control."

AI requires the same standard. A model must be governed by a layer that is separate from the intelligence it supervises and unreachable by it: one that runs in real time alongside the model and its compute, and that produces cryptographically attestable evidence of runtime behavior which operators, regulators, and insurers can independently verify.

A Foundation In Hardware

Today's announcement of NVIDIA's Open Agent Safety Platform is an important step toward the computing foundations that enterprise AI needs. Of its capabilities, hardware isolation and attestation are the most consequential. How the industry uses them, and what it builds on them, will determine their value.

The conviction behind this announcement is one I share with Jensen Huang: AI changes what the computing stack must provide for its behavior to be trustworthy. That requires a clear connection between the agent runtime and the protected infrastructure beneath it, in a cohesive stack where visibility and enforceable control underpin AI execution.

SentinelOne is committed to security rooted in hardware. NVIDIA's BlueField-4 places enforcement outside the host operating system, where tenant software cannot disable or bypass it. Together with other secure enclave architectures, it provides a way to secure the runtime directly from the hardware and to reduce the surface that must be secured to the hardware boundary itself. It also consolidates the cybersecurity stack: network, identity, data into the endpoint.

This is another step, and substantial work remains to build a truly secure architecture. The hardware boundary must itself be soundly secure, particularly where real-world applications are unforgiving. It must hold across deployment environments: enterprises and governments will use frontier AI services alongside workloads that must remain local, and their authority over data and actions must survive those transitions. And it must extend to any AI, on any compute that supports it.

The objective is clear. Anything that runs on a truly secure, hardware-rooted compute architecture should be provably governed, in the physical world and the digital one. Achieving that must also be simple, intuitive, and transparent to the end user. No one should need to understand attestation in order to benefit from it.

Verifiability

The broader question is how to govern action when agency is distributed across humans and machines. That comes down to six requirements.

• If a system cannot act in time, it does not matter. 
• If it cannot show the evidence behind its actions, it cannot be trusted. 
• If it cannot act independently when required, it cannot defend. 
• If it cannot stay within boundaries, it cannot be governed. 
• If its actions cannot be attributed, authority disappears. 
• And if accountability is lost, control is an illusion. That is ‘verifiable agency’.

What makes these requirements achievable is continuous behavioral visibility: the ability to observe, understand, and verify how actions are being taken across humans and machines in real time. 

SentinelOne was founded more than a decade ago on the conviction that behavior is the decisive signal, the only reliable way to distinguish the benign from the malicious at machine speed. Our behavioral AI is deployed at global scale today, protecting nearly one-fifth of the Fortune 500, and we are extending the same principle to make autonomous action verifiable, governable, and trustworthy.

In practice, this means AI operates at machine speed while every autonomous action remains traceable, auditable, and overridable by a human. AI provides scale, speed, and pattern recognition. Humans provide judgment, context, and the values these systems are expected to uphold. The arrangement is as much a matter of accountability as of engineering.

Certifiable and Insurable

Regulation, standards, and insurance are converging on the same requirement. Regulators will expect evidence of how AI systems behave at runtime, not only how they were aligned before release. Standards bodies will need a common basis for defining and measuring that behavior. Insurers will price risk against it. Attestation is the evidence all three will depend on. Within a few years, an AI product without attested runtime governance will be difficult to certify and difficult to insure, and more so for physical AI.

Building these foundations is the work SentinelOne is committed to. It will take sustained research and engineering across the stack, with claims of trust grounded in demonstrable behavior.

I congratulate the NVIDIA team. This is a meaningful commitment and an important milestone toward making increasingly capable AI truly governable, and toward making organizations willing to entrust it with work that matters.

On August 14, 2026, Alibaba released Qwen3.8-27B, a 27-billion-parameter open-weight model small enough to run on a laptop. Seventy-two hours later, the first fine-tune had already stripped its safety guardrails. On August 20, a researcher published an "abliterated" version, claiming, by his own testing, a 0% refusal rate across 842 prompts that safety teams are specifically trained to catch. A day after that, a demo of that stripped model running on a Mac, answering exactly the kind of request it was supposed to refuse, with no jailbreak engineering required, was making its way around the industry.

Near-frontier model capability is showing up on hardware anyone can buy within days of release. Months of a lab's safety work can be stripped out by someone else's side project just as fast. If you already have SOC data, and you already have engineers who can write a prompt, the AI SOC you'd otherwise buy starts to look like a sprint or two, not a purchase decision. That's why "let's just build our own AI SOC" sounds like a weekend project right now. 

The aspect often not considered is that the moment you stand up your own model, write your own routing logic, and point it at your own alert queue, you've accepted a job. Congratulations, you're now a security vendor. Any company that has ever sold you a SOC tool has accepted a long list of obligations on your behalf: supporting it, patching it, improving it, and acting on feature requests, the kind of list you rarely had to think about. Build your own version, and that list transfers to you, in full, starting today.

What follows is the fine print of what you have now accepted: the costs, the ceiling on how independent "truly DIY" really makes you, and the oversight that never gets to be optional. The goal here is not to settle a build-versus-buy debate. It's to contrast what any point on that spectrum actually puts on your plate operationally once AI enters the SOC, including how much of it remains human work, no matter who owns it.

Buy, Build, or Somewhere In Between

Buying a platform or building your own looks like a binary choice. It's actually a spectrum, and most organizations are already standing on a point along it without having picked that point on purpose. The hidden costs don't apply evenly across that spectrum. They change shape depending on where you land, and on how much sustained engineering investment security already gets inside your organization. A handful of teams have that investment. Most don't.

• Buy. A platform investigates, routes, and maintains itself on your behalf. You take on very little of what follows in this piece in exchange for working within the boundaries the platform sets. Which data sources it connects to, which models it has already vetted, and how quickly its roadmap moves relative to yours.

• Build-with. You orchestrate agents, MCP servers, or tools on top of infrastructure someone else still runs, patches, and keeps online. You gain real control over the workflow itself: how alerts are routed, what counts as a good verdict for your team, and what a playbook actually does, step by step. That maintenance burden simply relocates, moving from "who runs the model" to "who wires these pieces together correctly, and keeps them wired correctly as every piece changes underneath you." Layering AI on top doesn't fix a slow rate-determining step underneath it. Federated queries against a legacy SIEM architecture are still slow. A disconnect between identity and endpoint still delays remediation. And an agent that can't pull fresh forensic telemetry off an endpoint in real time is reasoning about stale information, no matter how good the model is.

• Truly DIY. Your own model, your own routing, your own infrastructure, built from the ground up. That last part reaches past the application layer, down to the hardware itself, the operating system running it, and every failure or patch cycle that comes with owning both. All of it is now yours to run and defend. Every decision is yours to make, which also means every consequence of that decision is yours to own, on a timeline nobody else is tracking for you.

From the ground up has a real ceiling, and it moves. The frontier you build against today won't be the frontier you're maintaining against once your stack is stable. Closing that gap every time a new model, a new attack pattern, or a new class of threat shows up is a standing commitment with no finish line, and that's a different kind of undertaking than the one-time build most teams picture when they say "truly DIY." Almost nobody actually gets to stop building. The real question is whether you're willing to keep chasing truly DIY indefinitely, on a timeline that resets every time the frontier does.

The far end always sounds smaller than it actually is. "Why not just put it in Amazon S3 with scheduled queries?" is a fair question, and also the first domino. The moment a scheduled query against a growing log store becomes part of your detection or investigation path, you've taken on retention design, query performance at scale, freshness lag, and a cron job as a piece of your incident response infrastructure. Nobody budgeted for that as a security commitment because it didn't arrive labeled as one.

The Job Description You Just Signed

These costs show up as dollars sometimes, but just as often, they show up as time and as coverage gaps that nobody notices until they matter. They don't all carry the same weight. Most of what follows is friction, real friction, the kind that slows a roadmap and eats afternoons, nights, and weekends. One of them is the one that ends up on a postmortem with your name on it.

The friction you'll live with day to day:

Model Choice and Routing

Picking wrong here doesn't announce itself. You find out weeks or months later, usually during an incident, that the model missed something a different one would have caught. Every model swap, frontier to open-weight to whatever ships next, adds a new maintenance task to every workflow already built on top of the old one, and catching a bad pick early means running your own ongoing benchmarking practice against your own data. 
Done well, this pays off. RouteLLM (ICLR 2025) showed that a router can cut costs by more than half while retaining roughly 95 percent of a flagship model's quality on standard benchmarks by sending easy queries to a cheaper model and reserving the expensive one for queries that actually need it. Routing has become its own layer of infrastructure. Whether you build that layer yourself, buy it, or inherit it through your vendor, someone still has to maintain it as the frontier moves.

Infrastructure

Every hop, from your log store to a model API to wherever the response lands, is a boundary you now have to account for, and every new integration adds another one. Hosting the model yourself means that infrastructure work lands on your team specifically. SentinelLABS, SentinelOne®’s threat research team, mapped 175,000 exposed Ollama hosts across 130 countries this year, many with tool-calling enabled, meaning code execution reachable from the open internet. That's the scale misconfigured self-hosting already operates at, in the wild, today.

Secrets management, API keys, service credentials, and model weights need their own rotation schedule that nobody enforces but you.

The Maintenance Surface Nobody Sizes Up Front

Every third-party feed, ticketing hook, or notification channel you wire up is an API you now watch indefinitely for breaking changes and schema drift. Permissions, guardrails, and injection defense for your own agent are now your responsibility. The routing logic, prompts, and evaluation harness usually live in one or two people's heads, and when they leave, the ability to safely change any of it leaves with them.

What You Trade Away 

Building your own tooling lets you tune it precisely to your own environment. The argument for a multi-tenant platform is that it improves for every customer by learning from one customer's incident, whereas a system built just for you only ever learns from you. Threat intelligence feeds are the usual attempt to buy back that value. Still, they trail disclosure by days or weeks, built from indicators already known and published, rather than from what another customer's environment just surfaced in real time.
Concretely, this means detection engineering is now a role someone on your team holds, whether or not anyone actually has that skill set. The open-source route is real and free, but it caps your detection quality at whatever the open-source community has already published, well short of what a platform learning from thousands of customers' incidents sees.

Detection engineering is one of several disciplines this plan usually assumes a single person covers. Model selection and evaluation are machine learning problems. Keeping a distributed system online under real alert volume is a production engineering problem. Guardrails, injection defense, and permissioning are their own specialty again. Vendors absorb this work the unglamorous way by staffing each of those functions separately and keeping them staffed. The DIY version usually assumes one very good engineer covers all four, indefinitely, on top of their existing job.

The One That Ends Up in a Postmortem

Availability and uptime, with no SLA to point to but your own. Long-term support is a permanent operating commitment starting day one. Zero Data Retention (ZDR) agreements with every model provider you route through, negotiated and tracked by you. Compliance posture, SOC 2, or whatever regime applies to your industry, becomes an obligation you own instead of something a vendor had largely absorbed for you.

The question that actually surfaces six months from now, usually at the worst possible time: when an incident happens, is your system's own trail forensically sound enough to support the investigation? Will it hold up to a regulator's or a cyber insurer's questions after the fact? Those are answers worth having ready long before an incident forces the question. 

The Slow Leak Underneath Both

Engineering time spent building and maintaining any of this pulls from everything else on the roadmap, and that opportunity cost compounds well past the initial build. The on-call rotation for a system that runs around the clock, the runbook that has to stay current as the system changes underneath it, and the ramp-up time every new engineer needs before they can safely touch routing logic someone else wrote months ago all surface the same way. A slower roadmap, quarter after quarter.

Coverage gaps open up on a similar rhythm, in the moments nobody plans for. Migrating between models usually means running two systems in parallel for as long as the migration takes, with the coordination overhead that entails. Patching requires a maintenance window, and a maintenance window means a gap in monitoring while it's open. A working, maintained system absorbs those gaps as part of the job it's already doing. Building your own means absorbing them yourself, on your own timeline, with your own team, every time.

Why This Argument Refuses to Pick a Model

Notice what's missing from all of that: a claim about which model is best, or what any of this costs. That's deliberate. The frontier will keep moving no matter what gets published this month, so any argument built on "our model beats your model" has a shelf life measured in weeks. The real question a SOC leader has to answer is who owns the complexity of managing that choice, forever, on top of everything else already on their plate.

That's also the honest answer to "but I can do it cheaper with self-hosted models." The price of a token was never the line item anyone forgot. It's usually the only line item DIY math accounts for. Everything in the section above is the remainder of the invoice, and none of it appears on a model provider's pricing page.

It's also why running a single frontier model for every step of an investigation is the wrong shape for the job, regardless of its cost. Most investigative steps don't need frontier-level reasoning, and treating every task as if they do is an architectural problem before it's ever a budget one. Specialized, right-sized models cost less and run faster without losing accuracy on the work that never needed a frontier model in the first place.

The Oversight You Still Have to Build

Even the best frontier models, under ideal conditions, still need a structured governance framework to remain trustworthy over the course of a long-running investigation. SentinelLABS put this to the test with a benchmark that ran leading frontier models through an eight-stage reverse-engineering exercise built from a real malware investigation. Only one model completed every stage, and even that run required a human to define the objective, control what evidence it saw, and hold final authority over the conclusion. The researchers' own term for the strongest outcome was "supervised investigative agency," not autonomous intelligence.

That's oversight of what a model does once it's running. A separate, harder question sits underneath it – whether the weights themselves can be trusted before you ever get to that point. That's its own problem worth its own treatment, and one this series will come back to.

It speaks to what frontier models need to be trustworthy in general, and the implication holds regardless of what you build on. Being impressive in a demo and being safe to run unsupervised for months are different bars. DIY means you're the one building the second bar, alone, with nobody checking your work until something goes wrong.

The Trailhead Sign

Plenty of teams have good reasons to build, and plenty of the considerations above apply, in some form, no matter what you choose. This is the sign at the trailhead: know what's on the trail before you're a mile in.

For most teams, the trail marked "truly DIY" dead-ends into build-with before it reaches full independence. That's still a real choice, worth making deliberately, it's just rarely the clean break from vendors it sounds like.

It's the same blind spot organizations keep hitting with AI more broadly. Mistaking today's friction for tomorrow's safety, when the friction is often the only thing keeping a bigger problem out of sight.

A SOC can't run on vibes, and neither can the decision to build one. Every item above is a real, ongoing commitment with a name attached to it inside your organization, whether you wrote that name down when you started or not. AI changes how much of this work exists and who ends up doing it. It's still human work, whether it happens on your payroll or a vendor's.

Buy, build-with, or truly DIY. Three lanes, and most teams land in one of them by accident rather than by decision. Worth asking: where are you today, and was that a deliberate call or a default?

Answer that honestly now, and the job description doesn't surprise you in six months. Answer it by accident, and it will.

Third Party Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

The question has shifted. Security leaders spent several years debating whether AI would reshape security operations. That debate has settled. Now the conversation is about pace. How fast can the foundation be built, and what do organizations that moved early have to show for it?

For the second year, SentinelOne® commissioned 451 Research to survey 611 North American cybersecurity decision-makers and practitioners on the state of security operations strategy. The results confirm what we’ve been building toward, and they surface a finding that should recalibrate how most security leaders sequence their AI investments.

The Returns Didn’t Wait for the Roadmap

Many product roadmaps assume a clear sequence and start with building toward higher maturity first with returns following. The data shows that AI is running ahead of schedule.

Nearly all organizations surveyed (96%) are still operating AI at the earliest maturity levels:

• Level 1: Basic monitoring; triage specialist/alert analyst
• Level 2: More senior triage analyst / basic incident responder and investigator

By most measures, AI adoption in the SOC is still early. And yet, 99% of those same organizations already report improvements in incident response and remediation.

The numbers are consistent. Early-stage AI (chatbots handling initial alert triage, automated tools sorting true positives from noise) is delivering before organizations reach advanced maturity. The gap between where most organizations are and what they are already getting is real and consistent across survey respondents.

Organizations waiting for higher AI maturity before building the supporting infrastructure are running the sequence backward. The returns are available now. The foundation built today determines how far those returns scale.

Platformization Has Reached A Verdict

The organizations accelerating AI adoption are also the ones consolidating onto platforms. A platform-oriented security architecture means moving from siloed, specialized tools to an integrated stack built on a foundation that coordinated AI decision-making can actually run on, and one that lets each new capability compound on the last.

The platformization numbers from this year’s survey are clear. 82% of organizations describe themselves as platform-oriented, a 13-point jump in a single year, and 94% expect to be there within three years.

A common assumption is that platform adoption means replacing specialized tools. The data complicates that picture. The same technologies most frequently deployed as standalone tools (EDR, SIEM, CNAPP) are also the top anchors for integrated platforms. Organizations typically start with one of these and expand outward. What changes is the common data layer that enables coordinated AI decision-making, serving as the connective tissue underneath.

Platformization is not coincidental with AI’s emergence. Agentic AI needs connected, continuously updated data to accurately reason across signals and take autonomous action. Fragmented architectures, where telemetry is siloed and pipelines require manual effort, cannot support AI-driven SOC operations at scale. Platform adoption and AI adoption are converging because AI’s data requirements have made integration a structural necessity.

The survey makes the infrastructure connection an explicit one. The top-cited benefit of investing in a data lake for SecOps is supporting AI-driven SOC workloads and agents. Organizations that built the data foundation early have already cleared the barrier stalling others. Those who haven’t, face a prerequisite gap, and the distance is widening rapidly. Architectural readiness is the variable that determines how far AI investments can scale.

Job Satisfaction Is Rising

Every discussion of AI in the SOC centers on detection and response metrics. This report has those too, but there is a finding that security leaders managing attrition should weigh: analyst burnout is declining.

As AI handles repetitive, high-volume triage work, analysts report rising job satisfaction. The role is shifting away from processing an endless queue and toward investigation, threat hunting, and judgment-intensive work. In a market where SOC analyst turnover remains a persistent operational cost, that shift carries real dollar value.

The analyst role evolves, becoming more strategic and more consequential.

A New Attack Surface

The same AI systems changing how SOCs operate are also creating new targets. Adversaries are already probing AI infrastructure including agents, data pipelines, model endpoints, and the governance gaps that emerge when controls lag behind adoption. The report surfaces this tension clearly: Organizations are deploying AI faster than they are securing it.

An AI agent with misconfigured access or an unmonitored data pipeline is an exposure. Securing the AI infrastructure that powers the SOC is happening alongside deployment, whether organizations have planned for it or not. Those without a clear governance posture are accepting risk that may not be priced into their AI investment case.

The potential of GenAI and agentic AI in the SOC is already being realized. The organizations that capture it fully are those building governance alongside deployment. The platform that runs the Autonomous SOC and the platform that secures it are, increasingly, the same platform.

SentinelOne’s Vision: The Autonomous SOC

Everything the report surfaces, from AI returns arriving before maturity to platform consolidation to the improving analyst experience, points to how these are expressions of the same shift. The foundation that enables early AI returns is the same one that determines how far those returns scale, how capable analysts become, and how well the security of AI itself is governed.

The findings align with how SentinelOne has defined the path to autonomous security operations: A progression from AI-assisted triage at early maturity levels to increasingly autonomous investigation, threat hunting, and response, with humans in strategic and governing roles. The report validates that the market is moving through exactly that sequence. Organizations that understand the architecture behind it (the platform integration, the common data layer, the governance controls) are positioning themselves to capture returns at every stage rather than waiting for the destination.

The full 451 Research report goes further into detail, covering what progression looks like at each maturity level, the specific barriers organizations are encountering, and the data behind each finding in full.

Read the full 451 Research report to learn more about how AI is reshaping cybersecurity.

Third-Party & Intellectual Property Disclaimers

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.

AI agents have made their way into virtually every layer of your environment. They run in the apps your employees adopt, on the endpoints where agents execute code, as users with access privileges those agents borrow, and in the cloud workloads that scale them. The platform that you trust to secure your endpoints is already already covering where AI operates today.

Here is the through-line that makes this one problem instead of four. Every AI attack starts as an interaction and ends as an action. A prompt gets manipulated, an agent gets tricked, and the damage lands on a host, reaches into an identity, or moves through the cloud. The tools that treat each surface as a separate product hand you fragments. SentinelOne treats them as one chain.

How SentinelOne Defends the Agentic Stack Today

Employee AI use is where the risk quietly enters. Your people are already using AI tools you never sanctioned, through browser, IDE, and API-connected apps and agentic AI tools. SentinelOne discovers that shadow AI use across browsers, IDEs, and copilots, highlights which tools and models are in play and governs it with policy. It keeps confidential data, PII, and secrets from reaching untrusted models, and it stops prompt injection and jailbreaks aimed at the tools you build. Legacy DLP reads patterns; this reads context, which is the only way to catch an attack aimed at AI systems that behave in a non-deterministic way.

The agent layer is where AI stops advising and starts acting. An employee’s prompt sends text. An agent sends commands, holds credentials, calls APIs, and chain actions without a human approving each step. That makes them non-human identities with standing access. SentinelOne governs that access. It inventories the agents and MCP servers already operating and scores what each one can reach and holds every agent to the privileges its task requires. Then it inspects the tool calls themselves, so an injected instruction gets blocked at the moment it would execute. What gets executed lands in a searchable record, and the same enforcement doubles as a kill switch.

While governance decides what an agent is allowed to do, the endpoint is where you find out what it actually did.

The endpoint is where agents execute. This is the frontier, and where SentinelOne has protected customers for over a decade. Our behavioral engine judges what a process does, not what it claims to be. That is how we caught QUIETVAULT – malware that spins up AI agents in “yolo” mode to exfiltrate secrets to GitHub. It is how we autonomously stopped the LiteLLM supply chain attack, where adversaries weaponized the Claude CLI to install a malicious payload. It is how we surfaced a DLL side-loading attack hidden inside an AI tool installer. Real detections, on the endpoint, today. Agents run on the host, and so do we.

The identity is where a hijacked agent runs next. Picture an employee’s AI coding agent that gets hijacked mid-task. It spawns a shell and reaches for cached credentials and cloud session tokens, trying to stop being a process and start being the user. That pivot to identity is what unlocks lateral movement, and it is where most AI attacks are headed. SentinelOne meets the move. It secures human and non-human identities alike, and seeds the environment with decoy credentials and honeytokens no legitimate user ever touches. The instant the hijacked agent grabs one, the trap trips, and Identity responds by forcing an MFA re-challenge, disabling the account, or isolating the host. Authorization at login is not enough. Access gets validated against behavior and pulled at runtime.

The cloud is where AI workloads scale. Consider an internal AI agent running in a Kubernetes cluster with standing access to a customer database. Security teams keep asking the same question about deployments like this. Where is the model connecting, and who is it talking to? SentinelOne answers with eBPF-native runtime protection that judges how the workload actually behaves, and flags the moment that inference service reaches an endpoint it has never touched before. It covers the control plane the deployment depends on, the secrets it reads, the pipelines it runs through, and the data it can access. Defending the AI you build takes more than watching it, it takes action on the workload in real time.

SentinelOne’s Singularity Platform Advantage

Each of these surfaces matters on its own. What closes the kill chain is following an attack across them without losing it at the handoff. This is where a single platform earns its keep. AI telemetry already streams into the Singularity™ Data Lake, alongside the endpoint data the platform has correlated for years. As identity and cloud signals join that same view, an analyst follows one attack from first prompt to final action, without stitching logs across six tools at two in the morning. A manipulated prompt, the process it spawns, the credential it reaches for, and the cloud resource it targets read as one story rather than six disconnected alerts.

Detection that only watches is observation. Runtime action is protection. When the Singularity Platform acts, autonomous response blocks the execution, rolls back the change, and revokes the access at the point of impact, without a human relaying orders between consoles. This is the difference between whether an attack is stopped or just gets logged.

That is the case for securing AI inside a platform built for autonomous runtime response. We are not adding a console to chase AI, we are extending the one already deployed where your agents run.

Questions to Ask When Assessing Your AI Security Options

When evaluating AI security, ask yourself three things.

• Does the solution protect the endpoint where agents actually execute, or is it a roadmap item?
• When a hijacked agent pivots to credentials and the cloud, does that telemetry land in the same platform, or are you manually connecting dots across three dashboards?
• Can the solution act at the moment of execution, or only tell me what already happened?

SentinelOne protects the surfaces where AI runs today. This includes the apps your employees use, the agents they deploy, the endpoints where agents execute, the identities they borrow, and the cloud where they scale. One platform, built for autonomous response. While AI has changed the attack, it does not have to change your architecture.

See it for yourself. Talk to our team about securing AI across your endpoints, identities, cloud, and the AI apps your employees already use, all from the platform you run today. Contact SentinelOne today.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

The question has shifted. Security leaders spent several years debating whether AI would reshape security operations. That debate has settled. Now the conversation is about pace. How fast can the foundation be built, and what do organizations that moved early have to show for it?

For the second year, SentinelOne® commissioned 451 Research to survey 611 North American cybersecurity decision-makers and practitioners on the state of security operations strategy. The results confirm what we’ve been building toward, and they surface a finding that should recalibrate how most security leaders sequence their AI investments.

The Returns Didn’t Wait for the Roadmap

Many product roadmaps assume a clear sequence and start with building toward higher maturity first with returns following. The data shows that AI is running ahead of schedule.

Nearly all organizations surveyed (96%) are still operating AI at the earliest maturity levels:

• Level 1: Basic monitoring; triage specialist/alert analyst
• Level 2: More senior triage analyst / basic incident responder and investigator

By most measures, AI adoption in the SOC is still early. And yet, 99% of those same organizations already report improvements in incident response and remediation.

The numbers are consistent. Early-stage AI (chatbots handling initial alert triage, automated tools sorting true positives from noise) is delivering before organizations reach advanced maturity. The gap between where most organizations are and what they are already getting is real and consistent across survey respondents.

Organizations waiting for higher AI maturity before building the supporting infrastructure are running the sequence backward. The returns are available now. The foundation built today determines how far those returns scale.

Platformization Has Reached A Verdict

The organizations accelerating AI adoption are also the ones consolidating onto platforms. A platform-oriented security architecture means moving from siloed, specialized tools to an integrated stack built on a foundation that coordinated AI decision-making can actually run on, and one that lets each new capability compound on the last.

The platformization numbers from this year’s survey are clear. 82% of organizations describe themselves as platform-oriented, a 13-point jump in a single year, and 94% expect to be there within three years.

A common assumption is that platform adoption means replacing specialized tools. The data complicates that picture. The same technologies most frequently deployed as standalone tools (EDR, SIEM, CNAPP) are also the top anchors for integrated platforms. Organizations typically start with one of these and expand outward. What changes is the common data layer that enables coordinated AI decision-making, serving as the connective tissue underneath.

Platformization is not coincidental with AI’s emergence. Agentic AI needs connected, continuously updated data to accurately reason across signals and take autonomous action. Fragmented architectures, where telemetry is siloed and pipelines require manual effort, cannot support AI-driven SOC operations at scale. Platform adoption and AI adoption are converging because AI’s data requirements have made integration a structural necessity.

The survey makes the infrastructure connection an explicit one. The top-cited benefit of investing in a data lake for SecOps is supporting AI-driven SOC workloads and agents. Organizations that built the data foundation early have already cleared the barrier stalling others. Those who haven’t, face a prerequisite gap, and the distance is widening rapidly. Architectural readiness is the variable that determines how far AI investments can scale.

Job Satisfaction Is Rising

Every discussion of AI in the SOC centers on detection and response metrics. This report has those too, but there is a finding that security leaders managing attrition should weigh: analyst burnout is declining.

As AI handles repetitive, high-volume triage work, analysts report rising job satisfaction. The role is shifting away from processing an endless queue and toward investigation, threat hunting, and judgment-intensive work. In a market where SOC analyst turnover remains a persistent operational cost, that shift carries real dollar value.

The analyst role evolves, becoming more strategic and more consequential.

A New Attack Surface

The same AI systems changing how SOCs operate are also creating new targets. Adversaries are already probing AI infrastructure including agents, data pipelines, model endpoints, and the governance gaps that emerge when controls lag behind adoption. The report surfaces this tension clearly: Organizations are deploying AI faster than they are securing it.

An AI agent with misconfigured access or an unmonitored data pipeline is an exposure. Securing the AI infrastructure that powers the SOC is happening alongside deployment, whether organizations have planned for it or not. Those without a clear governance posture are accepting risk that may not be priced into their AI investment case.

The potential of GenAI and agentic AI in the SOC is already being realized. The organizations that capture it fully are those building governance alongside deployment. The platform that runs the Autonomous SOC and the platform that secures it are, increasingly, the same platform.

SentinelOne’s Vision: The Autonomous SOC

Everything the report surfaces, from AI returns arriving before maturity to platform consolidation to the improving analyst experience, points to how these are expressions of the same shift. The foundation that enables early AI returns is the same one that determines how far those returns scale, how capable analysts become, and how well the security of AI itself is governed.

The findings align with how SentinelOne has defined the path to autonomous security operations: A progression from AI-assisted triage at early maturity levels to increasingly autonomous investigation, threat hunting, and response, with humans in strategic and governing roles. The report validates that the market is moving through exactly that sequence. Organizations that understand the architecture behind it (the platform integration, the common data layer, the governance controls) are positioning themselves to capture returns at every stage rather than waiting for the destination.

The full 451 Research report goes further into detail, covering what progression looks like at each maturity level, the specific barriers organizations are encountering, and the data behind each finding in full.

Read the full 451 Research report to learn more about how AI is reshaping cybersecurity.

Third-Party & Intellectual Property Disclaimers

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.

The security industry spent the last decade solving detection. Endpoint. Cloud Workloads. Identities. AI. We built better models. We moved beyond signatures. We reduced false positives. We got the alert into the right queue. Then, we discovered the harder problem had been waiting behind it.

The constraint in every SOC today is not detection. It’s investigation capacity. Security teams are generating more critical alerts than any staffing plan can possibly accommodate. The queue grows. Triage waits on analyst availability. Coverage drops on nights, weekends, and surges, exactly when adversaries know to move.

Frontier AI is about to make this exponentially worse. The same models reshaping every industry are being weaponized to chain hidden gaps and vulnerabilities, accelerate attacks, and compress attacker timelines. Investigation cannot stay a human-paced or human-scaled activity. If it does, defenders lose. We built Purple AI® to change that.

Every Alert. Investigated. Now.

Starting today, we’re opening up Purple AI Agentic Investigation to all new and existing SentinelOne® EDR customers. In the Singularity console. Activated with a single click.

The moment a new EDR alert is flagged Critical and Malicious, Purple AI acts, using flags you can trust. It is the output of over a decade of AI and ML models running natively at the edge, from behavioral analysis to real-time threat intelligence. Purple AI investigates signal vs. noise.

It collects evidence. It correlates telemetry across endpoint, identity, cloud, and third-party data. It builds the attack timeline and delivers a verdict: True Positive, False Positive, or Unknown. The complete evidence chain arrives with it before an analyst opens the console. We call it ‘zero-click’ investigation: Automated trigger, zero wait, coverage gaps closed.

Open the Alerts view, and you see it live: Purple AI retrieving context, running threat hunts, querying host telemetry, building the investigation in real time. Then, the verdict lands, supported and traceable, ready for a decision. This is investigation at machine speed. Continuous. At scale. Integrated into existing workflows.

The Native Platform Advantage

Purple AI investigates at this depth because it operates natively on the Singularity Platform. Zero integrations required. Where your team already works. Where your security data already lives.

Bolt-on AI tools layered onto other platforms start from a disadvantaged position. They require connectors, data mapping, and integrations before they can reason. Purple AI reasons directly on telemetry already in Singularity: endpoint, identity, cloud, and third-party data in the Singularity Data Lake. Nothing to configure. One click to activate.

The intelligence is distinct. Purple AI takes a multi-model approach that keeps customers at the edge of frontier AI reasoning capability. Models from leading frontier providers like Anthropic (Claude) and OpenAI (GPT) are part of that architecture. So is SentinelOne’s own Ultraviolet family of models, purpose-built on petabytes of real security telemetry and trained for SOC investigation reasoning. Here, frontier AI reasoning combines with Autonomous Security Intelligence.

Autonomy With Accountability

Agentic AI without defined limits and guardrails is a liability. As an AI-first company, we get that. So we built the limits first. Investigations run autonomously. Response stays on your terms. You decide your human-in-the-loop comfort zone.

Every verdict connects to one-click or policy-driven response actions in Singularity, including governed automated execution through Hyperautomation, SentinelOne’s workflow automation layer. Nothing fires outside the guardrails your team defines. Activation is admin-controlled and reversible at any time. Access is role-based. Every verdict carries a complete, auditable evidence chain. We’ve eliminated black-box decisions. Your analysts can see and review every AI step. The agentic SOC keeps humans in control of what happens next, by design.

What Customers Are Doing With It

Purple AI customers are already seeing the shift. Agentic Investigation is built to extend it further.

AI designed to give human defenders a decisive operating advantage. The machine removes the ceiling on what humans can cover.

Singularity Credits

Alongside Agentic Investigation, we are introducing Singularity Credits: a new unified currency for AI-powered workflows across the Singularity Platform. AI should be accessible. Utilization should be visible. Spending stays in the hands of those who set the limits. Credits are built around all three.

Every eligible SentinelOne customer gets free access starting this week. No payment method required. After the trial, Credits are available through partners, direct billing, and eCommerce channels. The balance is visible in real time. Built-in spending controls keep consumption bounded.

Agentic SOC, Autonomous SOC, AI SOC, ISOC: Call it what you want. Just don’t call it a roadmap item.

What we are delivering today is real, accessible and, for the next couple of months, complimentary. It is the agentic SOC in operation. GA, now. Critical alerts automatically investigated. Verdicts autonomously reached. Workflows automatically triggered. Governed authorization. Responses that execute within the policies your team controls and human-in-the-loop gates that your team decides.

The industry has called this many things: The Autonomous SOC, the Agentic SOC, the AI SOC. Gartner now has a name for this model: the Integrated Security Operations Center. Modern threat detection, investigation, and response as a single, continuous, AI-driven loop vs. the historic siloed functions and tool sprawl. More than solving alert fatigue, the new model has the potential to solve the investigation capacity gap and shrink MTTR to a scale and speed that cybersecurity will require in the frontier AI era. At SentinelOne, we have been building for this moment for years.

Investigation capacity should never again be the reason a critical alert goes unexamined. Frontier AI belongs where the data and the analysts already are: In the console, in the workflow, governed by the human customer. We put it there.

Activate Purple AI Agentic Investigation in your Singularity console or visit s1.ai/agentic.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

Enterprise adoption of Claude across teams, workflows, and business functions is happening at a pace unlike virtually any technology before it. While the innovation opportunity is obvious, so are many of the risks. From the exposure of sensitive data and secrets through shadow IT to new attack vectors like prompt injection, security teams need the visibility, governance, and response capabilities to ensure AI innovation is done safely and securely.

SentinelOne® helps organizations comprehensively secure Claude adoption by bringing AI usage directly into the security platforms teams already rely on. This helps protect the entire ecosystem from the underlying infrastructure to the application layer and end-user interactions. By bringing together SentinelOne and Claude, security teams can apply policies to user prompts, ingest Claude activity into the Singularity AI SIEM for investigation, and utilize frontier AI-powered services to identify real-world risks before attackers can exploit them.

Govern, Detect & Secure with SentinelOne’s Anthropic Compliance API Integrations

Security and compliance platforms utilize the Claude Compliance API to help organizations monitor AI activity within their existing tools. SentinelOne provides purpose-built Claude Compliance API integrations for its Prompt Security and Singularity AI SIEM offerings.

Prompt Security Integration

Scan AI prompts and responses against enterprise policies to flag violations without requiring a browser extension or endpoint agent. This agentless approach helps organizations extend their security coverage to unmanaged devices and external environments. Prompt Security enforces safe use by blocking high-risk prompts and preventing data leakage in real time. Additionally, the platform provides continuous risk assessment for agentic AI by securing Model Context Protocol (MCP) gateway connections between AI applications and known MCP servers.

Singularity AI SIEM Integration

Ingest audit and activity data directly from Claude rather than treating AI interactions as isolated events. With the integration, security operations center (SOC) teams can correlate Claude activity against existing security telemetry. This allows analysts to incorporate AI usage data into their broader security workflows and improve investigation, detection, and response across all their attack surfaces.

AI Visibility to AI-Ready Defense with Wayfinder Frontier AI Services

The partnership between SentinelOne and Anthropic extends beyond the Compliance API. SentinelOne has been a participating member in Anthropic’s Project Glasswing and has had early access to Anthropic’s most capable Mythos-class models. By continuously testing these models against real-world security workflows, SentinelOne helps ensure defenses keep pace with the modern adversary. Additionally, SentinelOne recently announced Wayfinder Frontier AI Services, a managed offering that pairs elite human security experts with frontier models, including Anthropic’s Claude Security.

Frontier AI is changing vulnerability discovery, giving both defenders and attackers the advantage of speed and scale. However, raw vulnerability counts rarely map cleanly to real-world risk, as many theoretical exposures are mitigated by existing architectural controls. Wayfinder Frontier AI Services evaluates findings against actual environmental context to deliver an exploitability-grounded prioritization. Instead of treating vulnerabilities in isolation, the service maps how exposures connect into end-to-end attack paths.

The Frontier AI models then provide targeted remediation guidance, including architectural changes or identity controls, designed to break the exploitation chain where it costs the adversary the most. With the service providing a continuous human-and-AI partnership across endpoint, cloud, identity, data, and AI attack surfaces, Frontier AI ensures that organizational security posture remains current as models and threats evolve.

Why SentinelOne is Built for the AI Security Era

SentinelOne operates from a clear conviction: A safer future for humanity and to give the advantage to those who secure our future. That conviction is what drives how SentinelOne approaches AI security — not as an isolated capability, but as part of the autonomous platform, expert services, and SOC workflows that defenders already use. SentinelOne has collaborated with frontier AI labs for years, including Anthropic, OpenAI, and Google DeepMind. These partnerships inform the capabilities embedded across the SentinelOne platform.

Operating at machine speed is necessary to counter modern threats, rather than relying strictly on manual triage. Over the past quarter, the SentinelOne Singularity Platform autonomously blocked novel zero-day and supply-chain attacks against widely used components, such as LiteLLM, Axios, and CPU-Z. Wayfinder Frontier AI Services takes this operational model further left in the security lifecycle to discover exposures before attackers can leverage them. This multi-model foundation reflects the understanding that no single AI model is the definitive answer for cybersecurity; the advantage belongs to defenders who can orchestrate the right intelligence and validate outputs with human expertise.

This is how SentinelOne enables business growth and innovation safely, giving security teams the ability to say yes to AI adoption while maintaining full control of the risk surface. Stronger protection with fewer incidents and less operational overhead.

Learn More

Ready to adopt Claude safely across your organization? Connect with SentinelOne to learn how Prompt Security, Singularity AI SIEM, and Wayfinder Frontier AI Services help security teams govern, monitor, and defend AI usage at enterprise scale.

• For Claude governance and monitoring: Contact SentinelOne to learn about the Anthropic Compliance API integrations for Prompt Security and Singularity AI SIEM.
• For proactive AI-driven exposure management: Learn more about Wayfinder Frontier AI Services.
• For broader AI security: Request a demo of SentinelOne’s AI security capabilities.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

Agentic AI is no longer theoretical. It’s already embedded across enterprises inside developer workflows, SaaS platforms, and operational pipelines. It is executing tasks, chaining actions, and interacting with critical systems at machine speed.

What makes this shift different from previous waves of automation is not just capability, it’s autonomy. These systems don’t wait for step-by-step human instruction. They interpret goals, break them into subtasks, and execute independently across tools, data, and environments. That autonomy is powerful, however it’s also introducing a new class of security challenges that traditional controls were never designed to handle.

Most organizations today lack visibility into where agents are running, what they can access, and what actions they’re taking. Even fewer have the ability to enforce policy or intervene in real time. As a result, agent adoption is accelerating faster than the security models required to govern it.

To adopt agentic AI safely, SentinelOne® is helping organizations rethink security from the ground up starting with how agents behave, what they can reach, and how their actions are controlled. The newly released Prompt for Agentic AI Security enables organizations to move from reactive oversight to proactive governance, meaning teams can deploy agents with confidence.

When AI Doesn’t Just Respond—It Acts

Agentic AI interactions have a technical distinction that fundamentally changes the security equation. Unlike traditional AI systems that generate outputs in response to prompts, agents are designed to execute. They receive a goal, decompose it into subtasks, and carry out actions across systems, often without per-step human approval. They hold credentials, make API calls, modify data, and interact with business-critical platforms in real time.

They can read files, execute code, send messages, and trigger workflows—all autonomously. This shift from “response” to “execution” introduces three distinct categories of risk.

1. Construction-Time Risk: How Agents Are Built

Many risks are introduced before an agent ever runs. Agents are often deployed with overly permissive IAM roles, granting access far beyond what their tasks require. They rely on third-party skills and plugins pulled from public repositories, creating a new supply chain surface with little verification. In many cases, API keys and secrets are hardcoded directly into configurations, making compromise trivial. At this stage, the issue is not behavior, it’s exposure.

2. Runtime Risk: What Happens When Agents Execute

Once deployed, agents introduce dynamic, real-time risks that traditional controls struggle to detect. Prompt injection attacks can manipulate agent behavior in ways that trigger real-world actions and not just incorrect outputs. A malicious instruction embedded in a document can become an execution command. Agents may also chain together individually authorized actions that, in sequence, produce unauthorized outcomes. Data exfiltration can occur through legitimate-looking API calls as part of “completing a task”. At runtime, the line between intended behavior and malicious activity becomes blurred.

3. Operational Risk: The Gaps Around the System

Even when risks are understood, most organizations lack the operational controls to respond effectively. There is often no kill switch to stop a misbehaving agent in seconds. No rollback capability to recover from corrupted data. No audit trail to reconstruct what an agent actually did. And no incident response playbook designed for machine-speed, autonomous actions. These gaps compound the risks introduced at every other stage.

From Blind Trust to Verified Control: The Evolution of Agent Security

As autonomous agents continue to move quickly from experimental tools to core infrastructure, security has lagged behind. Most frameworks still operate on implicit trust: trust in downloaded skills, trust in evolving prompts, and trust that agents will behave safely despite increasing autonomy. That assumption is already proving flawed.

Recent discoveries of hundreds of malicious agent skills circulating through public repositories highlight how easily these ecosystems can be exploited. Disguised as legitimate utilities, these components harvested credentials, secrets, and sensitive data at scale. This is a structural problem. Since agentic systems are dynamic by design, they pull external dependencies, adapt behavior over time, and execute across systems with minimal oversight. Traditional security models were not built for this.

Introducing Prompt for Agentic AI Security

Now, AI agents are already operating inside your organization—reading files, calling APIs, and chaining actions across critical systems without human approval at every step. They are non-human identities that reason, decide, and execute at machine speed.

Prompt for Agentic AI Security is SentinelOne’s agent security layer. This first phase provides real-time discovery and governance control plane designed specifically for this new reality as well as a full visibility Model Context Protocol (MCP) server across your environment, along with the ability to assess risk, enforce policy, and remediate automatically before unauthorized actions occur.

Unauthorized actions can be stopped at the moment they occur, not after damage is done. As agent adoption grows, organizations gain a centralized control plane to manage sprawl and maintain compliance. Most importantly, security becomes an enabler of speed rather than a barrier to it.

The following capabilities will be available as part of the first phase of this release. Starting with MCP, the protocol powering the rise of agentic AI.

• MCP Discovery and Governance: surface every MCP server in your environment, sanctioned or shadow
• Risk-Based Enforcement: assess and score each server’s threat profile before agents act
• Runtime Prompt Injection Blocking: inspect tool calls and agent interactions in real time, stopping attacks at the moment of execution
• Malicious Server Prevention: identify and block malicious MCP servers from operating in your environment

How to Adopt AI Agents Safely: A 90-Day Plan

Adopting agentic AI safely requires structure. A practical approach is to move in phases: first gaining visibility, then enforcing guardrails, and finally building operational capability.

Days 1–30: Discovery and Inventory

Start by understanding what exists. Audit browser extensions, analyze network traffic to known AI services, and review OAuth grants for third-party integrations. These steps provide an initial baseline, but they won’t capture everything.

• Deploy Prompt for Agentic AI Security to automatically discover MCP activity, including shadow deployments, local processes, and embedded agents inside developer tools.
• Map not just what agents exist, but what they’re connected to. Identify which systems they can access, what permissions they hold, and what actions they can take.
• Prioritize agents based on risk—those with access to production systems or sensitive data should be investigated first.

The goal: A live, risk-scored inventory of every agent and its blast radius.

Days 31–60: Guardrails and Control

Next, enforce boundaries. Route agent interactions through controlled pathways like an MCP gateway to inspect and enforce policies in real time.

• Configure allow/block rules based on user, agent, and action type to enforce least privilege.
• Enable content inspection to prevent sensitive data from entering execution pipelines. At the same time, provide sanctioned tools and frameworks so teams have secure alternatives.
• Establish a clear, simple acceptable use policy for agents—covering approved tools, prohibited data, and escalation paths.

The goal: Real-time enforcement and safe pathways for adoption.

Days 61–90: Operational Readiness

Finally, build the ability to respond. Integrate agent telemetry into SOC workflows and establish behavioral baselines.

• Use enforcement controls as a kill switch to stop anomalous activity instantly.
• Run tabletop exercises to test detection, containment, and recovery. Ensure teams can answer “what did this agent do?” in seconds—not days.
• Document an AI-specific incident response playbook and establish continuous review of agent permissions using dynamic risk scoring.

The goal: Full operational capability to manage agent-related incidents.

Conclusion

Agentic AI is not slowing down. The organizations that succeed won’t be the ones that moved fastest or blocked adoption entirely—they’ll be the ones that built the visibility, control, and response capabilities to adopt it safely. The path forward is clear: See every agent, understand what it can reach, enforce what it’s allowed to do, and maintain a complete record of its actions. This is the governance layer agentic AI demands.

The new release of Prompt for Agentic AI Security brings it all together as an enterprise control plane by combining real-time discovery, dynamic risk scoring, policy enforcement, and full auditability at machine speed. Security isn’t the reason your organization can’t adopt agents, it’s how you adopt them with confidence.

Learn more about Prompt for Agentic AI Security or contact us to see it in action.

Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

This publication includes forward-looking statements, including, but not limited to, statements concerning the expected timing of product and feature availability, the benefits and capabilities of our current and future products and services, competition and our competitive position, our strategic plans and objectives, and general market trends. Forward-looking statements are subject to risks and uncertainties, including factors beyond our control, that could cause actual performance or results to differ materially from those expressed in or suggested by the forward-looking statements. These and other risk factors are described in the “Risk Factors” section of our most recent Annual Report on Form 10-K, subsequently quarterly reports filed on Form 10-Q, and other filings made with the U.S. Securities and Exchange Commission (SEC), which are available free of charge on our website at http://investors.SentinelOne.com and on the SEC’s website at www.sec.gov.

You are cautioned not to place undue reliance on these forward-looking statements. Any future products, functionality and services may be abandoned or delayed, and as such, you should make decisions to purchase products and services based on features that are currently available.

Any forward-looking statements made in this publication are based on our beliefs and assumptions that we believe to be reasonable as of the date hereof. You should not rely upon forward-looking statements as predictions of future events. Except to the extent required by law, we undertake no obligation to update these forward-looking statements to reflect new information or future events.

In 2025, the enterprise risk landscape experienced a paradigm shift: the adoption of AI and LLMs officially becoming the primary driver of cloud risk. Today, almost 88% of organizations now leverage AI in at least one business function. With this level of integration, the risk of AI is now outpacing traditional security guardrails, culminating in a highly complex and interconnected attack surface.

SentinelOne’s® new AI and Cloud Verified Exploit Paths and Secrets Scanning Report examines this evolving threatscape and draws on telemetry from over 11,000 anonymized customer environments to offer deeper visibility into how threat actors are actively exploiting modern cloud and AI infrastructures.

An Explosion of AI-Specific Secrets and Shadow AI

A primary finding of the 2026 report is the rising proliferation of AI-specific credentials. The data indicates that AI-related secrets — such as OpenAI API Keys, Azure OpenAI API Keys, and others — increased by approximately 140% in a span of one year. This growth correlates directly with the rapid embedding of AI technologies into customer support systems, internal tooling, financial platforms, and product experiences.

Ubiquitous deployment has generated a widespread organizational pattern known as “shadow AI” – the unsanctioned use of AI tools in an environment without formal IT approval or security oversight. In practice, this occurs when developers or internal teams utilize unmanaged or personal LLM keys to process corporate data outside of sanctioned IT or security channels. Since these AI integrations span numerous internal applications, the same API keys are frequently duplicated and stored within code repositories, SaaS configurations, and development scripts. Compounding this, these credentials are often implemented without proper access controls or routine rotation schedules.

The sprawl of these credentials renders them difficult to track via standard secrets management protocols, establishing a requirement for more centralized governance over how AI keys are issued and utilized.

Distinct Risk Vectors of Unmanaged AI Credentials

Unlike traditional cloud credentials that primarily facilitate resource manipulation, the compromise of AI keys introduces unique risk vectors. AI services frequently operate at the intersection of various enterprise systems, including CRM platforms, ticketing systems, and analytics tools, which means a single compromised LLM API key can provide an attacker with broad visibility into diverse datasets. The risks associated are categorized with exposed AI keys into two primary areas:

• Data exposure and leakage: Unauthorized access via AI keys can expose sensitive or proprietary datasets processed by the models, embedded business logic, and internal user prompts and outputs. This enables attackers to harvest sensitive corporate conversations at scale.
• Prompt injection and data poisoning: Unmanaged AI keys allow threat actors to actively manipulate AI models. Through prompt injection, an attacker can influence model behavior to exfiltrate data or bypass established security controls. Additionally, attackers can execute data poisoning by injecting misleading or malicious data into contextual corpora or fine-tuning datasets, which degrades the model’s integrity and reliability over time.

The Broadening Scope of Traditional Cloud Secrets

While AI credentials represent a novel attack surface, the traditional cloud secrets landscape has concurrently grown more complex. In 2025, organizations exposed approximately twice as many types of critical secrets as they did in 2024. This diversification spans AI platforms, cloud providers, SaaS services, and payment processors, pointing to how a single compromise can result in a broader blast radius across revenue-generating systems and infrastructure.

High-privilege cloud provider keys associated with AWS, Azure, and GCP remain the primary anchor of critical risk. The exposure of these keys can facilitate complete account takeover, infrastructure manipulation, and large-scale data exfiltration. As well, the exposure of payment gateway keys, such as those for Stripe and Razorpay, expands the potential damage by putting Personally Identifiable Information (PII) and financial data at risk, enabling the direct abuse of payment workflows.

Repository and CI/CD tokens also introduce supply chain risks, where high-severity credentials like a GITHUB_TOKEN can grant attackers direct access to deployment pipelines and source code, allowing a localized leak to escalate into a systemic infrastructure incident. From a collective standpoint, secrets exposure is exponentially spanning payments, coding, and software development workflows, making risk an interconnected and complex challenge.

Verified Exploit Paths: The Persistence of Legacy Vulnerabilities

To evaluate how these exposed secrets translate into practical risks, the SentinelOne researchers leveraged the Offensive Security Engine (OSE) to generate Verified Exploit Paths. This technology analyzes misconfigurations, vulnerabilities, and exposed secrets in context to determine realistic exploitability.

The telemetry demonstrates that attackers generally do not rely on highly complex, theoretical attack chains. Instead, threat actors consistently exploit recurring entry points, specifically targeting misconfigured external services and widely abused Common Vulnerabilities and Exposures (CVEs). Notably, legacy vulnerabilities remain highly prevalent across customer environments and serve as reliable initial access points. The top verified exploit paths continue to involve older, critical CVEs, including:

• Shellshock (CVE-2014-6271)
• FortiGate SSL VPN credential disclosure (CVE-2018-13379)
• Pulse Secure VPN arbitrary file read (CVE-2019-11510)
• Webmin RCE (CVE-2019-15107)
• Barracuda ESG zero-day backdoor (CVE-2023-1698)

Since these vulnerabilities are public and well-documented, threat actors possess proven techniques and automated tooling to exploit them whenever they persist in production environments. Once initial access is achieved through these legacy vulnerabilities, attackers routinely follow reachable secrets to pivot into additional services, such as utilizing an exposed key found in a cloud bucket to access an AI assistant, and subsequently, the customer data it processes.

Strategic Recommendations for Security Leaders

Addressing the interconnected risks of AI integration and cloud secrets requires a structured, objective approach to security architecture. The report outlines several concrete capabilities and practices including:

• Continuous Surface Monitoring: Organizations must regularly inventory internet-facing assets, databases, and key cloud services, ensuring any configuration changes are immediately reflected in security posture assessments.
• DevSecOps Automation: Security controls must be embedded directly into CI/CD pipelines and developer workflows. Organizations should automate the scanning of exposed secrets and trigger safe remediation actions, such as access revocation or key rotation.
• Governance of AI Credentials: AI keys must be classified and treated as high-value credentials. Organizations should mandate the use of centrally managed AI keys rather than personal credentials, enforce least-privilege access, implement regular rotation schedules, and continuously monitor for shadow AI usage or abnormal access patterns.

Conclusion

As AI systems are increasingly built atop existing cloud, payment, and CI/CD platforms, weaknesses in traditional credentials inevitably become weaknesses in the AI infrastructures that rely upon them. The full report provides complete datasets and comprehensive exploit path models allowing today’s security teams to align their internal security policies with the realities of current threat actor behaviors. Learn more about the objective metrics behind the latest wave of credential exposure and vulnerability exploitation to establish more resilient and fully-controlled infrastructure architectures.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.