AI is absorbing the volume work that makes up the fundamental architecture of the Security Operations Center (SOC) tier system. While the tiers and the work aren’t going away, a junior and senior analyst’s day-to-day is changing fast.

At some point in the last week, every analyst on your team made the same call. Close an alert uninvestigated, because the queue was too long and triage ate the time real investigation and deep analysis was needed. Most of those calls were right, but odds are that at least one critical threat will eventually be overlooked.

The root cause here is the mathematical disparity. Nearly half of SOC teams lack the capacity to investigate more than fifty percent of the alerts they generate daily. Analyst capacity grows linearly while data volume compounds exponentially.

According to findings from SentinelOne®’s Annual Threat Report, what’s worse is that the math leans heavily towards the adversaries. Automated exploits have been recorded escalating privileges within a target environment in approximately 30 milliseconds. Similarly, malicious attack chains can progress from initial network access to establishing persistent footholds in under 50 seconds. No manual workflow currently matches these kinds of machine speed tempos.

As a result, the traditional tier structure of the SOC is transforming in real time. AI is already absorbing the triage and correlation work that that structure was originally built to manage. The critical call-out here is understanding that these tiers are not dissolving; rather, they are evolving. Junior and senior analysts still exist and hold their titles, and continue to have a clear career path ahead of them. What’s changing is the nature of the tasks that fills their day.

Analyst Tiers, Redefined by Depth

Historically, the distinctions between Level 1, Level 2, and Level 3 analysts were established primarily to manage high-volume workloads. Those distinctions were built to manage volume: Alerts routed to the right skill level, junior analysts escalating what they couldn’t resolve, senior time reserved for what actually needed it. AI now handles the triage and correlation volume those tiers existed to manage. Volume stops being the variable that defines the role. As a result, analyst tiers are being redefined by depth of expertise rather than the ability to process large queues.

That evolution isn’t limited to junior and senior analysts:

• Threat intel analysts move from manual feed correlation to directing AI-correlated intelligence
• Security engineers move from manual rule-writing to guiding AI-generated detection logic
• SOC managers move from tactical management to strategic leadership and AI governance

Depth of expertise replaces volume as the key differentiator: cloud architecture, identity, adversarial tradecraft. The kind of judgment that only comes from watching an environment long enough to know what normal looks like. AI can’t replicate nuanced, environment-specific skills that the legacy, volume-driven tiered system was never able to encourage or reward.

A Day in the Life, Before and After

In the legacy model, an analyst’s day typically begins by facing a queue containing hundreds of unvetted overnight alerts. Three or four hours go to manual triage, pivoting between tools to reconstruct what happened. The vast majority of the queue closes as false positives. The real threat, if there is one, surfaces hours later, pieced together across five or more disconnected consoles.

Adding in the administrative paperwork widens the gap even further. The legacy model requires analysts to spend upwards of an hour writing an incident report that adds nothing to the actual technical investigation. The new model allows the analyst to review and approve an AI-generated summary, adds environment-specific context, and closes the case in minutes.

In a modern model, the day starts with a prioritized queue instead of a noise wall: evidence-backed verdicts already assembled, ready for review. Thirty minutes go towards confirming the highest-priority case. That confirmation triggers a pre-approved response workflow within defined policy. Critical hours that were parcelled off to triage are used for proactive threat hunting instead.

Teams operating this way report the difference in hard numbers, according to two IDC research studies commissioned by SentinelOne.

• Teams using AI-powered investigation report 63% faster threat identification and 41% more efficient investigation. (IDC Business Value of Purple AI®, July 2025)
• AI SIEM customers on the Singularity Platform report 55% more efficient security operations and 4x more threats handled, at 55% lower solution costs. (IDC Business Value of Singularity AI SIEM, May 2026)

That time moves to where the judgment actually matters.

Governance is the New Core Skill

Recovered time only pays off if real judgment fills it. The most important judgment now is knowing when to distrust the AI.

The analyst who knows exactly where their AI is unreliable is more operationally effective than the one who trusts it uniformly. That skepticism is a skill and it has to be built on purpose, case by case.

Four capabilities define the analyst role going forward:

• Validating AI output instead of accepting it by default
• Designing the automation workflows that execute at machine speed
• Forming hypotheses worth hunting instead of only answering tickets
• Translating what the AI found into what it means for the business

Escalation frameworks must be designed to reflect that same judgment. Teams building trust in a new workflow route more cases to a human by default. Mature teams narrow that escalation path as their confidence in specific alert types grows. Either way, the analyst decides where the line sits, not the AI.

On top of this, analysts must govern the response earlier, setting the policy before events are triggered instead of reacting to it. Every automated action is scoped to a policy an analyst defined in advance. This keeps all of the details of the logged and fully auditable after the fact. The quality of what fires automatically traces back to the quality of that workflow.

The Career Path Forward

The evolution we are seeing in SecOps is directly addressing systemic issues of burnout and attrition, both significant risks to retaining talent within the cybersecurity industry. Under an AI-augmented model, every rung on the SOC career ladder gets more strategic:

• Junior analysts move from manual triage to verdict review
• Senior analysts move from reactive response to strategic hunting
• Managers move from daily firefighting to designing the system everyone else works inside

None of this happens in one leap. Adoption works crawl-walk-run, workflow by workflow. ‘Crawl’ starts with AI-assisted triage, validated against your own judgment, alert by alert. ‘Walk’ enables automated responses for well-understood, lower-risk cases, with human approval required for anything novel. ‘Run’ hands full workflows to AI for established threat patterns, with analyst time going to verdict review and hunting. Different parts of a SOC can sit at different stages of that maturity at the same time.

Start with the First 90 Days in the AI SOC checklist, a concrete plan for the next ninety days. For the full argument behind it, check out the Analyst’s Guide to the Autonomous SOC and see how SentinelOne is building toward this model.

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.

Here’s What Actually Happens Review

There’s something to be said about the reality of how helpful AI can be within running a business, and as someone who has been on the hunt to discover this for themselves, I speak from experience when I say that the path to AI-run success is not exactly what the internet makes it out to be.

A few months ago, as a business owner myself, I became consumed with the idea of building something truly special with AI assistance a real, legitimate business with actual revenue generation but I couldn’t find any real information on what the actual process of doing this looked like

Most articles written on the subject were either promotional pieces for SaaS tools or sensationalist opinion pieces focused on how the technology could replace humans in the workplace; no one actually seemed to want to discuss the day-to-day reality of building an AI-driven company and what it actually meant to run such an entity. Thus, I set out to answer these questions for myself, and in this piece, I’ll do my best to relay what I learned without pushing any particular tool or method as being somehow superior to the rest.

