100+ AI SOC vendors: how to tell which will last. 5 hours ago More than 100 AI SOC vendors were described in Software Analyst Cyber Research founder Francis Odum's introduction to the firm's 2025 AI SOC market research. That estimate illustrates the breadth of the category. At PAGO Security Summit 2026, Stellar Cyber's keynote examined how buyers can evaluate the architecture behind AI SOC offerings, including the data available to an investigation and the work required to maintain it. For CISOs, vendor selection involves a longer term commitment. An AI SOC platform becomes part of how the team works every day, so if the vendor is acquired, changes direction or shuts down, moving to another service can create work for the security team. Buyers should therefore examine ongoing support, data export and continuity alongside the product's current capabilities. Why the demo won't tell you. An AI SOC demo may show an alert arriving, an AI investigation and a verdict appearing in under two minutes, with a summary and a chat window for follow up questions. It offers a starting point for evaluation. At the Summit, Stellar Cyber's Aimei Wei argued that fast triage, generated investigation reports and custom agents would become increasingly common across vendors. Her argument was that data architecture, including normalization, retention and context, deserves closer examination. Buyers can test that argument by checking whether verdicts are supported by evidence and whether the platform maintains that quality as data volumes grow. Four questions to ask any AI SOC vendor. 1. Can I trust what the AI says? Every verdict the AI produces should link back to the raw data behind it, so an analyst can check the reasoning instead of taking it on faith. Without that evidence, results can't be verified, and the team can't safely hand the AI more responsibility over time. Whether a platform can show its evidence depends on the underlying data layer as well as its AI model. Connecting an AI agent to a data source is relatively simple; the hard part is whether the data underneath can answer accurately and quickly. Retention decides what can be proved, because if logs are kept for only 30 days, an investigation into activity from two months ago may lack the records it needs unless archived evidence can be retrieved. Normalization decides what can be correlated, because when field names, timestamps and formats don't match across tools, the AI may link the wrong events and produces conclusions that sound confident but are wrong. Context matters just as much. A suspicious PowerShell command may look like a routine admin script on its own, yet the same command 40 minutes after a first-time login from a new location tells a very different story, and an AI that only sees the single alert will miss it. The SANS SOC Survey 2025 reports that 42% of SOCs send all incoming data into a SIEM, often without a retrieval or management plan. When evaluating vendors, ask how long data is retained, whether the AI can query months of history, how logs from different tools are normalized, and whether the evidence behind every verdict is visible. 2. Are the AI agents governed? AI agents need clear limits on what they can access and what they can change, and those limits work best when they are designed into the platform from the start rather than added later. In multi-tenant platforms, one customer's data must never mix with another's, and any content the AI processes, such as an email body or an uploaded file, carries a risk of prompt injection that has to be contained. When an agent changes a record or takes an action, approval requirements should follow its agreed authority and risk, and the action should be logged, because otherwise the team can no longer trust its own record of what happened. A good vendor should be able to explain exactly what its agents can access, which actions require human approval, and how every AI action is audited. OWASP recommends limiting agent functionality and permissions, enforcing authorization outside the model, requiring human approval for actions with substantial consequences, and logging activity. 3. Is the cost sustainable? Many model inference services charge according to token usage. Amazon Bedrock, for example, lists prices for input and output tokens, with costs also affected by caching and service tier. The cost of an AI SOC therefore deserves examination at the workflow level. Ask how much data is sent to a model, how often it is called and where filtering, normalization and correlation take place. Applying AI to a smaller set of correlated cases is one approach to evaluate for efficiency. Its suitability depends on the workload and the evidence preserved. Vendors should show where their AI runs and how the customer's total charges change as data and case volumes grow. 4. Is the ROI measured in production? Many vendors publish striking performance numbers, so it is worth asking whether they come from lab testing or from real customer environments. Lab results have value, but production data is messier, and the gap between the two can be large. A vendor that is confident in its product should be comfortable starting small, with one team, one tenant or one use case, so you can measure MTTD, MTTR and investigation coverage before and after and decide on evidence whether to expand. A checklist for your next AI SOC demo. * Every verdict links to the raw evidence behind it * The AI can query months of history, not just recent data * Data from different tools is normalized into one schema * Agent access is scoped, and every action is logged and auditable * Actions with substantial consequences follow agreed authority and approval requirements * The vendor can explain how cost scales with data volume * A limited pilot is possible before a full rollout * Performance metrics come from production customers * The platform covers both cloud and on-premises environments, if you run both A vendor's long term viability cannot be established by a demo. These questions help buyers assess the operational foundations of the service: evidence that can be checked, governed agents, sustainable costs and results measured in the customer's environment. They also provide a basis for reviewing support commitments and planning how data and operations could be transferred if the service changes. How this applies to PAGO's services. These evaluation questions also apply when choosing an operations partner. PAGO uses AI for repetitive analysis, evidence gathering and investigation drafts, while analysts assess business impact, set response priorities and retain responsibility for decisions. DeepACT Defense provides continuous detection, investigation and response. DeepACT Detection Engineering uses threat intelligence and lessons from incidents to build, test and refine detection rules. Integration and response depend on the supported technologies and the service scope agreed with the customer. Response authority should be part of that discussion. PAGO acts within rules and authority agreed in advance, with business impact informing critical actions. Buyers can ask how those rules translate an investigation into containment, how exceptions are escalated and how outcomes feed into detection improvements. The PAGO Security Summit 2026 Insight Report explores the operational thinking behind this approach. Sources. * PAGO Security Summit 2026 Insight Report. * Christopher Crowley, SANS SOC Survey 2025, July 2025, p. 2. Source * OWASP LLM06 2025 Excessive Agency. Source * Gartner, Hype Cycle for Security Operations, 2026, Darren Livingstone, Jonathan Nunez, 5 June 2026, as summarized by Dropzone AI: https://www.dropzone.ai/blog/gartner-hype-cycle-security-operations-2026