What Does it Mean to Build a Company with AI?

When I set out on this journey, I didn’t have a business plan. I had an idea, a hope, really that perhaps a single individual with the right tools could be able to achieve the same results as a small, mid-level team.

I had seen too many companies waste money and resources on tasks that a competent individual could complete and struggled to find much in the way of viable options for streamlining my own processes at the time, and so that’s what drove me to seek out information on how to build a company with AI assistance in the first place.

The truth is, I didn’t have a particularly strong grasp on what exactly it meant to build a company in this way at first — a majority of people don’t. What I failed to realise at the time was that to build a truly digitalised, AI-driven company meant to adopt a fully digitalised approach to every aspect of my own operations as well.

In practice, this looked like research and validation became a continuous, daily process rather than an event that only happened occasionally — content writing became exponentially faster and far more experimental, as I could churn out ten different headlines for the same article in the same day rather than spending a week agonising over a single one, customer communications became far more immediate and efficient, and administrative tasks that previously bled into my entire day were consolidated into far more manageable chunks that took up, altogether, less than an hour.

It’s important to note, however, that none of this eliminated the need for judgement or critical thinking within my own operations — I simply replaced my own repetitive, time-wasting tasks with those that could be automated, which ultimately gets to the root of what I feel is the most important lesson within the entire experience in general.

The Lesson that Not Everyone Talks About

When it comes to actually learning how to build a company with AI assistance, I think the most important lesson to be learned is that AI doesn’t do the work for you it only removes the roadblocks that previously kept you from doing the work you needed to do at an acceptable pace.

My early experiments with AI were riddled with failure emails that I sent to prospective clients had been generated by AI and were immediately off-putting due to their robotic nature; market research conducted by my chatbots turned out to be wildly inaccurate when cross-referenced with actual data from other sources, etc. In the end, none of this was actually AI’s fault it simply reflected that people who are using these tools tend to make the same mistakes over and over again, and those mistakes are usually process-related. If you rush through the process of generating content, you’ll end up with content that sounds rushed. If you fail to fact-check your research, you’ll end up with research that’s full of easily avoidable errors.

So, Can You Actually Build a Company with AI Assistance?

Yes, but not in the way that most people seem to think

You can’t magically outsource your own judgement or decision-making to some magical algorithm, but what you can do is automate the drudgery of actually executing on an idea to let your brain focus on the more important tasks that require thought. The companies that have successfully utilised this method in practice have done so by building proper feedback loops into their processes and never putting out any work without first double-checking the AI’s work to ensure it meets their standards.

In essence, these companies know that the best way to use AI assistance is to treat any work that comes out of it as a first draft of something that will eventually need to be reviewed by a human being — this way, they’re able to maintain quality control throughout their operations while still enjoying the benefits of increased productivity and decreased overhead. It’s a delicate balance, but with the right approach, it’s entirely possible.

What Would You Say to Someone Considering This Approach?

If you’re reading this article, odds are you’re considering learning how to build a company with AI assistance one day, and so I urge you to think carefully about exactly what it is you hope to accomplish before investing too much time into learning the ins and outs of these tools.

Above all, I think it’s important that you realise that the end goal should always be a company that only requires your own brainpower to make decisions. Ideally, most of your daily tasks should be automated so that you only have to spend minimal amounts of your own time on them throughout the day.

Start small: take one repetitive task from your own operations and plug it into an AI-powered program before you try to scale up and automate your entire business at once and be prepared to spend some time troubleshooting before you begin seeing results. After all, the companies that will end up succeeding in this space aren’t the ones that claim to be “100% AI-run,” but rather the ones that use the technology as a tool to move faster than everyone else while keeping a close eye on what needs to be improved in their own operations.

This is the reality of learning how to build a company with AI assistance, and I hope that this piece serves not as some magical end-all-be-all guide, but rather an informative look at the actual process that people rarely ever seem to talk about, as well as an actionable starting point for anyone who wants to begin exploring the benefits for themselves.

I Tried Building a Company with Only AI was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Security Operations Centers (SOCs) are currently confronting scalability challenges on two fronts: structural and cognitive. The day-to-day reality of modern defensive operations is stark: an analyst frequently begins a shift facing a queue deeply saturated with unvetted alerts. To process a single event, the analyst must open the alert, pivot to a secondary console to complete an investigation, manually enrich an IP address, copy a file hash into a third interface, and cross-reference an asset inventory that may not have been updated in months. Following this, they must author and refine queries, waiting for overloaded databases to return historical context.

The actual work of assessing the investigation’s results and moving to decision-making and action has not even begun. This is the administrative burden of the modern SOC. The true threats are not just those that attempt to bypass defenses, but the critical operational hours lost before an active mitigation attempt is even initiated. While analysts are highly trained professionals, the relentless requirement to perform manual data aggregation inevitably leads to exhaustion.

Misdiagnosing the Bottleneck: The Upstream Data Problem

Threat actors operate at machine speed, utilizing automation to pivot laterally across networks in a matter of seconds, frequently disappearing before defensive teams can even log into their terminals. Expecting human defenders to counter automated threat vectors by manually aggregating bad data is an architectural failure.

Every SOC inherits a highly fragmented data ecosystem. Telemetry is continuously generated by diverse sources, including firewalls, cloud workloads, identity providers, endpoint sensors, and legacy systems. This telemetry arrives in disparate dialects, varying formats, and highly inconsistent levels of fidelity. Before AI tools can accurately reason about a potential threat, or an analyst can initiate a logical investigation and run a playbook response, this raw telemetry must be synthesized.

Historically, organizations analysts take on these complex synthesis processes, manually normalizing data points across different vendor schemas. This represents a key misallocation of human intelligence. The asymmetry in modern security operations is not merely a discrepancy in speed; it is an imbalance in how security teams are forced to allocate their finite time. When operators spend the majority of their shifts wrangling data instead of actively investigating threats, the foundation of the SOC itself is inadequate. To achieve defensive velocity, organizations must recognize that fixing the data foundation is the mandatory prerequisite for improving all downstream security functions.

Architecting the Data Foundation with Singularity AI Data Pipelines

Addressing the upstream data problem requires the implementation of advanced data pipelines capable of resolving enterprise data chaos before it impacts the detection engine. Frameworks such as SentinelOne’s® Singularity AI Data Pipelines serve as this foundational layer, engineered to ingest telemetry from every source and in every format without requiring months-long integration projects or heavy manual engineering.

Modern pipelines utilize AI to normalize raw telemetry into standardized formats, specifically aligning with the Open Cybersecurity Schema Framework (OCSF). This structural alignment transforms fragmented logs into structured data that is immediately actionable. It eliminates the need for analysts to construct complex regular expressions during critical incidents simply to reconcile how two different software vendors format data, such as usernames or a timestamp.

Efficient data ingestion also requires dynamic, in-flight optimization. Not all telemetry possesses the same analytical value, and storing all generated logs in highly indexed, expensive storage tiers is financially and operationally untenable. Data pipelines optimize data streams by filtering out extraneous noise, trimming excess volume, and routing specific logs based on dynamic criteria. High-value security events are routed and indexed for rapid search retrieval, while lower-priority compliance or operational logs are routed to more cost-effective tiered storage. The result is a substantial reduction in infrastructure costs, a higher signal-to-noise ratio, and a structured data foundation that is completely prepared the moment an investigation is required.

When underlying data pipelines automatically enrich that log with identity and asset information, revealing (for example) that a specific financial director’s laptop in a remote office is communicating with a known botnet, the output transitions from a raw data point into a definitive starting point. Crucially, this enrichment occurs systematically before the human operator ever interacts with the alert. Solving this data problem end-to-end is a primary reason SentinelOne was recognized in the IDC MarketScape for AI SIEM.

Accelerating Detection via Singularity AI SIEM

When a clean, structured data foundation is properly established, the performance of downstream security tools accelerates. Modern detection engines, such as the Singularity AI SIEM, leverage indexless architectures to manage enterprise-scale telemetry. Because the data is normalized and optimized prior to ingestion, these platforms can execute petabyte-scale queries with minimal latency, ensuring investigative results are delivered before the analyst’s attention wanes.

Within this architecture, detection logic is executed continuously against a stream of clean, correlated telemetry. This transforms an ocean of disparate event logs into readable, centralized dashboards that provide immediate situational awareness. The quantitative benefits of this approach are substantial. With AI SIEM, organizations are already executing their queries 70% faster. Adding AI Data Pipelines further augments this workstream, providing cleaner data for AI to run at optimal efficiency. These improvements represent the direct result of ensuring that the data arriving at the SIEM is inherently fit for purpose.

AI SIEM remains a single, comprehensive SKU with customers automatically receiving integrated pipeline functionality for everyday data optimization rather than treating it as a premium add-on. For every unit of paid Data Ingest capacity, customers can process twice that volume through Data Pipelines. A customer with 500 GB/day SIEM entitlement can push 1 TB/day through the pipeline at no additional cost.

Transitioning to Agentic Reasoning Layers with Purple AI

The establishment of a structured data pipeline unlocks the capability for true agentic reasoning within the SOC. Unlike traditional rule-based automation, which executes static responses to predefined triggers, technologies like SentinelOne’s Purple AI operate as a dynamic investigative layer.

When an initial alert is generated, an agentic reasoning system does not simply pause and wait for human triage. It autonomously launches an investigation, comprehensively maps the potential blast radius of the incident, and synthesizes a clear, logical recommendation for containment. Then, the analyst logs into the console and is presented with a fully formed situational briefing rather than a blank investigation screen.

More importantly, an agentic AI layer possesses the capacity to evaluate broader adversarial campaigns rather than isolated security events. In isolation, a minor registry key modification, a singular file write, or a brief outbound network connection may not meet the threshold for a critical alert. Legacy security tools often fail to connect these disparate, low-signal events. However, Purple AI can assemble these seemingly unrelated activities into a cohesive narrative, exposing the overarching strategy of the attacker before a major breach occurs.

This level of autonomous intelligence is strictly dependent on the underlying architecture. Advanced AI algorithms cannot derive accurate conclusions from unparsed, low-quality telemetry. The analytical integrity of the agentic layer is entirely contingent on the principle of data quality; systems like Purple AI require clean, structured data to function effectively, avoiding the fundamental issue of “garbage in, garbage out”.

Governed Hyperautomation and the Human-in-the-Loop

The final component of a modernized, agentic SOC is the deployment of Hyperautomation to execute defensive responses. To counter threats effectively, organizations must deploy automated workflows capable of executing decisions at machine speed. These no-code workflows can be configured to trigger autonomously based on AI triage verdicts, the disclosure of new high-severity vulnerabilities, or specific incoming alerts. By automating the mitigation phase, the SOC evolves from an environment strictly dedicated to passive observation into a dynamic system that actively neutralizes threats.

However, the implementation of automated response mechanisms must be rigorously governed. Executing changes to enterprise infrastructure carries inherent risk. To mitigate this, automated workflows must integrate critical approval steps, ensuring that highly consequential actions are paused until human authorization is provided. The analyst retains the ultimate authority, defining the precise parameters of what processes may run automatically and what workflows require manual judgment.

Redefining the Analyst Mandate via Autonomous Security Intelligence

The strategic objective of integrating data pipelines, agentic reasoning, and Hyperautomation is not the removal of the human operator. Instead, the overarching goal is the restoration of the analyst’s primary function: exercising expert judgment.

By offloading repetitive tasks to technological systems, organizations systematically remove operational friction. The data layer filters out irrelevant noise, allowing the analyst to clearly see the threat. The AI investigation layer removes the administrative grind of data collection, allowing the analyst to focus purely on analytical thinking. Finally, the automated response layer eliminates procedural delays, ensuring the analyst’s decisions are executed rapidly enough to matter. This creates an intelligence fabric, known as Autonomous Security Intelligence (ASI), where data, investigation, and response function concurrently as a single, unified system.

Under this model, the operational output of a single analyst is exponentially multiplied, allowing one unburdened professional to accomplish the work of ten while still owning every critical decision. While the alert queue will perpetually require attention, the fundamental nature of the work fundamentally changes. The timeline of a manual initial triage to active investigation compresses from a multi-hour ordeal into a matter of minutes. The data arrives clean, the investigation runs automatically, and the response mechanisms are prepared. The hours previously consumed by administrative waiting are directly reallocated to strategic decision-making.

Conclusion

When defensive systems are finally architected to operate at the speed of the modern threat landscape, the role of the human operator transforms. Analysts are no longer forced to act as passive passengers, grateful to be carried by fragmented tools. They are elevated to the role of pilots, operating with full situational awareness, retaining their judgment, and actively directing the defensive posture of the organization. This is the paradigm of the agentic SOC, and it is entirely predicated on the foundation of clean, structured data.

Contact us today to learn more about how SentinelOne is leading the way forward with Agentic SOC.

NASA breathed a deep sigh of relief six years ago when SpaceX launched two astronauts, Doug Hurley and Bob Behnken, on a successful mission to the International Space Station. With the safe landing of Crew Dragon, the US space agency broke a nearly decade-long gap in its ability to put humans into orbit.