Stellar Cyber 7.0 adds AI triage and SOC management APIs for MSSPs. Stellar Cyber 7.0 adds AI case triage, SOC management APIs, and multi-tenant automation designed to reduce repetitive work for MSSPs. Oct 7, 2026 Channel Insider content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More MSSPs looking to automate more of the SOC without handing every decision to AI have a new set of controls to consider. Stellar Cyber announced version 7.0 of its security operations platform on Oct. 5, adding AI-assisted case handling and multi-tenant automation for managed security service providers (MSSPs) running security operations centers (SOCs). For providers juggling many customer environments, the release reaches both analyst workload and the repetitive administration that grows with every tenant. Case queues become the control point for automated review. Administrators can enable Case Summary and Auto-Triage on selected case queues. Work routed into those queues can receive automated analysis before an analyst begins review. Once a case enters an enabled queue, Auto-Triage investigates its associated alerts and assigns each alert a verdict: true positive, benign true positive, false positive, or inconclusive. Analysts can review the supporting evidence, ask follow-up questions through AI Assistance, and override individual alert verdicts. The platform then reevaluates the case verdict. Case Summary serves a different role by organizing evidence already attached to the case without performing the additional investigation used for triage. Measurement follows the automated review. Case Metrics tracks intervals such as creation to acknowledgment or resolution, allowing MSSPs to compare handling times against internal targets or customer service commitments. Similar measurement can give providers evaluating AI-driven SOC tools something more reliable than vendor automation claims. Use at scale comes with limits. SaaS customers need an add-on license for Auto-Triage, and MSSPs should confirm their licensed capacity and usage limits before expanding it across customer environments. APIs extend automation across customer environments. Version 7.0 also moves some repetitive administration outside the product interface. New System Action Center APIs can programmatically create actions tied to cases, infrastructure health, reports, users, privileges, and licensing. These capabilities become useful as multi-tenant security management expands across larger customer bases. Additional changes include several jobs providers may otherwise repeat customer by customer. Sensor management. On SaaS deployments, a new API can generate installation tokens for a specified tenant and sensor profile. Another API can initiate remote uninstallation of connected Windows and Linux Server Sensors, helping providers automate onboarding and decommissioning. Parser administration. Parser Studio can reuse configurations across tenants and disable inactive parsers in bulk. MSSPs managing different telemetry sources across many customers can avoid rebuilding or cleaning up the same parser setup individually. Response actions. Integrations extend into products customers may already use, including Microsoft Defender for Endpoint and Fortinet FortiGate. Providers involved in Microsoft Defender XDR deployments can keep more investigation and response activity inside the same SOC process without replacing those controls. Across these changes, MSSPs gain more ways to standardize routine work across their tenant base. Providers should set boundaries before expanding SOC automation. MSSPs need to evaluate the rollout as a change to the service they deliver. Customer requirements and service economics can vary from tenant to tenant, leaving providers with several decisions to settle before expanding access. Evaluate four areas before expanding access: * Start with a defined workflow. Choose a well-understood customer case type and establish how automated decisions will be evaluated during the initial rollout. Comparing AI verdicts with analysts' final dispositions can expose inconsistent results before the same approach reaches additional customers. Similar testing will become useful as agentic security workflows enter more managed security environments. * Set rules for capacity and service tiers. Auto-Triage capacity is shared across an organization's tenants and cannot be reserved for individual customers. If one customer generates a disproportionate volume of eligible alerts, an MSSP needs a policy for allocating that capacity instead of letting case volume determine consumption. Providers can then decide whether access belongs across standard services or within selected tiers. * Check customer deployment restrictions. On-premises Auto-Triage remains in Early Access and needs outbound access to Stellar Cyber's cloud AI service. Providers packaging managed security services should review customer data-handling rules and contract terms before adding the capability to environments with stricter connectivity requirements. * Measure the delivery economics. Establish a baseline for engineering and support hours before rollout, then compare staffing effort after API automation is in use. Work that moves into maintenance or exception handling produces a different return from work removed from the delivery cycle. For MSSPs, the longer-term value will depend on whether these controls allow a provider to add customers without adding manual work at the same rate. More AI news: Cisco's Webex expansion brings AI agents, RoomOS 27, and new customer experience tools into one broader enterprise collaboration strategy.