Through its Commercial Crew program and multibillion-dollar contracts awarded in 2014, NASA had hoped to foster two providers of low-Earth orbit transportation, SpaceX and Boeing. However Boeing has yet to complete a successful crewed test flight—a perilous 2024 test flight by Boeing's Starliner was later declared a Type A mishap—and probably won't fly another crewed mission before 2028.

With the International Space Station slated for retirement in the early 2030s, NASA is partnering with several US companies to develop private space stations. As part of that effort, the private companies will have to work with NASA to determine how they will transport astronauts to and from their space stations, some of which could launch as soon as 2030.

Read full article

Comments

The US Federal Government is committing $600 million to build one of the world’s most advanced AI infrastructure systems. Executive Order 14363, the Genesis Mission, connects national laboratory supercomputers across nuclear simulation, biodefense, energy grid modeling, and every major scientific domain. Fifty-one organizations signed on, including NVIDIA, OpenAI, IBM, Microsoft, AWS, Google, and Oracle.

The security framework governing these workloads was not written for this scale of use.

NIST SP 800-234, the High-Performance Computing Security Overlay, is well-constructed, tailoring 60 controls across four security zones, building on the SP 800-53B moderate baseline. It was designed for deterministic HPC workloads such as climate simulations, finite element analysis, and computational fluid dynamics. These workloads share a common attribute: code that runs the same way, every time, and behaves predictably under well-understood inputs. The security controls governing those workloads assume you can scan at the perimeter, clear memory between jobs, and attest to integrity at load time.

AI workloads break every one of those assumptions.

SentinelOne has submitted a formal proposal to the NIST HPC Security Working Group regarding this gap, and NIST has acknowledged it. We have a post on LinkedIn to share our proposal, and welcome commentary from across the industry.

The supply chain problem just got a lot more dangerous

This spring, in just three weeks, three AI-driven supply chain attacks targeted widely deployed software: LiteLLM, the most-used AI infrastructure package in Python development environments, Axios, the most-downloaded HTTP client in the JavaScript ecosystem, and CPU-Z, a trusted system diagnostic tool with a legitimate signed binary from the official vendor domain.

SentinelOne stopped all three on the same day each attack launched, with no prior knowledge of any payload.

The most important aspect of this outcome is how these attacks were stopped, and why signature-based detection couldn’t work. Each attack arrived through a trusted delivery channel. LiteLLM was compromised after credentials were stolen via Trivy, a security scanner. The attacker published two malicious versions to the PyPI repository. In at least one confirmed case, an AI coding agent with unrestricted permissions auto-updated to the infected version, meaning there was no human review or approval step before the payload ran. The Axios attacker exploited a legacy access token that the project maintainers had forgotten to revoke, bypassing every npm security control. CPU-Z attackers targeted the vendor’s distribution infrastructure directly; anyone who downloaded from the official website received a properly signed binary containing a payload. In all three cases, while the authorization chain was legitimate, the intent was not.

This is the defining characteristic of modern supply chain attacks: the workflow is verified, but the intent has been subverted. Every perimeter control, signature library, and reputation lookup checks authorization and passes. These attacks were designed to exploit that gap, and they ran at machine speed through automated pipelines with no human checkpoint.

To put this into the context of HPC and AI workloads running at scale, a compromised Python package in a developer’s environment is a serious incident; a poisoned training pipeline on classified biodefense data on a national laboratory supercomputer is on a different order of magnitude. The model it produces may be correct 99.9 percent of the time and adversarially wrong under precisely targeted conditions. No perimeter scan, signature check, or load-time integrity verification will catch it after training completes.

Where the current framework falls short

Of the 60 controls SP 800-234 tailors, three bear directly on AI workload protection, and each carries a documented gap. In a fourth area, supply chain, the overlay does not tailor at all.

• SI-3 (Malware scanning): The control acknowledges that real-time scanning is most effective but explicitly permits tailoring for performance on HPC systems, deferring to perimeter scanning before data reaches the compute zone. For traditional HPC workloads, that tradeoff may be defensible, but for AI workloads, it leaves behavioral analysis of the execution process completely unaddressed. A poisoned training run that executes within the expected statistical range of a training job looks like legitimate compute to a perimeter scanner.
• SI-4 (System monitoring): The control notes that high-speed data flows in HPC environments can overwhelm standard monitoring tools, and lacks AI-specific monitoring requirements or telemetry collection requirements from execution pipelines. The practical interpretation of this is: monitor what you can, accept the gap for what you can’t. On infrastructure running AI at scale, that gap creates a primary attack surface.
• SC-4 (Information in shared resources): Requires GPU memory clearing between user reassignments. It addresses data residency at the transition but does not address runtime behavioral monitoring of workloads during execution, side-channel attack detection, or anomalous compute-pattern identification while training is active.
• SR family (Supply chain risk management): The overlay carries all 12 moderate-baseline SR controls forward from SP 800-53B, with no HPC or AI-specific guidance, and supply chain is not among the 14 categories it tailors to. The SR controls still address only the conventional software and hardware supply chain; they say nothing about training-data provenance, model-weight integrity, or pre-trained-model validation, and the framework defines no AI equivalent of a software bill of materials. LiteLLM, Axios, and CPU-Z all arrived through legitimate software supply chain channels. AI workloads carry that same exposure one layer deeper, in the data and model artifacts that software trains on, which is exactly where the overlay is silent

AI Runtime Threats

The attacks against AI workloads on HPC are not theoretical, and they are not detectable at the perimeter.

• Training data poisoning scales at rates most security teams are not equipped to respond to. Research¹ across 41 studies documents attack success rates exceeding 60 percent from manipulation of 100 to 500 training samples, a fraction of a percent of a typical dataset. Poisoning as little as 3 percent² of training data achieved 41 percent attack success rates in code-generating models. OWASP’s LLM Top 10³ documents the consequence. Backdoors leave model behavior intact until a specific trigger activates adversarial outputs. The model ships, it gets deployed, and operates correctly, until it doesn’t. No post-training audit reliably catches a well-designed poisoning attack.
• GPU side-channel attacks are executed remotely by a co-tenant workload on shared GPU infrastructure; no physical access is required. The NVBleed research demonstrated covert channel attacks on NVIDIA NVLink, achieving over 91 percent accuracy in recovering data-dependent information from co-tenant GPU workloads on a shared fabric. The BarraCUDA research demonstrated the extraction of neural network weights via electromagnetic side channels from NVIDIA hardware. Both attack classes execute during active training, not at job transition. If your HPC environment runs multiple projects or security classifications on shared accelerators, the co-tenancy model is an active attack surface today.
• Inference pipeline compromise survives load-time integrity checks. A model with clean weights at deployment faces attacks through three vectors: hot-swap modification of serving configurations while inference runs; preprocessing and postprocessing layer injection that alters inputs before they reach the model or modifies outputs before delivery; and adversarial input manipulation that triggers targeted misbehavior in a model that appears fully operational. For AI serving safety-critical inference, each is a security risk, not just a research concern.

The characteristic that makes AI workloads uniquely difficult is persistence. A compromised simulation may produce visibly wrong results, but a compromised model can produce correct results the overwhelming majority of the time and adversarially wrong results under precisely targeted conditions. By the time anyone has reason to investigate, the window for recovery has often closed.

Securing HPC AI Workloads

We know the technology required to address these gaps exists and has been proven at scale in environments with performance constraints far tighter than those in HPC. What is needed is a well-defined architecture that enables the secure execution of large-scale AI workloads.

Dedicated security compute. Runtime security that shares CPU resources with the workload it monitors can be starved of CPU time under heavy load and interfered with by a workload that achieves kernel-level access. The SPiCa research demonstrated that eBPF monitoring pipelines can be manipulated from within the kernel by rootkits filtering events before they reach the analysis engine, meaning that a co-scheduled monitor is not a reliable monitor.

Every other infrastructure function on an HPC node has dedicated resources. The job scheduler, the filesystem client, and the out-of-band management plane. Security monitoring is infrastructure and should be afforded the same dedicated resources.

Modern HPC nodes have 128 to 256 CPU cores. One reserved for security monitoring is less than one percent of the available compute. Linux kernel CPU isolation via isolcpus, nohz_full, and rcu_nocbs is production-proven in high-frequency trading and real-time systems, with bounded, predictable overhead.

eBPF-based behavioral telemetry at the training layer. Effective monitoring of an AI training pipeline means continuous observation of compute behavior profiles, memory access patterns, GPU utilization, and inter-node communication, with behavioral baselines established for approved training configurations. A poisoning attack that executes within expected statistical ranges is not visible to a perimeter scanner, but it is visible to a behavioral baseline that knows what the training job should look like.

This is the same principle that SentinelOne’s on-device Behavioral AI detected for LiteLLM, Axios, and CPU-Z. The LiteLLM detection flagged a Python interpreter executing Base64-decoded code in a spawned subprocess. The CPU-Z detection flagged an anomalous process chain: cpuz_x64.exe spawning PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z doesn’t do that. The behavioral baseline knew what legitimate execution looked like, and in these cases, that behavior was the decisive signal.

Cloudflare uses an eBPF-based architecture to mitigate DDoS attacks exceeding 7 Tbps. SentinelOne uses it to detect and stop threats in under one second across enterprise fleets. A training job that begins writing to unexpected locations, establishing anomalous inter-node communication, or deviating from its expected compute profile is detectable at runtime, before the model completes training. The performance argument against runtime monitoring on HPC was never about the technology; it requires a shift in architecture.

Inference-time output monitoring. Deployed models require continuous observation of output distributions, latency patterns, confidence score distributions, and input-output statistical properties. A model under adversarial input attack, or serving modified weights, exhibits detectable output patterns before any human analyst notices the outputs are wrong. Circuit-breaker logic needs to be designed into the serving architecture, not added after the first incident.

Model integrity verification that runs during inference. Load-time attestation is a necessary and important requirement; it is not sufficient. Long-running inference deployments are vulnerable to hot-swap attacks that replace weights after the initial integrity check passes. Continuous cryptographic hash verification of loaded model weights, running on the dedicated security core with automated circuit-breaker logic on failure, closes that vector. For a model serving safety-critical calculations, the re-verification frequency should match the workload’s risk profile with predictable overhead.

An SR-family extension for the AI supply chain. The existing SR controls address software supply chain risk. They do not address training data provenance, model weight integrity at ingestion, or pre-trained model validation. An AI bill of materials, including cryptographic documentation from the training data source through intermediate checkpoints to the deployed model, is the model-layer equivalent of software supply chain controls. Without it, every pre-trained model loaded into an HPC environment is an unverified artifact from an unverified chain.

Defending AI at Every Layer

The supply chain attacks this spring demonstrated what happens when defense architecture falls behind the delivery mechanisms attackers use. LiteLLM, Axios, and CPU-Z all arrived through trusted channels, carrying payloads no signature database contained. They were stopped because behavioral detection does not require prior knowledge of the payload. It requires knowing what legitimate execution looks like and acting when execution deviates.

Defenders protecting AI workloads face that same problem across every layer they own. HPC is the hardest version of it. But identities, endpoints, applications, and infrastructure all carry the same exposure at different scales. SentinelOne gives defenders coverage across all four, with behavioral AI running at each layer to catch what signatures miss. The specifics of how that works across your AI environment are in our AI security overview.

Citations

¹ “Data Poisoning 2018–2025: A Systematic Review. IACIS (2025)”, and “Data Poisoning Vulnerabilities Across Health Care AI Architectures. JMIR (2026)

² “Poisoning Attacks on LLMs Require a Near-Constant Number of Poison Samples” (2025). arXiv:2510.07192 and Huang et al., 2020.

³ OWASP (2025) LLM04:2025 Data and Model Poisoning. OWASP Gen AI Security Project.

Microsoft is cutting 4,800 jobs, just over 2% of its global workforce, citing a need to revamp its sales and consulting division to keep pace with a rapidly changing tech industry, while overhauling its Xbox business in a push for long-term growth and profitability from gaming. 

The cuts include about 600 jobs in Washington state, home to Microsoft’s Redmond headquarters. That’s down from 3,200 job reductions locally a year ago. Combined with ongoing hiring, Microsoft’s workforce in the state is expected to remain stable at around 52,000 people.

About 1,600 of the 4,800 job cuts being announced Monday are in the Xbox division. Additional Xbox layoffs in the months ahead are expected to bring total job reductions in the gaming division to roughly 3,200, or about 20% of the global Xbox workforce, this fiscal year. 

Microsoft is also spinning off four Xbox game studios to operate independently. 

In an internal memo, Xbox CEO Asha Sharma called it the biggest restructuring in Xbox history, saying the division has been “operating at margins that are 3-10x lower than comparable platform and publishing businesses” and that studios have been losing 64 cents for every dollar invested.

Overall, top executives sought to distinguish Microsoft from other tech giants, saying the cuts were minimized by the redeployment of more than 4,000 employees into new roles over the past year and a voluntary retirement program that let thousands more exit by their own choice.

By comparison, the company last year cut more than 15,000 jobs globally in two rounds of layoffs in spring and summer 2025 — the largest reductions in more than a decade.

The latest cuts come amid record capital spending on the company’s AI infrastructure, pressure from Wall Street to keep operating expenses in check, and a 30% stock slide that has wiped out roughly $1.2 trillion in Microsoft’s market value over the past nine months.

“Microsoft can only be a strong employer if it has a successful business,” said Brad Smith, its president and vice chair, in an interview with GeekWire. “We have to adapt to change.”

Before the latest cuts, the company’s total workforce was about 220,000 people. Across the company, Microsoft expects worldwide headcount to decline year-over-year, CFO Amy Hood said on an April earnings call. 

Amy Coleman, Microsoft’s chief people officer, said in a memo to employees Monday morning that the roles the company is eliminating today are not being directly replaced by AI.

At the same time, she acknowledged, “AI is changing how work gets done.” She added, “Some of the tasks we do every day can now be automated, and that means we all need to keep learning, keep building new skills, and keep adapting as the work evolves.”

However, the line from Coleman’s memo that may get the most attention internally is this: “We are still early on this journey, and there will be more changes ahead; other parts of our business will need to make similar changes.”

In an interview, Coleman stopped short of signaling further layoffs across the company. Instead, she described a larger shift in how Microsoft manages its workforce. That includes reskilling engineers for customer-facing and AI-focused positions, and exploring how to make voluntary exit programs a regular part of the company’s operations — not just a one-time offer, but potentially something employees could opt into annually or on an ongoing basis.

Coleman confirmed that about 30% of roughly 8,750 eligible U.S. employees accepted Microsoft’s first-ever voluntary retirement program in recent weeks, in line with the company’s expectations, which reduced the size of the reduction in force announced Monday. 

The cutbacks and changes in the company’s sales and consulting teams build on last week’s launch of the Microsoft Frontier Company, a $2.5 billion initiative to embed 6,000 engineers inside customers to deploy AI. The shift is reducing some traditional sales and consulting roles and resulting in more technical positions working directly with customers. 

“We’re seeing that we need more engineering excellence in the customer space,” she said. 

Smith said software development is undergoing its biggest shift in the more than 50 years since Microsoft’s founding. The widespread use of AI is making code cheaper and faster to produce, but he said that’s also creating demand for new kinds of roles and work.

“Some things like coding require less time of software developers,” he said. “At the same time, there’s new parts that are growing, whether it’s the product management or software design, or perhaps most importantly, working directly with customers.”

Update: A filing by Microsoft on Monday under the Washington state Worker Adjustment and Retraining Notification Act listed 605 positions being eliminated in Washington state.

The roles span software engineering, product management, sales strategy, data science, business program management, marketing, and game design, among others — ranging from mid-level individual contributors to senior managers, consistent with cuts that reach across both the company’s technical ranks and its sales and consulting operations.

Nick Parker, a 26-year Microsoft veteran who led the company’s worldwide commercial sales business, is leaving to become Nvidia’s new sales chief — a high-profile talent shift between two of the biggest players in the AI boom. 

Parker will join Nvidia as executive vice president of worldwide field operations, effective Aug. 24, according to a regulatory filing. He succeeds Jay Puri, who is retiring after 21 years running Nvidia’s global sales operation and will stay on as a senior adviser. 

“Microsoft and NVIDIA are great partners and I look forward to continuing to nurture that fantastic relationship,” Parker wrote in a LinkedIn post announcing the move.

The regulatory filing by Nvidia sets Parker’s base salary in the new role at $1 million, with a $5 million signing bonus and equity grants targeted at $40 million. The bulk of that, $35 million in restricted stock units, vests over roughly four years, while the additional $5 million in shares is tied to Nvidia outperforming the S&P 500 over three years.

The new role puts him in charge of global sales and customer relationships at the center of the AI boom, reporting directly to Nvidia CEO Jensen Huang — one of the most consequential commercial roles in the industry, overseeing the operation that sells Nvidia’s chips to the world’s largest companies.

Parker, 55, rose through OEM, device and partner sales roles at Microsoft before being named president of industry and partner sales in 2022. After a promotion this year, he served most recently as executive vice president and chief business officer of Microsoft Worldwide Sales & Solutions, reporting to Judson Althoff, CEO of Microsoft’s commercial business.

Puri, 71, is credited with helping transform Nvidia from a consumer gaming brand into an AI infrastructure giant, building the enterprise sales operation Parker will now inherit.

On Thursday, Microsoft unveiled a $2.5 billion initiative called the Microsoft Frontier Company, which will embed AI engineers inside customers. It will be led by Rodrigo Kede Lima, a longtime Microsoft sales and enterprise leader, most recently president of Microsoft Asia. 

Microsoft is launching a new AI “company.” It won’t be a separate legal entity, and most of its 6,000 people already work at Microsoft. But the $2.5 billion behind it is real, and the stakes are big, given how many of its AI partners and rivals are racing to do basically the same thing. 

The tech giant on Thursday announced “The Microsoft Frontier Company,” which will embed engineers inside customers to build and run AI systems. It will be led by Rodrigo Kede Lima, a longtime Microsoft sales and enterprise leader, most recently president of Microsoft Asia.

This practice is known in the industry as forward-deployed engineering, in which a company sends its own technical employees to work inside a customer’s operations to design, build, deploy and operate AI systems on-site rather than selling a tool and walking away. 

The model was pioneered two decades ago by Palantir, but in recent months the approach has become the hot new thing in enterprise AI. Amazon committed $1 billion to its own forward-deployed engineering initiative just two days ago. (Some inside Microsoft suspect that its rival may have caught wind of what it was planning and moved to announce first.) 

Anthropic and OpenAI launched rival ventures in May to put engineers inside enterprise customers. Unlike Microsoft’s initiative, the OpenAI Deployment Company, as the ChatGPT maker’s venture is known, is an actual standalone entity — majority-owned by OpenAI but backed by more than $4 billion from a partnership led by the private-equity firm TPG. 

Similarly, Anthropic teamed with Goldman Sachs, Blackstone and Hellman & Friedman on a $1.5 billion venture — not yet named — to embed engineers inside mid-sized companies, starting with the investment firms’ own portfolio businesses.

Microsoft is attempting to one-up them all. 

“This goes beyond what has been labeled as Forward Deployed Engineering (FDE) and will be the largest, most capable, outcome-driven engineering organization in the industry,” wrote Judson Althoff, CEO of Microsoft’s commercial business, in a post announcing the new initiative Thursday morning.

Responding to questions from GeekWire, a Microsoft spokesperson called the new initiative “a purpose-built company with its own leadership and financial accountability” but stopped short of calling it a separate legal entity or standalone company.

The spokesperson said the organization “brings together more than 6,000 industry, engineering and AI professionals, drawn primarily from Microsoft’s existing engineering and forward-deployed teams,” noting that it will “grow through a combination of internal talent and external hiring across engineering, AI, and industry roles.”

Separately, some consulting roles are among those expected to be impacted by the round of layoffs anticipated next week.

Microsoft wouldn’t say whether the $2.5 billion is new spending or repurposed from existing budgets, or over what period it’s being spent. The company also hasn’t yet spelled out what the new organization means for the future of its existing consulting and services units.

Across the industry, this is happening now because the payoff from AI has proven harder to capture than many companies expected. Businesses across the economy have adopted tools like ChatGPT, Claude, Gemini and Copilot, only to find that impressive demos don’t automatically translate into results. The technology is powerful, but deploying it can be difficult inside a real company, with its own data, rules and entrenched ways of working.

So the AI providers have started sending their own engineers to work inside those companies, figuring out where the AI can actually help, then building it into their operations.

“Having the model alone doesn’t change your workflows or how you operate,” said Marc Nachmann, Goldman Sachs’ global head of asset and wealth management, in an interview with CNBC about the Anthropic partnership. “You need people who can combine the technology with what’s actually happening in the business and implement those changes.” 

The big AI providers have multiple reasons to do this. Each of them wants to get more businesses using its AI platform at higher volumes. All of them are looking to drive long-term demand for the AI capacity they’re collectively spending hundreds of billions of dollars to build.

Another big reason: AI models are becoming commodities, getting cheaper and more similar by the month. The big money for the likes of Microsoft is in selling the services needed to make AI pay off inside a company, which is a far bigger market than just selling the models themselves.

Microsoft is pitching privacy and trust as a selling point. Its promise is that a customer’s data and hard-won knowledge stay the customer’s alone. Microsoft says it won’t feed them into training its AI models in ways that would hand the same advantages to the customer’s rivals. 

It’s also promising choice: customers can run whichever AI model fits the job, from OpenAI, Anthropic, Microsoft, or open-source providers, not locked into using one.

Microsoft CEO Satya Nadella has argued that a company should be able to exchange one AI model for another without losing all the institutional knowledge it has built up. 

That’s his test, as he put it, for whether a business still controls its own future.

“The last thing any of us want is a world where every company across every sector is ceding value to a few models that eat everything they see,” Nadella wrote in a June 14 essay. “If all the value is accrued by only a few models, the political economy will simply not tolerate it. There is no societal permission for an AI future that hollows out entire industries.”

Whether that vision of swappable AI models becomes a reality remains to be seen. There’s actually a risk for customers that the opposite will happen in the forward deployed engineering approach. Even if they can theoretically swap in a competitor’s AI model, working with Microsoft’s engineers means their systems naturally end up running on Microsoft’s cloud platform and related technologies, making it very difficult to jump ship.

It’s also not clear how new all of this really is for the company. Microsoft already runs a large in-house delivery arm — Industry Solutions Delivery, the group that absorbed what used to be called Microsoft Consulting Services — with thousands of consultants and engineers building and deploying technology inside customer organizations. 

Microsoft also has programs like FastTrack to help customers roll out its software, and over the past year it has been rolling out “forward-deployed engineering” teams with partners, including a dedicated practice with Accenture and a $1 billion, five-year alliance with EY.

So ultimately the Microsoft Frontier Company is less a new company than a new push behind work the actual company was already doing, albeit bigger and better-branded than before.

When SentinelOne® introduced the Autonomous SOC maturity model, we made a deliberate choice: describe a journey, not promise a destination.

The industry had no shortage of vendors declaring that AI would transform security operations. We thought the more useful contribution was a framework for understanding what that transformation looked like, at what pace it was realistic, and what conditions each stage of progress required.

Security teams found the model useful. Not as a marketing claim, but as a map. CISOs and SOC leaders started placing their organizations on it, asking what it would take to move forward.

What happened next was telling. By RSAC 2026, ‘autonomous SOC’ appeared in vendor keynotes and product launches from companies that hadn’t used the term twelve months earlier. Add in pseudonyms like Agentic SOC and AI SOC, and the list explodes. Fast adoption brings loose definitions. For us, it’s worth being precise about what the concept means and what it doesn’t.

Here is what SentinelOne has learned from 18 months of real-world Autonomous SOC deployments.

What Held Up

Today, the progression still maps accurately to where organizations are and what separates each stage from the next. That accuracy holds even for a framework built before most organizations had meaningful AI deployment experience. The inflection points reflect real operational transitions at each maturity step.

The “journey not destination” framing has proven more important than we anticipated when we wrote it. In early 2026, Gartner published guidance to help buyers evaluate AI SOC claims more critically, noting that vendor credibility in this space depends on honest representation of where the technology is:

A maturity model is structurally honest. It reflects where you are, not where a vendor wishes you were. Gartner’s research found that while 40% of organizations are actively evaluating AI SOC capabilities, only 18% have actually deployed₂. The gap between evaluating and deploying is rarely about technology. Most organizations cannot advance because they lack a clear view of where they stand or what the next stage requires.

When security leaders use the model as a reference point, the evaluation conversation changes. The question shifts from “does your product make my SOC autonomous?” to “what would it realistically take to advance, given where we are today?” A feature list cannot answer that question. An honest vendor can.

Watch our webinar on why most AI SOC deployments stall here.

What We Underestimated

The levels were always sound. What we underestimated was how much organizations needed to build before they could operationalize them. Customers understood where they wanted to go. But achieving Partial Autonomy (Level 3) requires a data foundation, a workflow architecture, and AI readiness that most teams were still building when we first published this model. That’s a fact about where most security organizations were in 2024.

The transition from AI-Assisted Operations (Level 2) to Partial Autonomy (Level 3) is primarily a governance problem, not a tooling one. The tools are capable. What most organizations are missing is an understanding of the foundation of data and trust that Partial Autonomy (Level 3) requires, including the role humans play in building it.

When analysts work with AI assistance, they leave traces. Which queries they accept. Which results they act on. Which steps they modify or override. Over time, the system learns which investigation patterns the team trusts, which AI recommendations get acted on, and where analyst expertise is required – the kind of institutional knowledge that only comes from doing the work. Partial Autonomy is built on that record, not installed on top of an existing stack.

The path from AI-Assisted Operations to Partial Autonomy starts earlier than most organizations realize. It begins before they’re thinking about autonomy at all. Every assisted workflow is building toward what comes next.

What Holds Organizations Back

The primary barrier between AI-Assisted Operations (Level 2) and Partial Autonomy (Level 3) is accountability.

Consider how the automotive industry defined its equivalent of Partial Autonomy – SAE Level 3.

The designation applies only within specific, defined operational conditions. Outside those conditions, the human must take control. What qualifies a system for L3 is defined before autonomous operation begins: explicit parameters, a defined scope, and clear conditions for human override. Governance precedes autonomy.

Consider Waymo. It is the most capable autonomous system deployed at scale today — L3+ — operating without a safety driver under defined conditions. The vehicle is remarkable. But Waymo’s primary innovation is the organization built around it: the cloud infrastructure that keeps cars in autonomous condition, the human operations that handle exceptions the system cannot cover. The more autonomous the system, the more organizational maturity it required to build. High autonomy is an organizational capability.

The same logic applies in security operations. Accurate AI is the foundation. What makes Partial Autonomy legitimate is what gets built on top of it: defined rules of engagement, pre-approved policies, audit trails, and a clear organizational answer to who is responsible when an AI verdict is acted on. That accountability sits with the security team. When automation fires, it fires because someone made a deliberate governance decision to allow it. That is what makes it auditable, defensible, and durable.

Gartner’s readiness criteria for AI SOC deployments require that operational workflows be established in playbooks before AI is introduced₄. In practice, the organizations that advanced most consistently treated that requirement as a sequencing discipline, not a box to check. They defined their rules of engagement before turning on automated response.

The second learning was the attacker asymmetry. Defenders who stall between AI-Assisted Operations and Partial Autonomy have often done the validation work. The AI logic checks out. What remains is the decision to extend that trust to autonomous action — and that decision takes time. Attackers move differently. They deploy, observe what works, and iterate. Governance is an externality. Trial and error with no consequences for failure is a significant operational advantage. The gap between a defender’s trust-building timeline and an attacker’s operational tempo is structural. It compounds.

Why High Autonomy Stays on The Horizon. And Why That Matters Less Than We Thought

Eighteen months of deployment have also changed how we think about the upper end of the model.

When the original post was written, High Autonomy (Level 4) was described as dependent on a level of AI reasoning we hadn’t yet seen in production security environments. That remains the right framing. What’s changed is how close that horizon has become. Two years ago, asking a model to reason through a multi-stage attack, correlate signals across data sources, and produce an auditable verdict required significant scaffolding and produced inconsistent results. That’s no longer true. The gap between where AI was and where High Autonomy requires it to be has narrowed substantially.

High Autonomy still requires more than capable models. Institutional trust takes time to build. Accountability structures have to go beyond controlled tests to survive real incidents. Human oversight has to be redefined from reviewing individual actions to governing a system’s behavior within a defined scope. Those are organizational problems, technology doesn’t solve them. That work is already underway at Partial Autonomy (Level 3). What the road to High Autonomy requires is only visible from Partial Autonomy. Organizations that haven’t operated there yet are planning for a destination they haven’t seen. The knowledge of what it takes is path-dependent, and it emerges from operation, not from design.

As organizations move deeper into Partial Autonomy, the distinction between levels matters less in practice. What security leaders actually want is relevant control: governance over the decisions that matter, without being burdened by the ones that don’t. You cannot be responsible or accountable for a system that asks you to review everything.

Control over the right decisions is what matters. An analyst reviewing every alert has maximum control and minimum leverage. A system that acts autonomously on well-understood threat patterns, surfaces only the ambiguous and novel cases for human judgment, and maintains a complete audit trail, gives the analyst control over exactly what deserves their attention. That is a better and more focused version of human oversight.

High Autonomy, seen through this lens, is AI that has earned sufficient trust within a defined scope. The remaining human decisions are the ones that require human judgment, because the governance architecture evolved to allocate human attention correctly.

In the same way, a pilot does not manually adjust every control surface for the duration of a flight. They set the destination, define the parameters, and monitor the instruments. The system handles thousands of micro-corrections that would be impossible to manage directly. The pilot’s job is to govern the conditions under which the aircraft flies itself, not to manage every control input directly. Nobody describes this as a lack of pilot control. It is a better allocation of pilot judgment. And it works because of the environment surrounding the autopilot: pilot training standards, airline operational doctrine, air traffic control, and regulatory frameworks. The technology is one layer of a much larger system.

The governance work done at Partial Autonomy is the same work that produces High Autonomy. Organizations investing in it now are not waiting for a future capability release. They are building the foundation on which High Autonomy operates.

What This Means for the Road Ahead

The first step toward Partial Autonomy is a policy decision. Define the conditions under which your organization will allow a system to act: which response actions, against which threat types, within what scope, under whose authority. Write it down, however rough. That document is the actual starting point. Without it, the tooling is irrelevant.

The work at Partial Autonomy is real, meaningful, and available now. Security teams that define accountability structures before deploying autonomous systems, build a record of AI efficacy in their specific environment, and treat governance as a prerequisite rather than an afterthought, are the ones that reach and sustain Partial Autonomy. They are also the ones best positioned for what comes next. That work produces a more integrated SOC — data, AI, and response operating as a unified system.

High Autonomy remains the north star. This clearly articulated ideal state stops organizations from settling too early. It is the same function that “zero trust” serves as an architectural principle: no organization fully achieves it. Every organization is better for pursuing it.

The tools are capable. The frontier models have advanced significantly since our maturity model was first introduced. The capability gap that once made waiting feel reasonable has narrowed. What remains is the institutional work. That work is always harder than buying a product, which is why vendors who are honest about it are worth paying attention to.

SentinelOne customers operating the Autonomous SOC are seeing it in their numbers: 75% faster investigations, 4x more threats handled, 42% fewer false positives₅. Read the IDC Business Value Snapshot.

References

¹ Gartner, “AI SOC Agents: Harnessing Innovation, Managing Expectations,” Kevin Schmidt, Alex Tytarenko, Steve Santos, 25 February 2026. G00841784.

² Gartner, “AI SOC Agents: Harnessing Innovation, Managing Expectations,” Kevin Schmidt, Alex Tytarenko, Steve Santos, 25 February 2026. G00841784.

³ SAE International, “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,” SAE Standard J3016_202104, April 2021. https://www.sae.org/standards/content/j3016_202104/

⁴ Gartner, “AI SOC Agents: Harnessing Innovation, Managing Expectations,” Kevin Schmidt, Alex Tytarenko, Steve Santos, 25 February 2026. G00841784.

⁵ IDC Business Value Snapshot, “The Business Value of SentinelOne Singularity AI SIEM,” Michelle Abraham and Matthew Marden, May 2026, sponsored by SentinelOne. #US54435826-BVS.

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.