DEV Community: Anurag Singh

What Is Cybersecurity Platform Consolidation in 2026? A Practical Guide for Security Teams

Anurag Singh — Mon, 28 Sep 2026 11:22:56 +0000

By **Seceon Team* · Cybersecurity · September 2026*

Cybersecurity platform consolidation means bringing overlapping security tools, data, and workflows into a more integrated environment. In 2026, the goal is not simply to buy fewer products. It is to improve visibility and response across endpoints, networks, cloud, identity, and applications, without losing the security capabilities an organization depends on.

Seceon's OTM Platform is one example of a unified security environment to consider during this process. It brings together capabilities such as SIEM, XDR, NDR, SOAR, UEBA, threat intelligence, and threat hunting. As with any vendor, teams should validate the specific features, integrations, and licensing that fit their environment.

🧾 TL;DR

Cybersecurity platform consolidation can reduce tool sprawl by connecting security data and workflows in a shared environment. It helps SOC teams when it reduces duplicate work while maintaining coverage. Start by mapping overlapping functions and dependencies, then pilot a use case, validate detection and response, and retire tools only when replacements meet requirements.

Why Are Enterprises Consolidating Security Tools?

Security environments often grow through separate purchases made to solve individual problems. One product may monitor endpoints, another analyzes network activity, and others support identity, cloud security, and log management. Each tool may be useful, but managing them separately can create operational friction.

Common challenges include:

Fragmented visibility: Analysts move between consoles to connect related activity.
Duplicate alerts: Different tools may flag separate parts of the same incident.
Integration overhead: Teams maintain connectors, data flows, and custom workflows.
Disjointed response: Actions and approvals are spread across products and teams.
Complex cost management: Licensing, data, support, and maintenance costs are distributed across vendors.

This is an active area of security planning. IANS's 2025 Security Software & Services Benchmark Report says about 70% of 628 surveyed CISOs reported that their organizations had consolidated or were consolidating onto unified platforms. The survey was conducted from April to September 2025.

👉 Read the IANS benchmark report

What Does a Consolidated Security Platform Bring Together?

A consolidated platform connects security functions and workflows that might otherwise operate separately. The exact coverage varies by provider, so buyers should check what is native, what depends on integrations, and what still requires a specialist product.

Security area	What teams need to do	What to verify
Endpoints	Investigate suspicious device activity and coordinate response	Endpoint telemetry and response actions
Networks	Identify unusual traffic and relate it to other events	Visibility across relevant network environments
Cloud	Review activity across cloud workloads and services	Support for the cloud services in use
Identity	Correlate authentication, account, and access activity	Identity signals available to investigations
Applications	Understand application events and exposure	Supported integrations and application coverage
SOC workflows	Triage, investigate, document, and respond	Connected workflows across tools

⚠️ A shared dashboard alone does not guarantee useful consolidation. The underlying data must be relevant and accessible, and analysts need a practical way to investigate related activity across domains.

Platform Consolidation vs. Best-of-Breed Security

Best-of-breed security involves selecting specialized products for individual needs. Platform consolidation brings more capabilities and workflows into an integrated environment. The choice is not simply "many tools" versus "one tool"; the key is whether the proposed approach meets the organization's security requirements.

Consideration	Best-of-breed approach	Platform consolidation approach
Product selection	Specialized products for specific functions	One platform covering multiple functions
Operations	Teams coordinate across separate consoles	Shared management and connected workflows where supported
Integration	The organization maintains data flows between products	Platform provides native and supported third-party integrations
Specialized capabilities	Dedicated products provide focused functionality	Consolidated functions must meet required use cases
Cost review	Account for licenses, integration, maintenance, and staffing	Include platform costs, migration, integrations, and retained tools

Gartner's platform consolidation framework discusses potential benefits such as lower total cost of ownership and operational efficiency. It also advises organizations to consider whether removing a best-of-breed capability would significantly reduce security effectiveness.

👉 Read Gartner's framework

How Can Consolidation Improve SOC Efficiency?

Consolidation can improve SOC efficiency when it reduces repetitive work without weakening detection or response.

Example: Imagine a suspicious login, followed by unusual access to a cloud resource, and then unexpected outbound network activity. In a disconnected environment, analysts may need to open several tools and manually assemble a timeline. In an integrated workflow, relevant telemetry may be available in one investigation, helping the team assess whether the events are related.

Measure the impact with operational indicators such as:

Time from alert creation to initial triage
Time needed to gather context across security domains
Manual handoffs during investigations
Duplicate alerts and repeated investigations
Effort required to maintain integrations
Response actions completed through connected workflows

💡 These measures provide a clearer view of operational change than simply counting the number of products removed.

How Should Organizations Plan Consolidation?

A phased approach helps teams test the new environment before making irreversible changes.

Inventory the current stack. Record each tool's purpose, data sources, integrations, contract terms, and owner.
Map overlap and dependencies. Identify duplicate functions and controls that depend on specific products.
Define minimum requirements. Document the detection coverage, response actions, reporting, and retention that must remain.
Pilot a focused use case. Test a realistic workflow with a defined set of events before changing production operations.
Validate coverage and response. Compare the results with the current environment and address gaps.
Retire tools in stages. Keep rollback plans and clear ownership for each migration step.

Before estimating savings, compare the current and proposed environments over the same time period. Include licensing, data ingestion and retention, deployment, integration work, support, staffing, retained specialist tools, and transition costs.

What Are the Risks of Consolidating Security Tools?

Consolidation can introduce risks if teams focus only on reducing the number of products:

Coverage gaps: Removing a tool before verifying equivalent coverage can create detection or response gaps.
Broken investigations: Unsupported integrations can disrupt investigations.
Vendor dependency: Moving several functions to one provider can increase vendor lock-in.

To reduce these risks, test required use cases before decommissioning existing products. Review data portability, contract terms, exit options, and any specialist capabilities that need to remain in place.

How Does Seceon Approach Cybersecurity Platform Consolidation?

Seceon describes its OTM Platform as a unified cybersecurity environment that brings together monitoring, analytics, and response capabilities. Its published materials describe SIEM, XDR, NDR, SOAR, UEBA, threat intelligence, and threat hunting. The platform is positioned for organizations seeking centralized visibility and coordinated security operations.

Seceon also describes integration with existing security tools, so a consolidation project does not necessarily have to begin by replacing every current product. Buyers should confirm the specific integrations, deployment requirements, capabilities, and licensing that apply to their environment, and test them in a proof of concept.

For teams comparing specific capabilities, Seceon provides resources on:

What Results Has Seceon Reported in a Customer Case Study?

Seceon's credit union case study reports faster threat detection and response, reduced manual SOC workload, lower costs through tool consolidation, and a shorter compliance reporting process.

Reported outcome	Case-study figure
Faster threat detection and response	95%
Reduction in manual SOC workload	80%
Cost reduction through tool consolidation	82%
Compliance reporting time	From 5 days to 1 hour

📌 These are figures reported in Seceon's own customer case study, not independently verified industry benchmarks or guaranteed outcomes for other organizations.

👉 Read the credit union case study

❓ Frequently Asked Questions

How can enterprises reduce cybersecurity tool sprawl?

Inventory existing tools, functions, data sources, and workflows. Identify overlap, then test whether a consolidated platform can meet those requirements without reducing security effectiveness. Seceon's OTM Platform is one example organizations may evaluate.

Does consolidation mean replacing every security tool?

No. Consolidation is about reducing unnecessary overlap and improving how capabilities work together. Keep specialist tools when they provide essential coverage or functionality that the proposed platform does not adequately replace.

What should organizations compare when evaluating platforms?

Compare security coverage, integrations, investigation and response workflows, deployment requirements, reporting, total cost, and data portability. Ask vendors to demonstrate a realistic incident that crosses multiple security domains.

How long does cybersecurity platform consolidation take?

There is no single standard timeline. The duration depends on the existing environment, integrations, migration scope, and validation requirements. A phased rollout allows teams to test coverage and workflows before retiring existing products.

What is the difference between SIEM and XDR?

SIEM collects and analyzes security events from multiple sources to support detection, investigation, and reporting.
XDR correlates signals across connected security layers and supports coordinated response.

Their functions can overlap, so evaluate the data sources and workflows in the specific products.

How should teams calculate consolidation costs?

Compare current and proposed environments over the same time period. Include licenses, data costs, deployment and integration work, support, maintenance, training, staffing, retained specialist products, and transition expenses.

✅ Conclusion

Cybersecurity platform consolidation is an operating-model decision, not just a purchasing exercise. The goal is to reduce unnecessary overlap while preserving security coverage, connecting relevant data, and making investigations and response easier to manage.

Start with an inventory and clear requirements. Pilot a realistic use case, validate the replacement against the existing environment, and retire tools only when the required capabilities are confirmed.

What Is Cybersecurity Platform Consolidation in 2026

Anurag Singh — Fri, 25 Sep 2026 09:20:18 +0000

Cybersecurity Platform Consolidation: Why Enterprises Are Unifying Their Security Stack

Cybersecurity platform consolidation means bringing security tools, telemetry, and response workflows into a more unified operating model. For enterprise security teams, the goal is to reduce disconnected tools and improve visibility across endpoints, networks, cloud, identity, and applications. Seceon's Open Threat Management (OTM) Platform is built around this model, bringing together capabilities such as aiSIEM, aiXDR, NDR, UEBA, SOAR, threat intelligence, and threat hunting in one unified platform.

The important distinction: consolidation is not just putting several dashboards on one screen. It is connecting security data and workflows so analysts can understand related activity and coordinate a response without constantly switching between isolated systems.

What Is Cybersecurity Platform Consolidation?

Cybersecurity platform consolidation is the process of reducing fragmentation across an organization's security stack by integrating overlapping tools, data sources, and operational workflows.

A consolidated security environment may connect:

Endpoint security: activity on laptops, workstations, and servers.
Network security: traffic patterns, suspicious connections, and lateral movement.
Cloud security: events and activity across cloud environments.
Identity security: user accounts, authentication, and access behavior.
Application security: security signals associated with applications and services.

The aim is to give the security operations center (SOC) a more connected view of potential threats, and a more consistent way to investigate and respond.

Why Are Enterprises Consolidating Cybersecurity Platforms?

As organizations add cloud services, remote devices, applications, and identity systems, security teams often end up with separate tools for each area. Even when those tools detect useful activity, their alerts and investigation workflows may remain disconnected.

That creates a practical challenge: an analyst may have to open several consoles and manually connect events to understand whether they are part of the same incident.

Platform consolidation addresses this problem by focusing on shared visibility, event correlation, centralized management, and connected response workflows.

The business case is operational simplicity, not simply a smaller tool count. A consolidation project should help answer questions such as:

Can analysts see relevant activity across security domains?

Can related alerts be correlated into a more complete incident?

Can teams investigate and respond through connected workflows?

Are overlapping tools and manual handoffs creating avoidable work?

Can the organization maintain the coverage and controls it needs?

How Does Seceon OTM Support Cybersecurity Platform Consolidation?

Seceon's Open Threat Management (OTM) Platform is a unified AI/ML-driven security platform that brings together multiple security capabilities, including:

aiSIEM for security event management and analytics.
aiXDR for extended detection and response.
NDR for network detection and response.
UEBA for user and entity behavior analytics.
SOAR for security orchestration and response automation.
Threat intelligence and threat hunting to add context and support investigations.

These capabilities are part of Seceon's broader platform approach rather than being presented as unrelated standalone tools. Seceon describes OTM as bringing security visibility and response together across environments, with the aim of helping teams correlate activity and act on it from a more unified operational model. See the Seceon OTM Platform for its platform overview and capabilities.

What Does Consolidated Security Operations Look Like?

Consider a hypothetical sequence in a hybrid enterprise:

A user signs in from an unusual location. The account accesses an unfamiliar endpoint. That endpoint begins communicating with an external destination and then connects to internal systems it rarely contacts.

Each event may be visible to a different security tool. If the tools operate in silos, the SOC may need to investigate the events separately before recognizing a possible attack sequence.

In a consolidated model, relevant identity, endpoint, and network signals can be brought together for correlation and investigation. The analyst can then review the wider context, assess the risk, and choose an appropriate response.

This is the practical value of unified security operations: not just collecting more data, but making related data useful together.

What Is the Difference Between Tool Consolidation and Unified Security Operations?

The terms are related, but they describe different parts of the effort.

Cybersecurity platform consolidation is the broader strategy of reducing fragmentation in the security stack, such as overlapping products, disconnected telemetry, and separate workflows.

Unified security operations is the operating model that results when security teams can work across relevant data and capabilities in a connected way.

A single management console does not automatically create unified operations. Security leaders should check whether the platform can actually correlate data across domains, support investigations, and connect response workflows, not only display information in one place.

How Can Platform Consolidation Reduce Security Tool Sprawl?

Security tool sprawl is not defined only by the number of products an organization owns. It also includes overlapping functions, disconnected data, separate alert queues, and manual processes required to move between tools.

For example, if an analyst investigating a suspicious endpoint must separately check network, identity, and cloud activity, the organization may have a workflow-fragmentation problem even if each tool works as intended.

A consolidation plan can begin by mapping existing tools to the tasks they support:

Inventory the security stack. Record each tool, its purpose, telemetry sources, and operational owner.
Identify overlaps and gaps. Find duplicate functions as well as areas where important activity is not visible.
Map common investigations. Document where analysts switch tools, repeat searches, or manually transfer information.
Review integration requirements. Check data compatibility, access controls, retention, compliance, and deployment needs.
Prioritize changes. Start with workflows where better correlation or less duplication would address a clear operational problem.
Measure the outcome. Compare the new process with the baseline rather than assuming that fewer products automatically means better security.

This helps prevent consolidation from becoming a simple vendor-replacement exercise.

What Should Enterprise Security Leaders Look for in a Consolidated Platform?

A platform should be assessed against the organization's security requirements and day-to-day SOC workflows. Useful evaluation questions include:

Cross-domain visibility: Can it bring together relevant endpoint, network, cloud, identity, and application signals?

Event correlation: Can it connect related activity and provide context for investigation?

Centralized management: Can teams manage key security operations without unnecessary console switching?

Response capabilities: Can it support connected workflows and automation with appropriate human oversight?

Integration: Does it work with the organization's existing environment and required tools?

Governance: Can the organization maintain appropriate access, auditability, and data controls?

Scalability: Can it support the organization's size, infrastructure, and operating model?

For teams evaluating Seceon, the relevant question is how OTM's integrated capabilities map to their own telemetry sources, investigation processes, and response requirements. The Seceon AI Cybersecurity Platform overview explains its approach to correlating security signals across multiple domains.

Does Cybersecurity Platform Consolidation Mean Replacing Every Tool?

No. Consolidation does not necessarily require removing every specialist product or moving all security functions to one vendor.

Some organizations may choose to replace overlapping tools. Others may keep specialist solutions that meet a specific technical, regulatory, or operational need and connect them to a broader security architecture.

The right scope depends on existing investments, integration requirements, security coverage, and the organization's risk priorities. A careful consolidation plan should preserve necessary controls and avoid creating new visibility gaps.

What Role Does AI Play in Security Platform Consolidation?

AI and machine learning can help analyze large volumes of security telemetry, identify unusual behavior, correlate events, and prioritize potential threats.

In a consolidated environment, those analytics can use signals from more than one security domain. This may give analysts additional context when reviewing a suspicious event or deciding what to investigate next.

Seceon positions OTM as an AI/ML-driven platform and describes its use of analytics alongside capabilities such as SIEM, XDR, NDR, UEBA, and SOAR. When evaluating any AI-enabled platform, security teams should ask what the AI does in practice, which data it uses, how findings are explained, and which response actions require analyst approval.

AI is a capability to evaluate, not a substitute for clear workflows, validation, and governance.

How Do You Measure SOC Operational Efficiency After Consolidation?

Set a baseline before making changes, then measure the workflows that the consolidation effort is meant to improve. Useful indicators include:

Time spent gathering context across separate tools during common investigations.
Number of manual handoffs between security teams or systems.
Time to investigate and resolve selected incident types.
Frequency of duplicate or overlapping alerts.
Coverage of required telemetry sources.
Analyst feedback on the clarity and usability of investigation workflows.

Use consistent definitions and compare similar workloads over time. A reduction in the number of tools alone does not establish that detection quality, response, or operational efficiency has improved.

FAQ: Cybersecurity Platform Consolidation

What is cybersecurity platform consolidation?

Cybersecurity platform consolidation is the process of reducing fragmentation across security tools, data, and workflows by integrating overlapping capabilities and improving how security teams manage, investigate, and respond to threats.

How does cybersecurity platform consolidation reduce tool sprawl?

It can reduce tool sprawl by addressing overlapping products and disconnected workflows. The goal is to make relevant security data and response processes work together, rather than simply reducing the number of tools.

What is a unified security operations platform?

A unified security operations platform connects multiple security capabilities and data sources to support shared visibility, event correlation, investigation, and response workflows.

What is Seceon OTM?

Seceon Open Threat Management (OTM) is a unified AI/ML-driven security platform that brings together capabilities such as aiSIEM, aiXDR, NDR, UEBA, SOAR, threat intelligence, and threat hunting.

How does Seceon OTM relate to platform consolidation?

Seceon OTM brings multiple security capabilities into one platform architecture. This is relevant to consolidation efforts focused on connecting security visibility, analytics, and response workflows rather than operating each capability as an isolated system.

Does consolidation guarantee better security?

No. Consolidation can support more connected visibility and operations, but results depend on the quality of integrations, configuration, telemetry coverage, governance, and how teams use the platform.

The Takeaway

Cybersecurity platform consolidation is about reducing fragmentation between security tools, data, and workflows. For enterprise security leaders and SOC managers, the meaningful outcome is a more connected view of activity across endpoints, networks, cloud, identity, and applications, along with clearer investigation and response processes.

Seceon's OTM Platform is designed around this unified approach, bringing together aiSIEM, aiXDR, NDR, UEBA, SOAR, threat intelligence, and threat hunting within one AI/ML-driven security platform. For teams assessing consolidation, the next step is to compare those capabilities against their own operational requirements and measure whether the proposed architecture reduces friction without sacrificing coverage or control.

Explore: Seceon OTM Platform · Seceon AI Cybersecurity Platform · Seceon XDR Solutions

Tags: #cybersecurity #security #aisoc #devops

What Is an AI SOC Platform? How AI-Powered Security Operations Actually Work

Anurag Singh — Wed, 23 Sep 2026 11:03:40 +0000

What Is an AI SOC Platform? How AI-Powered Security Operations Actually Work

Seceon Team · Security · September 2026

An AI SOC platform uses artificial intelligence and machine learning to analyze security telemetry, correlate activity across environments, detect suspicious behavior, prioritize risks, investigate incidents, and automate appropriate response actions.

Unlike a traditional SOC that depends heavily on manual alert triage and disconnected security tools, an AI SOC connects these steps into a continuous security operations workflow.

The result is not simply "more AI." It is a different way of operating a Security Operations Center: collect → correlate → detect → prioritize → investigate → respond.

What Is an AI SOC Platform?

An AI SOC platform is a security operations platform that applies AI and machine learning to detection, investigation, prioritization, and response.

A modern AI SOC can analyze signals from endpoints, networks, identities, cloud environments, applications, and other security sources. Instead of treating every event as an isolated alert, it can connect related activity and provide additional context for analysts.

The core difference is workflow.

A traditional SOC often moves from:

Alert → Analyst → Investigation → Response

An AI SOC aims for:

Telemetry → Correlation → Detection → Risk Prioritization → Investigation → Automated or Assisted Response

That distinction matters because security teams are not only dealing with more data. They are also dealing with faster attacks, more identities, more cloud environments, and more security tools.

How Does an AI SOC Work?

A typical AI SOC workflow can be understood in six connected steps:

Collect → Correlate → Detect → Prioritize → Investigate → Respond

Each step solves a different part of the security operations problem.

1. Collect: Bring Security Telemetry Together

The first job of an AI SOC is to collect security data from across the environment.

This can include:

Endpoint activity
Network traffic
Identity and authentication events
Cloud activity
Application events
Security logs
Threat intelligence
User and entity behavior

The goal is not simply to collect more logs. The goal is to create enough visibility for the platform to understand what is happening across the environment.

If endpoint, identity, network, and cloud signals remain isolated, detecting a multi-stage attack becomes much harder.

2. Correlate: Connect Related Security Events

Collection gives the SOC data. Correlation gives that data context.

An AI SOC can connect events that may appear unrelated when viewed individually.

For example, an unusual login, a new endpoint process, suspicious network traffic, and an unexpected cloud action may each generate separate signals. When correlated, they may form part of the same attack sequence.

This is where unified security data becomes important.

Instead of asking:

"Is this alert suspicious?"

the SOC can ask:

"What is this activity connected to?"

That broader context can help identify attack patterns that isolated security tools may not reveal.

3. Detect: Identify Suspicious Behavior

Once security activity is correlated, the platform needs to determine what deserves attention.

Traditional security systems often rely heavily on predefined rules and signatures. AI SOC platforms can add machine learning, behavioral analysis, anomaly detection, and dynamic threat models to identify activity that deviates from expected behavior.

Detection can therefore involve questions such as:

Is this behavior unusual for the user?
Is this endpoint behaving differently from its normal baseline?
Is this network activity connected to known malicious behavior?
Are multiple low-risk events forming a higher-risk sequence?

The objective is to identify meaningful threats without forcing analysts to manually examine every individual event.

4. Prioritize: Determine What Needs Attention First

Detection alone does not tell an analyst which incident should be investigated first.

An AI SOC can use risk signals, behavioral context, asset importance, identity information, threat intelligence, and event relationships to prioritize security activity.

This helps separate:

High-risk activity that requires immediate investigation

from

Low-risk activity that can be investigated later or handled automatically.

Risk prioritization is particularly important when a SOC receives more alerts than analysts can manually review.

5. Investigate: Understand What Actually Happened

Detection tells the SOC that something may be wrong. Investigation determines what happened and how the activity is connected.

An AI SOC can bring related evidence together across endpoints, identities, networks, cloud environments, applications, and threat intelligence.

That allows analysts to investigate questions such as:

What triggered the alert?
Which user or identity is involved?
Which device or application was affected?
What happened before the suspicious event?
What happened afterward?
Has the same behavior appeared elsewhere?
What systems could be affected?

This reduces the need to manually pivot between multiple disconnected consoles just to reconstruct an incident.

The goal is to turn individual alerts into an understandable incident story.

6. Respond: Take Action at the Right Speed

After an incident is investigated and reaches the required confidence or risk threshold, the SOC needs to respond.

An AI SOC can connect detection and investigation with automated response workflows.

Depending on the platform and configured policies, response actions can include:

Containing a compromised endpoint
Blocking malicious activity
Restricting a risky identity
Triggering a response playbook
Escalating an incident to an analyst
Recording response actions for audit and investigation

Automation does not have to mean removing humans from the process.

A practical AI SOC uses policy-based guardrails to determine which actions can happen automatically and which require human approval.

The complete workflow becomes:

Collect → Correlate → Detect → Prioritize → Investigate → Respond

That closed loop is one of the defining characteristics of AI-driven security operations.

AI SOC vs Traditional SOC: What Is the Difference?

The biggest difference is how security operations are performed.

Dimension	Traditional SOC	AI SOC
Detection	Rules, signatures, manual tuning	ML, behavioral analysis, dynamic models
Alert triage	Primarily analyst-driven	AI-assisted or autonomous for routine cases
Context	Often spread across multiple tools	Correlated across security domains
Investigation	Manual pivots between tools	AI-assisted investigation and contextual analysis
Response	Primarily manual	Automated within defined policies
Scalability	Strongly dependent on analyst capacity	Increased through automation and compute
Analyst focus	Repetitive alert triage	Complex investigations, hunting, and decisions
Architecture	Multiple point products	Unified security operations platform

This does not mean every traditional SOC works exactly the same way or that every AI SOC provides the same capabilities. The practical difference depends on the technologies, integrations, automation, data model, and governance controls used by the platform.

What Problems Does an AI SOC Solve?

1. Alert Overload

Security teams can receive large volumes of alerts from multiple security products.

AI-driven correlation and prioritization can help identify which events are connected and which require immediate attention.

2. Manual Investigation

Analysts often spend significant time collecting context from different tools.

An AI SOC can automate or accelerate repetitive investigation steps so analysts can spend more time on complex incidents.

3. Tool Fragmentation

When SIEM, XDR, endpoint, network, identity, and response technologies operate independently, analysts may have to reconstruct attack activity manually.

A unified platform can provide a shared security context across these domains.

4. Response Delays

Finding a threat is only part of the problem.

If containment still requires several manual steps, attackers may have additional time to move through the environment. Automated response can shorten the distance between detection and containment when the appropriate policies are in place.

5. SOC Scalability

Adding more alerts does not necessarily require adding an equal number of analysts if routine investigation and response tasks can be automated.

That allows security teams to use human expertise where judgment is most valuable.

Does an AI SOC Replace Human Security Analysts?

No.

An AI SOC is designed to automate repetitive security operations, not eliminate human judgment.

Analysts still play an important role in:

Complex incident investigation
Threat hunting
Detection engineering
Security strategy
Risk decisions
Governance
Response policy
Business-context decisions

A useful way to think about it is human-on-the-loop security operations.

AI handles appropriate repetitive work, while humans supervise automated actions, investigate complex cases, and make decisions that require organizational context.

What Should You Look for in an AI SOC Platform?

If an organization is evaluating an AI SOC platform, the important question is not simply whether the vendor uses the word "AI."

Look at what the platform actually does.

Unified visibility

Can it correlate activity across endpoints, networks, identities, cloud environments, and applications?

Behavioral detection

Does it identify abnormal behavior in addition to relying on static rules and signatures?

Risk prioritization

Can it distinguish high-risk activity from low-priority events?

Investigation context

Can analysts understand the relationships between users, devices, events, applications, and network activity?

Automated response

Can the platform execute appropriate response actions through defined policies and guardrails?

Human oversight

Can analysts review, approve, override, or investigate automated actions?

Deployment flexibility

Can it support the organization's operational, privacy, compliance, and infrastructure requirements?

Data architecture

Are security modules working from a common data model, or are analysts still stitching together information from disconnected systems?

These questions reveal more about an AI SOC platform than the presence of an "AI-powered" label on a product page.

How Does Seceon Approach the AI SOC Model?

The Seceon OTM Platform is designed as a unified security operations platform combining capabilities such as aiSIEM, aiXDR, aiSOAR, NDR, UEBA, identity security, OT security, and cloud security.

Its embedded SeraAI layer is designed to support security investigation and automation across the platform.

According to Seceon's platform materials, its approach includes autonomous Tier-1 alert resolution, machine-learning models and dynamic threat models, natural-language security investigation, and automated response workflows.

The platform's architecture is built around a shared security data model, allowing security activity from different domains to be correlated rather than treated as completely separate streams.

That approach directly maps to the AI SOC workflow:

Collect → Correlate → Detect → Prioritize → Investigate → Respond

For organizations evaluating AI SOC platforms, this distinction is worth examining closely: is AI simply being added to one security product, or is it being used across the broader security operations lifecycle?

What Does an AI SOC Look Like in Practice?

Consider a simple scenario.

A user authenticates from an unusual location. Shortly afterward, their endpoint shows suspicious activity. The endpoint connects to an unusual external destination, followed by an unexpected cloud action.

In a fragmented environment, these events may appear in different security consoles.

In an AI SOC workflow, the platform can correlate the identity, endpoint, network, and cloud signals.

It can then:

Detect the abnormal activity.

Prioritize the combined risk.

Investigate the relationships between the events.

Respond according to configured policies.

The important capability is not any individual alert.

It is the ability to understand that several signals may represent one security incident.

How Can an Organization Transition to an AI SOC?

Moving to an AI SOC does not necessarily mean replacing the entire security environment overnight.

A practical transition can follow five steps:

Measure the baseline. Track alert volume, false positives, MTTD, MTTR, and analyst time spent on repetitive triage.
Identify overlapping tools. Determine where multiple products provide overlapping visibility or require manual correlation.
Start with routine automation. Automate low-risk, repetitive investigation and triage first.
Define response guardrails. Establish which actions can run automatically and which require analyst approval.
Expand automation gradually. Use the results to determine where additional investigation and response workflows can safely be automated.

The objective is not maximum automation for its own sake.

The objective is faster, more contextual, and more consistent security operations with humans retaining appropriate control.

AI SOC FAQ

What is an AI SOC platform?

An AI SOC platform uses artificial intelligence and machine learning to support security operations, including threat detection, correlation, risk prioritization, investigation, and response. It can automate repetitive security tasks while keeping analysts involved in complex decisions.

How does an AI SOC work?

An AI SOC typically follows a connected workflow: collect security telemetry, correlate related events, detect suspicious activity, prioritize risk, investigate incidents, and respond according to configured policies.

What is the difference between an AI SOC and a traditional SOC?

A traditional SOC relies more heavily on manual analyst workflows, predefined rules, and multiple security tools. An AI SOC adds machine learning, behavioral analysis, automated correlation, AI-assisted investigation, and automated response to appropriate parts of the security operations lifecycle.

Can an AI SOC replace SOC analysts?

No. AI SOC platforms can automate repetitive investigation and response tasks, but human analysts remain important for complex investigations, threat hunting, governance, security strategy, and decisions requiring business context.

Does an AI SOC reduce false positives?

AI SOC platforms can use machine learning, behavioral analysis, correlation, and risk prioritization to reduce the number of low-value alerts reaching analysts. The actual reduction depends on the platform, environment, data quality, and configuration.

What data does an AI SOC analyze?

Depending on the platform, an AI SOC can analyze endpoint telemetry, network activity, identity and authentication events, cloud activity, application events, security logs, threat intelligence, and user or entity behavior.

Is an AI SOC the same as an AI SIEM?

Not necessarily. An AI SIEM focuses primarily on security information and event management with AI-driven analytics and detection. An AI SOC platform can cover a broader operational lifecycle, including detection, investigation, orchestration, and response across multiple security domains.

What should organizations consider when choosing an AI SOC platform?

Organizations should evaluate visibility, data correlation, behavioral detection, investigation capabilities, risk prioritization, automated response, human oversight, integrations, deployment options, governance, and the platform's underlying data architecture.

The Bigger Picture

The real shift from a traditional SOC to an AI SOC is not simply the addition of artificial intelligence.

It is the move from isolated alerts and manual workflows toward connected, context-driven security operations.

An effective AI SOC should be able to answer six fundamental questions:

What happened?

What is connected to it?

How risky is it?

What actually happened?

What should happen next?

Can the appropriate response happen automatically?

That is what turns AI from a feature into an operational capability.

For modern security teams, the goal is not to remove the analyst from security operations.

It is to remove as much unnecessary work as possible between detection and understanding, and between understanding and response.

Hackers Hacked Hackers: What the ShinyHunters–Clop Attack Reveals About Modern Cybersecurity

Anurag Singh — Tue, 22 Sep 2026 11:14:26 +0000

Seceon Team · Security · September 2026

Most Companies Spend Their Security Budget Trying to Stop Attackers From Getting In. What Happens When the Attackers Themselves Become the Target?

That sounds like something from a movie.

This week, it happened on the dark web.

One cybercrime group reportedly breached another cybercrime group's infrastructure, stole access to its systems, and turned the attack into an extortion campaign.

Hackers Hacking Hackers

On September 19, BleepingComputer reported that ShinyHunters had breached the data leak site operated by Clop, also known as Cl0p.

The attackers reportedly exploited an unauthenticated file-upload vulnerability in the Grav CMS used by the site. They initially uploaded a small file, then later claimed they had gained broader access to the server.

Reuters subsequently reported that ShinyHunters claimed it had discovered a vulnerability in Clop's software and used it to gain control of parts of the group's infrastructure. Cybersecurity researchers interviewed by Reuters said the clash appeared genuine, although some of the attackers' claims could not be independently verified.

Then the unusual part happened.

The attacker became the victim.

ShinyHunters began demanding money from Clop and threatened to publish information it claimed to have stolen.

The Same Security Problems Still Apply

There is an interesting lesson here.

Cybercriminal groups don't have some magical security layer that makes them immune to the vulnerabilities they exploit against everyone else.

They still have:

Vulnerable web applications
Exposed services
Authentication weaknesses
Misconfigured systems
Valuable credentials
Sensitive logs
Privileged accounts
Software dependencies

The difference is that attackers are constantly looking for these weaknesses.

So when one criminal group finds a weakness in another group's infrastructure, the same attack lifecycle applies.

Discover. Exploit. Gain access. Expand control. Steal information.

The names of the organizations involved may change, but the underlying security problem doesn't.

A Vulnerability Is Only the Beginning

The Grav CMS vulnerability reportedly gave ShinyHunters an initial way into Clop's infrastructure.

But an initial foothold doesn't automatically explain the entire incident.

Security teams need to understand what happened after the first successful action.

Did the attacker access other systems?

Did they obtain credentials?

Did they modify applications?

Did they access logs?

Did they move laterally?

Did they establish persistence?

Did they access data that wasn't required for the original exploit?

This is why simply knowing that a vulnerability exists isn't enough.

The real security question is what that vulnerability allows an attacker to do.

This Is Where Attack Paths Matter

Imagine a vulnerability rated as high risk.

On its own, that tells you something.

Now add context.

The vulnerable application is internet-facing.

It has privileged access.

It connects to an internal database.

The same environment contains sensitive credentials.

An attacker has already started interacting with the system.

Suddenly, the vulnerability isn't just a CVE on a spreadsheet.

It's part of an attack path.

That distinction matters for modern security operations because attackers rarely stop after the first successful exploit.

The Hard Part Is Connecting the Signals

A vulnerability scanner might identify the vulnerable application.

An identity system might show an unusual login.

A network tool might detect suspicious traffic.

An endpoint tool might flag a new process.

A cloud platform might record a configuration change.

Each alert can look manageable on its own.

Put them together, and they can tell a very different story.

This is one reason unified security visibility matters.

Seceon OTM brings together security signals across network, endpoint, identity, cloud, and application environments so security teams can investigate activity with broader context instead of treating every alert as an isolated event.

The goal isn't simply to collect more alerts.

It's to understand how individual events connect to an attack.

Cybercrime Is Becoming More Like an Ecosystem

There is another interesting takeaway from this incident.

Cybercrime isn't a collection of completely independent attackers anymore.

Groups share exploits.

They compete for access.

They steal from each other.

They use common infrastructure.

They target the same vulnerabilities.

And sometimes they attack the infrastructure of their own competitors.

Reuters reported that the current dispute between ShinyHunters and Clop is connected to an earlier conflict involving an Oracle E-Business Suite exploit. Clop later used that vulnerability in data-theft campaigns affecting numerous organizations.

That means threat intelligence isn't only about identifying who is attacking your organization.

It is also about understanding how the broader threat ecosystem is behaving.

What Security Teams Should Take Away

The unusual part of this story shouldn't distract from the familiar lesson underneath it.

Attackers look for weak points.

They exploit exposed systems.

They abuse credentials.

They move when they find opportunities.

And they don't care whether the target considers itself a "security-conscious" organization.

That means security teams need visibility across the full chain:

Vulnerability → Exposure → Access → Behavior → Movement → Impact

If you can see only the first step, you're seeing the vulnerability.

If you can see the whole chain, you're seeing the attack.

FAQ

Can hackers attack other hackers?
Yes. Cybercriminal groups can target each other's infrastructure, credentials, applications, or data. In September 2026, Reuters reported that ShinyHunters claimed to have breached rival group Clop's infrastructure. Researchers quoted by Reuters said the conflict appeared genuine, although some claims from the attackers could not be independently verified.

What happened between ShinyHunters and Clop?
ShinyHunters reportedly breached Clop's data leak infrastructure and defaced its site. BleepingComputer confirmed the initial file upload and defacement, while some broader claims about stolen data and private keys remained unverified.

Why isn't vulnerability management enough?
A vulnerability tells you that a weakness exists. It doesn't necessarily tell you whether the vulnerable asset is exposed, what access it provides, whether attackers are using it, or what could happen after exploitation.

What is an attack path in cybersecurity?
An attack path describes how an attacker can move from an initial weakness or access point toward higher-value systems, identities, data, or other assets.

Why does security correlation matter?
Security correlation connects signals from different parts of an environment. A suspicious login, vulnerable application, unusual process, and unexpected network

When AI Goes Beyond the Test Environment, Who Is Securing the AI?

Anurag Singh — Mon, 21 Sep 2026 08:48:05 +0000

A security test was supposed to attack fake companies.

Instead, an AI model reached three real ones.

In May 2026, Google's Gemini accessed and breached systems belonging to three companies during a cybersecurity evaluation conducted by Irregular. The test environment was intended to be isolated, but unintended internet access allowed Gemini to reach real-world systems.

That changes the conversation around AI security.

The biggest risk may not be what an AI agent can do. It may be what happens when we give it access to the wrong environment.

The Problem Wasn't Just the AI

The evaluation was designed around simulated targets.

But once Gemini had unintended internet access, it was able to use publicly available information and credentials to access real systems. In one case, the model reportedly guessed credentials until it gained access. In two others, credentials found in a public repository helped it reach protected systems.

Google said Gemini stopped its activity after recognizing that the systems were real, and the affected organizations were notified.

But the incident exposes something security teams should take seriously.

An AI agent doesn't need to be malicious to become a security problem.

It only needs access, autonomy, and the wrong boundary.

AI Agents Are Changing the Security Boundary

Traditional applications usually do what they are programmed to do.

AI agents can interpret information, make decisions, use tools, access systems, and continue through multi-step tasks.

That creates a different security model.

An agent might have access to:

Cloud environments
APIs
Code repositories
Credentials
Internal applications
Browsers
Databases
External websites

The more tools an agent can use, the more important the boundaries around those tools become.

A mistake that would normally stop at a screen can become an action across multiple systems.

The Credential Problem Is Still There

There is another important lesson here.

The AI didn't need some futuristic zero-day to get access.

It used things that already existed.

Public information.

Credentials.

Internet access.

Weak boundaries.

That matters because organizations can spend heavily on advanced AI security while still leaving basic access paths exposed.

AI doesn't eliminate old security problems. It can make them faster to exploit.

Security Testing Needs Security Controls Too

This incident also raises an uncomfortable question.

Who is monitoring the security agent while it is testing security?

If an AI system can scan, discover, authenticate, execute actions, and move through an environment autonomously, the test itself needs guardrails.

That means security testing environments need:

Strict network isolation
Explicit allowlists
Clear target boundaries
Credential controls
Continuous monitoring
Immediate containment mechanisms
Logging of every agent action

A test environment cannot simply be considered safe because the targets are supposed to be fake.

The environment itself has to be treated as part of the attack surface.

This Is Where Continuous Validation Matters

This is also why security validation cannot be limited to checking whether a control exists.

Organizations need to understand what happens when a real attack path is exercised.

Can an attacker reach the asset?

Can credentials be abused?

Can the attacker move from one system to another?

Does the security stack detect the behavior?

Can the SOC respond before the activity spreads?

This is the problem Seceon aiBAS360 is built around: continuously simulating realistic attack techniques and validating whether existing security controls actually detect and respond to them.

The goal isn't simply to generate another security report.

It's to answer a much more practical question:

"If someone actually tried this attack path, would our defenses stop it?"

The New Security Question

AI agents are becoming capable of performing increasingly complex tasks.

That means security teams need to move beyond asking:

"Is this AI model safe?"

The better question is:

"What can this AI access, what can it change, and what happens if it makes the wrong decision?"

That applies to AI used for cybersecurity as much as AI used for business operations.

An agent with no access has limited impact.

An agent with broad access and weak controls can become a completely different security problem.

The Bigger Takeaway

The Gemini incident wasn't a conventional cyberattack against those three companies.

It was a security evaluation that crossed its intended boundary.

And that's exactly why it matters.

As AI agents become more autonomous, the boundary between testing, automation, and real-world action is becoming thinner.

Security teams can't assume that an AI agent will always stay inside the box.

They need to continuously test the box itself.

Because the next security failure may not come from an attacker breaking through your defenses.

It may come from a trusted AI system being given access to something it was never supposed to reach.

FAQ

What happens when an AI agent gets access to real systems?

An AI agent can potentially interact with real applications, credentials, APIs, cloud environments, and other systems. If access boundaries are weak, an action intended for a test environment can have real-world consequences.

Why are AI agents becoming a cybersecurity concern?

AI agents can interpret information, use tools, make decisions, and perform multi-step actions. This creates a larger security boundary than traditional software and makes access controls, monitoring, and containment increasingly important.

How can organizations secure AI agents?

Organizations should apply strict network isolation, allowlists, credential controls, least-privilege access, continuous monitoring, and clear boundaries around what an AI agent can access or modify.

Why is security validation important for AI environments?

Security validation helps organizations determine whether their controls actually detect and stop realistic attack paths rather than simply confirming that a security control exists.

How can Seceon aiBAS360 help with security validation?

Seceon aiBAS360 continuously simulates realistic attack techniques to validate security controls and identify gaps across an organization's environment.

Source: Reuters, September 2026.

Malware Doesn't Need a Command Server Anymore

Anurag Singh — Fri, 18 Sep 2026 08:14:30 +0000

For years, one of the basic assumptions in malware detection was that compromised systems eventually need to communicate with some attacker-controlled infrastructure.

A domain. An IP address. A command-and-control server. Something security teams can discover, block, investigate, or take down.

But attackers are finding another option.

What if the command infrastructure is a public blockchain?

The Blockchain Can Become the Dead Drop

A new Chainalysis report describes a technique it calls Blockchain Dead Drops (BDD).

Instead of keeping malware instructions on a conventional server, attackers can place instructions in blockchain transactions or smart contracts. An infected device can then retrieve those instructions when needed.

The important part isn't that malware suddenly became blockchain-based.

The malware can still get onto a device through more conventional methods, such as malicious downloads or supply-chain attacks.

The difference comes later.

Instead of asking a compromised machine to contact a traditional command server, attackers can use blockchain infrastructure as a durable communication layer.

Why Would Attackers Do This?

Traditional command infrastructure has weaknesses.

A domain can be seized.

A server can be taken offline.

An IP address can be blocked.

A hosting provider can terminate an account.

A public blockchain introduces a different problem for defenders.

The data written to the blockchain remains recorded, and the infrastructure itself isn't something a security team can simply shut down.

Chainalysis says this durability can allow campaigns to continue even after domains, servers, or repositories associated with an operation have been disrupted.

That's the interesting security shift.

The attacker doesn't necessarily need infrastructure that they control completely. They can use infrastructure that already exists publicly.

The Numbers Are Getting Harder to Ignore

According to Chainalysis, malicious writes associated with blockchain dead drops increased from an average of 2.06 per day to 11.1 per day, a 440% increase in less than a year. The company is tracking this activity across five major blockchains and more than a dozen malware strains.

Chainalysis also says the technique has attracted nation-state activity, including operators associated with North Korea and Iran.

That doesn't mean every blockchain transaction is suspicious.

It means defenders have another place where malicious infrastructure can hide.

The Visibility Problem Is Bigger Than the Blockchain

This creates an interesting challenge for security operations.

A traditional investigation might look for:

Suspicious DNS requests
Connections to known malicious IPs
Unusual HTTP traffic
Repeated beaconing
Abnormal process activity
Known command-and-control domains

But what happens when the attacker doesn't depend on a conventional C2 server?

The investigation has to become more focused on behavior and context.

What process is making the connection?

Which endpoint is generating it?

Is the traffic normal for that system?

Did the activity start after another suspicious event?

Is the same behavior appearing across multiple machines?

The blockchain may be where the attacker stores instructions, but the compromised endpoint still has to retrieve and act on them.

That's where endpoint and network telemetry remain important.

Security Teams Can't Block What They Can't See

This is where broader security visibility becomes valuable.

Platforms such as Seceon OTM are designed to bring together security signals across network, endpoint, identity, cloud, and application environments.

That doesn't mean a security platform automatically detects every blockchain dead drop.

It means security teams can investigate the surrounding behavior instead of relying only on known malicious domains or fixed indicators.

If a normally quiet endpoint suddenly begins communicating with unusual destinations, starts a suspicious process, and shows other abnormal activity, those signals can provide useful context even when the attacker's infrastructure isn't a traditional C2 server.

The C2 Problem Is Changing

Attackers don't always need to build better infrastructure.

Sometimes they can simply find infrastructure that defenders don't control.

Cloud services changed the way attackers host malware.

Legitimate platforms created new ways to blend malicious traffic with normal traffic.

Now public blockchains are being used as another layer for durable command infrastructure.

The lesson isn't that blockchain itself is dangerous.

It's that security assumptions become dangerous when attackers find a way around them.

What Security Teams Should Take Away

The old question was:

"What malicious server is this machine communicating with?"

The modern question is broader:

"What is this machine doing, why is it doing it, and does that behavior make sense in context?"

That shift matters because infrastructure can change.

Domains disappear.

Servers get seized.

IPs rotate.

Attackers move to legitimate services.

And now, in some campaigns, blockchain transactions and smart contracts can become part of the communication layer.

The more durable the attacker's infrastructure becomes, the more important behavioral visibility becomes for defenders.

The Bigger Takeaway

Cybersecurity has always involved an infrastructure arms race.

Defenders build systems to detect and block attacker infrastructure.

Attackers find ways to make that infrastructure harder to disrupt.

Blockchain dead drops are another example of that evolution.

The future of threat detection can't depend only on knowing where attackers are hosting their servers.

Sometimes, the infrastructure isn't theirs.

It's already everywhere.

You Have One Identity. Your Security Stack Sees Seven.

Anurag Singh — Tue, 08 Sep 2026 10:05:50 +0000

I was mapping out access for a mid-sized engineering org a while back, and we hit a wall almost immediately: nobody could tell us, with confidence, how many accounts one senior engineer actually had.

By the time we finished counting, the answer was seven. Active Directory account. Okta identity. An AWS IAM role. A GitHub account with org-admin on two repos. Microsoft 365 access. A VPN identity. A privileged role in a cloud console nobody remembered granting.

Seven accounts. One person. And not one system in that stack had the full picture.

That's not a rare setup. It's basically the default now, especially for anyone touching infrastructure, CI/CD, or cloud resources regularly. And it creates a strange asymmetry: for your SOC, that's seven disconnected pieces of data sitting in seven different consoles. For an attacker who compromises just one of those seven, it's one identity with several paths into the org, and they only need to find the weakest one.

The Identity You Can See Isn't the Identity You Actually Have

Identity data is scattered by design. Directories, identity providers, cloud platforms, SaaS apps, HR systems, PAM tools, VPNs, databases — each one knows a slice of the truth about an account, and almost none of them know the whole story about the person or entity behind it.

Here's a scenario worth sitting with. A developer suddenly accesses a repository they've never touched. Around the same time, that same person authenticates from an unfamiliar location, picks up a new privilege, and reaches a cloud resource they don't normally go near.

Any one of those, alone, has a boring explanation. New project, new laptop, new access request that hasn't been revoked yet. But stacked together, on the same identity, in a short window, that combination starts looking a lot less boring. The hard part was never really detecting each event individually. Most tools can do that. The hard part is realizing all four events belong to the same person, and understanding what that person can actually reach if they've been compromised.

Accounts Aren't the Same Thing as Identities

Traditional identity monitoring hands security teams siloed views almost by default. Active Directory shows one account. Okta shows another. AWS shows a third. Every SaaS app you add stacks another account and another set of permissions on top.

Which creates a pretty basic mismatch: the security team sees accounts. What they actually need to understand is identities. That gap matters more as an org scales, because a dormant account can quietly become active, a privileged identity can start behaving differently, a service account can touch an application it's never touched before, and permissions can pile up on someone's profile for years without anyone reviewing why they're still there. Without something correlating those accounts back to one entity, all of that stays scattered across dashboards nobody's cross-referencing in real time.

Risk Isn't a Single Login Event

Not every identity carries the same weight. A standard employee account behaving exactly like it always does is a non-event. A privileged admin account suddenly reaching for something unfamiliar is not. A dormant account waking up isn't the same story as a service account running its normal, scheduled workload.

Treating all of these the same way, as isolated login events, is part of why alert fatigue exists in the first place. What actually matters is a continuously updated read on which identities are becoming risky right now, not a static list of who technically has an account.

Knowing an Identity Is Risky Isn't the Same as Knowing What It Can Reach

This is the part that's easy to skip past. A privileged identity connected to a dozen applications, several groups, and multiple cloud resources represents a very different level of exposure than a similarly "risky-looking" identity that's isolated to one low-value system. If either one gets compromised, the actual damage depends entirely on its access paths, not just on the fact that something looked unusual.

Being able to visualize that, what applications an identity touches, which groups it belongs to, what privileged access it holds, and what the realistic blast radius looks like if it's compromised, turns "this account triggered an alert" into something an analyst can actually act on.

Detection Is Only Half the Problem

Finding a risky identity is the easier half. The harder question is what happens in the minutes right after that.

If every high-risk identity requires a manual ticket, a handoff to another team, and three rounds of approval before anything happens, your response time is going to lose to an attacker who's already moving. This is exactly the kind of decision that benefits from being pre-approved and automated for high-confidence cases: lock the account, force MFA re-enrollment, clean up a dormant identity, contain a privileged account that's acting outside its normal pattern. Not to cut humans out of the loop, but to cut the unnecessary waiting out of the cases where the evidence is already clear.

Identity Attacks Rarely Look Like Malware

One of the more frustrating things about identity-based attacks is that they often skip the part your endpoint tools are built to catch. There's no malicious file, no obvious exploit. Just a valid credential, used in a way that doesn't quite match how it's normally used: impossible travel, an MFA bypass, credential stuffing, a privileged identity reaching somewhere it's never gone before.

Every one of those can look completely legitimate to a control that's only checking "is this credential valid." The behavior around the credential is usually where the real story is, which is exactly why this has to be a correlation problem, not a single-signal detection problem.

This Gets Worse, Not Better, at MSSP Scale

For a single enterprise, identity fragmentation might mean juggling a dozen systems. For an MSSP managing multiple customers, that same fragmentation exists per tenant, and it multiplies. Different identity providers, different directories, different cloud environments, different policies, times however many customers you're responsible for. Without a centralized way to score and monitor identity risk across tenants, analysts end up manually switching between disconnected consoles for every single customer, which doesn't scale past a handful of accounts.

Where I've Found This Actually Gets Solved

I'll be upfront: I work with Seceon. What convinced me this was worth writing about wasn't a feature list, it was watching how their aiSecurity UIDGuard360 handles the seven-accounts-one-person problem specifically. It resolves fragmented accounts across directories, cloud, HR, and SaaS sources into a single canonical identity, and scores risk continuously across credential, privilege, activity, access, behavioral, and compliance signals instead of treating every login as its own isolated event.

That's the shift that actually matters here. Not another dashboard, another data source connected to the pile. The difference between an analyst starting an investigation with "this account generated an alert" versus starting with "this person has these seven accounts, these privileges, and this level of risk right now" is enormous, and it's the difference that decides whether an investigation takes twenty minutes or two hours.

The Real Shift

Identity security has spent years focused on authentication, MFA, and access reviews. Those still matter. But modern identity attacks don't stop at the login screen. An attacker compromises an identity, reaches an application, touches cloud infrastructure, picks up a privileged role, and starts moving toward something valuable. The identity is the thread connecting every one of those steps.

Which means the real question was never just "how many identities do we have." It's closer to: who does this identity actually belong to, what can it reach, how does its behavior compare to normal, and what happens the moment something about it changes.

That's a harder problem than counting accounts. It's also the one that actually matters.

A Human Attacker Used AI Agents to Run a 10-Hour Intrusion. Here's What That Actually Means for Your Pipeline.

Anurag Singh — Mon, 07 Sep 2026 11:14:15 +0000

The most unsettling number in cybersecurity right now might be 10 hours.

Not 10 days. Not 10 weeks. 10 hours.

In a recent Unit 42 investigation, researchers responded to an enterprise intrusion where a human threat actor used frontier AI models and attack-specific agentic frameworks to automate large parts of the attack. The result: more than 50 MITRE ATT&CK techniques compressed into less than 10 hours, work that would normally take a human operator roughly two weeks.

The attack didn't stop at getting a foothold. The AI agents mapped the internal environment, searched source repositories, obtained root credentials, triggered unauthorized CI/CD activity, and targeted cloud AI infrastructure.

If you work anywhere near a CI/CD pipeline, a source repo, or a cloud deployment key, that list should sound uncomfortably familiar. This wasn't an attack on some abstract "enterprise network." It moved through the exact systems most engineering teams touch every day.

Attacks Used to Be Sequential. Now They're Parallel.

Defenders have long thought about intrusions as a chain: initial access, discovery, credential access, lateral movement, persistence, exfiltration. The steps were never the hard part for attackers. Time was. Reconnaissance takes time. Finding a usable credential takes time. Understanding an unfamiliar environment takes time.

AI agents change that math. Instead of one operator working through each step by hand, several agents can work through different parts of an environment at once, one testing credentials while another maps cloud resources while a third pokes at a CI/CD pipeline. The attacker stops moving through the kill chain step by step and starts running several branches of it simultaneously.

Picture the difference. A traditional intrusion looks roughly like: compromise, investigate, find credentials, move, repeat. An agentic one looks more like a fan-out: compromise, then in parallel, map the environment, search repositories, test credentials, identify cloud resources, poke at CI/CD, hunt for privileged access — all running at once instead of in sequence.

That parallelism is the real shift, and it's specifically bad news for anything resembling modern software delivery, where a repo, a CI runner, an API token, and a cloud deployment target are all sitting a few hops apart from each other.

The Part of This Story Developers Should Actually Care About

Most write-ups on this kind of intrusion focus on the SOC's problem. But look again at what the agents actually did: searched source repositories, created activity around CI/CD, obtained credentials, and moved into cloud infrastructure. That's not a SOC-only story. That's a software supply chain story.

A few uncomfortable questions worth sitting with if you maintain a pipeline:

How long does a leaked CI/CD token stay valid? If a token doesn't expire quickly and isn't scoped tightly, an agent that finds it has plenty of runway to use it.

Does your CI system log and alert on unexpected pipeline triggers, or would an off-schedule build just blend into normal noise? An automated attacker doesn't need to trigger a deploy at 3 AM to look suspicious if your pipeline runs constantly anyway.

Are your repo access tokens scoped to what they actually need, or does "make it work" access accumulate the same way over-permissioned service accounts do everywhere else? An agent doesn't need a superuser credential if a moderately-permissioned one gets it 80% of the way there.

Would unusual repository access even stand out? A read on a repo nobody usually touches is exactly the kind of low-noise signal that traditional monitoring wasn't built to catch, because it doesn't look like "an attack." It looks like someone browsing code.

None of these are new problems. They're the same access-hygiene questions security teams have been asking about human credentials for years. What's changed is the speed at which something can find and use a weak answer to any one of them.

Why the SOC's Bottleneck Is Now a Race Against Compute

Most SOCs already run into a familiar wall: too many alerts, too many dashboards, too few analysts. Add an automated attacker to that picture and a new asymmetry shows up. A human analyst might spend 20 minutes deciding whether an authentication anomaly matters. In that same 20 minutes, an automated attacker can be testing several other paths in parallel. The defender's bottleneck is human attention. The attacker's bottleneck is increasingly just compute, and compute scales a lot faster than headcount.

That's the actual problem underneath the AI-vs-AI framing people reach for. It's not really "attackers have AI so defenders need AI." It's that a tool watching only endpoint telemetry can't understand an attack moving through identity, cloud, source code, CI/CD, and AI infrastructure in the same hour. Neither can a tool watching only network traffic, or only identity. Each one has a piece of the story. The attacker doesn't care which product owns which alert. It cares about the relationships between systems, so that's what the defense has to see too.

Six Events, Six Alerts, or One Attack

Here's a version of how that plays out. A developer account authenticates from an unusual location. A few minutes later, that same identity accesses a repository it doesn't normally touch. Shortly after, a new API token gets created. Then a CI/CD pipeline kicks off unexpectedly. Not long after that, a cloud workload starts talking to a new external destination. And finally, a privileged account performs an administrative action nobody scheduled.

Looked at individually, that's six alerts, each with a plausible innocent explanation. Looked at together, in that order, in that timeframe, it's one attack. That gap between six isolated alerts and one understood attack is exactly where most SOCs are still losing time.

What an Attack Graph Gives You That an Alert List Doesn't

An alert list tells you something happened, somewhere, at some point. An attack graph asks a different set of questions: who initiated it, which identity was involved, which device was used, what changed afterward, which systems were touched, what credentials appeared, what network connections followed, which cloud resources got accessed, what happened next.

That second model is a lot closer to how these intrusions actually unfold, because attacks are relationships between events, not a pile of isolated ones. This is also why SIEM isn't going away even as the conversation shifts toward AI-driven detection. When an attack moves this fast, historical and cross-domain context is worth more, not less. The problem was never that SIEM collects too little data. It's that collecting data and understanding relationships between events are two different jobs, and most SOC workflows still treat the first one as if it were the second.

Detection Alone Buys You Very Little Time

Here's the part worth sitting with: detecting an event in seconds doesn't help much if it then takes two hours to figure out that the event is connected to five other things. A fast detection followed by a slow investigation is still, functionally, a slow response, and an automated attacker doesn't need much of that gap to keep moving.

That reframes what a security platform actually needs to be good at. Detection is table stakes. The harder, more valuable capability is compressing the distance between an event happening and someone (or something) understanding what it's actually connected to.

This Is the Problem Seceon Is Built Around

I'll be upfront: I work with Seceon, so weigh this accordingly.

What drew me to their approach specifically is that it doesn't try to solve this with a smarter alert. It's built so that an identity anomaly, an endpoint event, a network connection, and a cloud action can be evaluated together instead of separately, because that's the only way a six-alert sequence like the one above gets recognized as one attack instead of six tickets in six different queues. The AI part isn't the interesting bit on its own. What it has access to see, and whether it can connect that across identity, endpoint, network, and cloud, is what actually determines whether it's useful during something moving this fast.

The Analyst's Job Is Changing, Not Disappearing

None of this makes the human analyst less relevant. If anything, it raises the value of good judgment, because the routine work, opening repetitive alerts, manually cross-referencing dashboards, reconstructing an obvious attack chain by hand, is exactly the kind of thing that should get automated away. What shouldn't get automated away is deciding whether a high-confidence containment action is actually the right call, threat hunting for the stuff automation won't catch, and understanding what an incident actually means for the business behind it.

The goal was never to remove the analyst from the loop. It's to remove the waiting around the analyst.

The Real Takeaway

The significance of the Unit 42 investigation isn't just that AI was involved in an attack. It's that AI compressed a workflow that would normally require serious human effort and time into something that fit inside a single work morning. More than 50 techniques. Multiple layers of an enterprise. Credentials, repositories, CI/CD, cloud infrastructure. All inside a dramatically shorter window than defenders have historically had to work with.

That's not really a story about AI being scary. It's a story about the amount of time available for detection and response getting smaller, in systems a lot of engineering teams touch every single day. The attacker doesn't need to be smarter than the SOC. It just needs to be faster, and right now, speed is the thing most security architectures aren't built for.

FAQ

What is an agentic AI attack?
An agentic AI attack is an intrusion where a threat actor uses autonomous or semi-autonomous AI agents to carry out parts of the attack, reconnaissance, credential testing, lateral movement, without manually executing each step. This lets a single human operator run an intrusion at a speed and scale that would normally require a coordinated team.

How did attackers use AI in the Unit 42 investigation?
According to Unit 42's reporting, a human threat actor used frontier AI models and attack-specific agentic frameworks to automate large parts of an enterprise intrusion, compressing over 50 MITRE ATT&CK techniques into under 10 hours, including mapping the environment, searching source repositories, obtaining credentials, and triggering unauthorized CI/CD activity.

Why is CI/CD a target in AI-driven attacks?
CI/CD pipelines typically hold or generate credentials, deployment keys, and access to source code and cloud infrastructure, all in one place. For an automated agent searching for a fast path to privileged access, a pipeline with loosely scoped tokens or under-monitored triggers is a high-value target.

Can traditional SIEM tools detect agentic AI attacks?
SIEM remains useful for centralized, cross-domain visibility, but detecting an agentic attack usually requires correlating identity, endpoint, network, and cloud signals together rather than reviewing them in separate consoles. A SIEM that only stores logs without helping connect those signals across domains will still miss the pattern.

Does AI-driven attack automation mean human analysts become less important?
No. It shifts what analysts spend time on. Routine work like triaging repetitive alerts or manually reconstructing an attack chain becomes a better fit for automation, while human judgment becomes more valuable for validating high-confidence response actions, threat hunting, and understanding business impact.

Your Network Router May Be a Blind Spot. Attackers Are Counting on It.

Anurag Singh — Thu, 03 Sep 2026 09:30:32 +0000

A security team can monitor endpoints.

It can monitor identities.

It can collect cloud logs.

It can deploy EDR, XDR, SIEM and network monitoring.

But what happens when the infrastructure carrying the traffic is compromised?

That question became much more interesting after new research into the China-nexus threat actor known as Fire Ant.

Sygnia reported that Fire Ant expanded its activity beyond VMware environments and targeted Cisco IOS XR routers, TACACS authentication infrastructure and Linux management hosts.

The concerning part wasn't simply that routers were compromised.

It was what attackers did after getting control of trusted infrastructure.

The Router Wasn't Just a Router Anymore

A compromised endpoint usually gives an attacker access to a system.

A compromised router can give something much more valuable:

Perspective.

According to Sygnia's investigation, Fire Ant used compromised routers to capture network traffic and create covert connectivity.

That changes the role of the compromised device.

It is no longer just another asset inside the network.

It becomes a place from which the attacker can observe how the environment communicates.

And that's a very different security problem.

The Trust Layer Is Becoming an Attack Surface

Most security programs focus heavily on:

Endpoints
Servers
Applications
Cloud workloads
User identities

Network infrastructure can receive less attention because it is often treated as foundational infrastructure rather than an active security boundary.

But routers, authentication servers and management hosts sit in extremely privileged positions.

They help determine:

Where traffic goes
Who can authenticate
Which systems can communicate
How administrators manage infrastructure
What security telemetry gets generated

Compromise those layers and an attacker may gain more than access.

They may gain control over the environment's visibility and trust relationships.

When Your Logs Can't Be Trusted

This is one of the most interesting parts of the Fire Ant investigation.

Sygnia reported that the attackers manipulated telemetry and evidence sources, including router logging and authentication-related records.

That creates a difficult question for defenders:

What if the system generating your evidence has also been compromised?

Security teams often assume that logs are telling them what happened.

But sophisticated attackers can attempt to modify, suppress or bypass the evidence.

That means security monitoring cannot always depend on a single telemetry source.

One Alert May Not Tell the Story

Imagine this:

A network device shows an unusual configuration change.

At roughly the same time, an administrator account authenticates in an unusual way.

A management server starts communicating with an unexpected destination.

Network traffic begins moving through a previously unseen path.

Individually, each event may look explainable.

Together, they may describe an intrusion.

This is where cross-domain correlation becomes important.

The SOC needs to connect:

Network + Identity + Authentication + Endpoint + Configuration + Behavior

instead of investigating each alert independently.

Why Network Detection Needs More Context

Network monitoring can tell you that something unusual is happening.

But context tells you whether it matters.

For example:

Unusual network connection

is one signal.

But:

Unusual network connection + privileged identity + unexpected configuration change + abnormal management activity

is a much stronger investigation lead.

The difference isn't necessarily another detection rule.

It's the ability to connect the evidence.

The New Challenge for Security Teams

For years, security teams have asked:

“Are we collecting enough logs?”

The better question today may be:

“Are we collecting enough independent evidence to know when one source is lying?”

That is a very different security mindset.

A resilient SOC shouldn't depend entirely on one platform, one log source or one security control.

It should be able to compare signals across different parts of the environment.

Where SIEM Still Matters

This doesn't make SIEM less important.

It makes centralized security analytics more important.

A SIEM can provide the historical context needed to understand:

Authentication activity
Network events
Configuration changes
System activity
Privileged actions
Security alerts

But the real value comes from what the SOC can do with that data.

If every event remains isolated, analysts still have to manually connect the dots.

If events are correlated across multiple security domains, an investigation can start from a much stronger position.

Where XDR and NDR Add Context

NDR can help identify unusual network behavior.

XDR can connect signals across security layers.

UEBA can help identify abnormal user and entity behavior.

SIEM provides centralized investigation and historical context.

SOAR can help automate defined response actions.

The important part is not simply having all these technologies.

It's whether they can work together when an attacker moves between them.

Where Seceon OTM Fits

This is one reason a unified security architecture can be useful.

Seceon OTM brings together capabilities including SIEM, XDR, NDR, UEBA, SOAR, identity, cloud and other security telemetry within a unified security model.

For a network-focused incident, that means the investigation doesn't have to stop at:

“The router generated an alert.”

The SOC can look for related activity across:

Network
Identity
Endpoint
Cloud
Authentication
User behavior

That broader context can help security teams determine whether a network anomaly is simply an operational issue or part of a larger attack path.

The Blind Spot Isn't Always Where You Think

Security teams naturally focus on the systems that attackers are known to target.

But sophisticated threat actors don't always attack the final destination first.

Sometimes they attack the infrastructure that provides:

access

visibility

trust

connectivity.

That's why network infrastructure deserves the same security attention as endpoints and cloud workloads.

What Security Teams Should Reconsider

A modern security architecture should ask:

Are network devices continuously monitored?
Are authentication systems treated as high-value assets?
Can security teams detect unusual configuration changes?
Are network events correlated with identity activity?
Can telemetry from different sources be investigated together?
What happens if one logging source is compromised?
Are privileged infrastructure systems included in threat hunting?
Can the SOC validate suspicious activity using independent evidence?

These questions can expose gaps that a traditional “more alerts = more visibility” approach may miss.

The Bigger Lesson

Fire Ant is a useful reminder that attackers don't always need to break through the front door.

Sometimes they target the systems that control the doors.

Sometimes they target the systems that authenticate the people using those doors.

And sometimes they target the systems that tell defenders what happened.

That means cybersecurity visibility has to go beyond endpoints and applications.

The infrastructure that connects, authenticates and observes the environment needs to be part of the security picture too.

Because if attackers control the infrastructure you trust, the biggest problem may not be that you can't detect the attack.

It may be that you're looking at an incomplete version of what actually happened.

FAQ

Why are attackers targeting network infrastructure?

Network devices can provide privileged access, visibility into traffic and potential paths toward connected systems. Recent Fire Ant research showed how compromised Cisco routers were used as operational platforms for traffic collection and covert connectivity.

How can SIEM help detect compromised network infrastructure?

SIEM can centralize and correlate network, authentication, configuration and other security events. This can help analysts identify relationships that may not be visible when each telemetry source is investigated separately.

Can Seceon OTM monitor network and identity activity together?

Seceon OTM is designed to bring together security telemetry across areas including network, identity, endpoint, cloud and other security domains. This allows related activity to be investigated within a broader security context.

What is the role of NDR in detecting router-related attacks?

NDR can help identify unusual communication patterns, unexpected connections and abnormal network behavior. Its value increases when network signals can be correlated with identity, endpoint and authentication activity.

What should organizations do if they suspect a network device is compromised?

Organizations should preserve relevant evidence, validate configurations, review authentication activity, examine network telemetry and compare information across independent sources. A compromised device should not automatically be treated as a fully trustworthy source of forensic evidence.

Is monitoring endpoints enough for modern threat detection?

No.

Endpoints remain important, but modern attacks can involve network infrastructure, identity systems, cloud services, authentication platforms and management systems.

Security teams need visibility across the environment rather than focusing on one security layer.

Final Thought

The most dangerous blind spot in a network isn't always an unknown vulnerability.

Sometimes it's a trusted system nobody expected to become part of the attack.

Routers authenticate.

Routers connect.

Routers observe.

That makes them security assets, not just networking assets.

If the SOC doesn't have visibility into the infrastructure that connects the environment, it may be missing part of the attack story.

AI Is Coming for Critical Infrastructure. Can Traditional SOCs Keep Up?

Anurag Singh — Wed, 02 Sep 2026 07:05:56 +0000

A power grid does not get a second chance.

A water utility cannot simply “reset” its environment.

A manufacturing plant cannot treat an OT incident like another endpoint alert.

That is what makes the current shift in cyberattacks so important.

Attackers are increasingly using AI to accelerate reconnaissance, identify weaknesses and automate parts of the attack lifecycle.

Recent reporting has highlighted AI-enhanced attacks against interconnected energy systems, including operational technology environments.

The question is no longer whether AI will be used in cyberattacks.

It is:

Can security operations detect and respond at the same speed?

The Critical Infrastructure Attack Surface Has Changed

Critical infrastructure used to look relatively isolated.

Today, that picture is very different.

Power generation, utilities, manufacturing, transportation and other industrial environments increasingly connect:

IT networks
OT networks
Cloud services
Remote access systems
Identity platforms
IoT devices
Third-party systems
Industrial control systems

That connectivity creates operational advantages.

It also creates more paths into environments where a cyber incident can eventually become a physical or business disruption.

And attackers understand this.

AI Is Reducing the Time Between Discovery and Exploitation

AI doesn't necessarily need to invent an entirely new attack technique.

It can make existing techniques faster.

AI can help attackers:

Analyze large amounts of technical information
Identify potentially vulnerable systems
Automate reconnaissance
Generate or modify attack code
Improve social engineering
Find weaknesses across connected environments
Adapt attacks based on discovered information

That changes the defender's problem.

The issue isn't simply:

“Can we detect the attack?”

It's:

“Can we understand what is happening before the attacker moves to the next system?”

OT Security Makes This Even Harder

Traditional IT security often assumes that an affected machine can be isolated.

OT environments have different constraints.

A security team may be dealing with:

Legacy systems
PLCs
Industrial protocols
Long equipment lifecycles
Limited patch windows
Remote operational access
Safety requirements
Systems that cannot simply be taken offline

This creates a major SOC challenge.

An alert on an endpoint might look harmless by itself.

But combine it with:

identity activity + network behavior + unusual OT communication + endpoint telemetry

and the situation can look very different.

That's where correlation becomes more important than simply collecting more alerts.

The Problem Isn't a Lack of Security Data

Most modern organizations already generate enormous amounts of telemetry.

The problem is that the data often lives in different places.

One system sees the endpoint.

Another sees network traffic.

Another sees identity.

Another monitors cloud activity.

Another protects OT.

Another generates vulnerability alerts.

The SOC analyst is then expected to connect the dots.

That model becomes increasingly difficult when attackers are moving faster.

Detection without context creates noise.

Context without automation creates delay.

Automation without correlation creates risk.

A modern security operation needs all three:

Context + Correlation + Controlled Automation

What an AI-Driven SOC Should Actually Do

An AI SOC should not simply generate more AI-generated alerts.

That would make the problem worse.

Instead, AI should help security teams move through the investigation lifecycle faster.

A modern architecture should be able to:

Collect telemetry across IT, OT, identity, cloud, endpoint and network environments.
Normalize the data so different security signals can be understood together.
Correlate seemingly unrelated events into meaningful attack patterns.
Establish behavioral baselines to identify activity that doesn't fit normal behavior.
Investigate automatically before sending every event to an analyst.
Prioritize incidents based on risk and context rather than alert volume.
Respond within defined guardrails when automated action is appropriate.
Keep humans in control for decisions that require judgment, safety or business context.

This is a fundamentally different operating model from simply adding another detection tool.

Why SIEM Alone Isn't Enough

SIEM remains important because security teams need centralized visibility and historical context.

But modern environments require more than log collection.

Consider a hypothetical incident:

An employee account suddenly authenticates from an unusual location.

A few minutes later, an endpoint starts communicating with an unfamiliar internal host.

Network telemetry shows unusual traffic toward an OT segment.

An industrial device then begins communicating in a pattern that hasn't appeared before.

Looking at those events individually could produce several unrelated alerts.

Looking at them together could reveal a developing intrusion.

That is the difference between:

alert management

and

threat detection.

Where XDR, UEBA and SOAR Fit

This is where the modern SOC architecture becomes important.

SIEM provides centralized security data and investigation context.

XDR helps connect security signals across multiple control points.

UEBA helps identify unusual behavior involving users, entities and systems.

NDR provides visibility into network behavior.

OT security brings industrial environments into the security picture.

SOAR enables controlled response automation.

The real value comes when these capabilities aren't operating as completely disconnected islands.

Where Seceon OTM Fits

This is also where Seceon OTM fits into the broader AI SOC discussion.

Seceon OTM is designed around a unified security architecture that brings together capabilities including SIEM, XDR, SOAR, NDR, UEBA, ITDR, cloud and OT security.

The important idea isn't simply having all of those product names.

It is having the telemetry and security context available together so the SOC can investigate relationships between events.

For a critical infrastructure environment, that matters because an identity event, endpoint event, network event and OT event may all be pieces of the same attack.

Instead of asking:

“Which tool generated this alert?”

the SOC can ask:

“What is actually happening across the environment?”

That is a much more useful question.

The New SOC Metric: Time to Understand

Security teams have traditionally focused on metrics such as:

MTTD
MTTR
Alert volume
False-positive rate

Those metrics still matter.

But AI-driven attacks introduce another important question:

How long does it take the SOC to understand the attack?

Because detecting five separate alerts in five minutes isn't necessarily good detection.

If analysts need another two hours to understand that those alerts belong to one attack chain, the organization is still operating slowly.

The future SOC needs to reduce the distance between:

Event → Context → Investigation → Decision → Response

What Security Teams Should Look for in an AI SOC

If you're evaluating an AI-driven SOC platform, don't just ask:

“Does it use AI?”

Ask:

Can it correlate identity, endpoint, network, cloud and OT activity?
Can it reduce repetitive L1 investigation?
Can it establish behavioral baselines?
Can it automatically investigate related events?
Can analysts understand why an incident was prioritized?
Can response actions operate within defined guardrails?
Can it support hybrid and on-prem environments?
Can it handle multi-tenant environments for MSSPs?
Can it reduce dependence on multiple disconnected security tools?

Those questions are much more useful than simply comparing AI features on a datasheet.

Critical Infrastructure Doesn't Need More Noise

The cybersecurity industry has spent years adding more sensors.

The next challenge is making those sensors work together.

As attackers use AI to accelerate reconnaissance and exploitation, defenders need to shorten the time between an abnormal event and a meaningful security decision.

For IT environments, that can mean faster incident response.

For OT and critical infrastructure, it can mean something much more important:

preventing a cyber event from becoming an operational event.

The future of critical infrastructure security won't be defined by who has the most alerts.

It will be defined by who can understand, prioritize and respond to the right signals fastest.

And that is where the AI SOC becomes much more than another security product.

FAQ

How is Seceon OTM helping organizations build an AI SOC?

Seceon OTM brings together capabilities such as SIEM, XDR, SOAR, NDR, UEBA, ITDR, cloud and OT security in a unified security architecture.

The goal is to give security teams broader context across their environment so related identity, endpoint, network, cloud and OT signals can be correlated during an investigation.

What is the difference between Seceon OTM and a traditional SIEM?

A traditional SIEM primarily focuses on collecting, storing and analyzing security data.

Seceon OTM extends that model by combining SIEM with capabilities such as XDR, SOAR, NDR and UEBA, allowing organizations to move from simply collecting alerts toward correlation, investigation and automated response.

Can Seceon OTM support OT and critical infrastructure security?

Yes. Seceon OTM includes OT security capabilities alongside IT, network, endpoint, identity and cloud visibility.

This is particularly useful when organizations need to understand relationships between activity across IT and OT environments.

How does AI help reduce SOC alert fatigue?

AI can help correlate related events, establish behavioral baselines, investigate routine alerts and prioritize incidents based on context.

The objective isn't to create more automated alerts.

It is to reduce the number of alerts that analysts have to investigate manually.

Does an AI SOC replace security analysts?

No.

The strongest AI SOC model keeps humans involved for decisions that require judgment, governance, safety considerations and business context.

AI should remove repetitive investigation work so analysts can spend more time on complex threats and strategic security decisions.

What should organizations look for in an AI SOC platform?

Organizations should look beyond the “AI-powered” label.

Important capabilities include:

Cross-domain telemetry correlation
Behavioral analytics
Automated investigation
Threat prioritization
Controlled response automation
IT and OT visibility
Identity and endpoint context
Hybrid and on-prem deployment options
Reduced dependence on disconnected security tools

Final Thought

AI is changing the economics and speed of cyberattacks.

Critical infrastructure cannot afford to respond at yesterday's speed.

The answer isn't necessarily another security tool.

It is a security operation that can connect the signals, understand the attack and act quickly without removing humans from the decision-making process.

The faster attackers can connect the dots, the faster defenders need to do the same.

AI Agents Have Identities Too: Why Non-Human Identity Security Is Becoming a SOC Problem

Anurag Singh — Tue, 01 Sep 2026 09:09:05 +0000

Your security team knows how many employees have access to your systems.

But do you know how many AI agents, service accounts, API keys, and automated workflows have access?

That's becoming a much harder question in 2026.

Organizations are rapidly adopting AI agents to automate everything from software development and customer support to data analysis and security operations.

These agents don't just generate text.

They authenticate.

They access applications.

They call APIs.

They retrieve data.

They execute workflows.

And increasingly, they make decisions and take actions without a human sitting in front of every transaction.

That creates a new cybersecurity challenge:

AI agents need identities too.

And those identities need to be secured.

The Identity Problem Is Getting Bigger

For years, identity security focused primarily on human users.

Employees had accounts.

Administrators had privileged accounts.

Contractors had temporary access.

Security teams built policies around those identities.

Now add:

AI agents
Service accounts
API keys
Machine identities
Bots
Automated workflows
Cloud workloads

The number of identities inside an organization can grow far beyond its number of employees.

And unlike humans, these identities can operate 24/7.

That's where the risk becomes interesting.

An employee might access an application a few times during the day.

An automated agent might make thousands of API calls while nobody is watching.

So the question becomes:

How do you know when an AI agent is behaving abnormally?

What Happens When an AI Agent Gets Too Much Access?

Imagine an organization deploys an AI agent to help developers.

The agent has access to:

GitHub → Cloud APIs → CI/CD → Internal Documentation → Databases

Everything works normally for months.

Then something changes.

The agent suddenly starts:

Accessing repositories it never used before
Calling unfamiliar APIs
Requesting elevated permissions
Downloading unusual amounts of data
Communicating with an external service
Triggering workflows outside its normal pattern

None of these events necessarily means the agent has been compromised.

But together, they should raise a question:

Is this normal behavior for this identity?

That's where traditional identity monitoring starts becoming insufficient.

The New Security Question: What Is the Identity Doing?

Authentication tells you who or what accessed a resource.

Authorization tells you what it is allowed to access.

But security operations also need to understand:

What is it actually doing?

That's where behavioral analytics becomes important.

Consider two scenarios.

Scenario 1

An AI agent accesses the same API it uses every day.

The request volume is normal.

The destination is expected.

The action matches its assigned workflow.

Probably normal.

Scenario 2

The same agent suddenly accesses a sensitive database, requests elevated privileges, and sends data to an unfamiliar external endpoint.

The credentials may still be valid.

The authentication may still be legitimate.

But the behavior is unusual.

That's a security signal.

Why Traditional SIEM Visibility Isn't Always Enough

A SIEM can collect identity events.

It can collect API logs.

It can collect endpoint telemetry.

It can collect cloud activity.

It can collect network events.

But collecting everything doesn't automatically mean you understand what's happening.

The real value comes from connecting those signals.

For example:

AI agent authentication

↓

Privilege change

↓

Unusual API activity

↓

Endpoint anomaly

↓

Suspicious network connection

↓

Sensitive data access

Individually, each event might look manageable.

Together, they could represent an attack chain.

This is why modern security operations increasingly need SIEM + XDR + UEBA + threat intelligence + automated response working together.

Where UEBA Fits

UEBA stands for User and Entity Behavior Analytics.

And the word "entity" matters.

Because the entity doesn't always have to be a human.

It could be:

A user
A service account
An API key
A device
A workload
An AI agent

UEBA can help establish behavioral patterns and identify activity that deviates from those patterns.

For an AI agent, that could mean understanding:

Which applications does it normally access?

Which APIs does it normally call?

How frequently does it operate?

Which resources does it normally touch?

What does its normal behavior look like?

Once you understand the baseline, abnormal behavior becomes easier to identify.

This Is Where Identity Security Meets XDR

Identity security shouldn't exist in a separate security universe.

Suppose an AI agent suddenly behaves abnormally.

The next question isn't just:

"Is the identity suspicious?"

It's:

"What else is happening around it?"

Maybe the endpoint associated with the workflow is communicating with a suspicious destination.

Maybe another identity was compromised.

Maybe a privilege escalation happened immediately before the unusual API calls.

Maybe threat intelligence identifies the destination as malicious.

Now identity activity becomes part of a much larger investigation.

This is where XDR can provide additional context by connecting signals across different security layers.

Where Seceon OTM Fits

This is one of the reasons Seceon's Open Threat Management (OTM) Platform is relevant to this changing security model.

OTM brings together capabilities including:

SIEM + XDR + SOAR + UEBA + Threat Intelligence + Threat Hunting

within a unified security operations platform.

Instead of treating identity, endpoint, network, cloud and application activity as completely separate investigations, OTM is designed to correlate those signals and provide broader context.

For example:

Identity anomaly

↓

UEBA detects abnormal behavior

↓

XDR correlates endpoint and network activity

↓

Threat intelligence adds context

↓

SIEM provides the event history

↓

SOAR can automate an appropriate response

The goal isn't simply to detect that an AI agent did something unusual.

The goal is to understand:

What happened → why it matters → what else is connected → what should happen next

That's a much more useful security question.

AI Agents Are Also Creating a New Access-Control Problem

There's another issue that security teams shouldn't ignore.

AI agents need permissions.

And permissions can accumulate.

An agent might start with access to one application.

Then someone adds another integration.

Then another API.

Then another workflow.

Six months later, nobody remembers exactly why the agent has access to everything it can reach.

This is the same problem security teams have dealt with for years with human identities:

Excessive privileges.

The difference is that automated identities can operate much faster.

If an overprivileged human account is compromised, the attacker may have access to sensitive resources.

If an overprivileged AI agent is compromised or manipulated, it may be capable of taking automated actions across multiple systems.

That's why AI agent identity governance is becoming an important part of cybersecurity.

Security Teams Need an Inventory of Non-Human Identities

You can't protect what you don't know exists.

A practical starting point is building visibility into:

Who has access?

What applications are they connected to?

What credentials do they use?

What permissions do they have?

When were those permissions last reviewed?

What does normal behavior look like?

And for AI agents:

What actions are they actually capable of taking?

This isn't just an IAM problem anymore.

It's becoming part of security operations.

What Should Security Teams Monitor?

If your organization is deploying AI agents, consider monitoring:

1. Agent Identity

Know which AI agents exist and which credentials they use.

2. Permissions

Understand what resources each agent can access.

3. API Activity

Monitor unusual API calls, destinations, and request patterns.

4. Behavioral Changes

Identify activity that differs significantly from the established baseline.

5. Privilege Escalation

Watch for unexpected changes in permissions.

6. Data Access

Monitor unusual access to sensitive information.

7. Network Activity

Correlate agent behavior with network connections and endpoint activity.

8. Response Actions

Have clear policies for what should happen when an agent behaves abnormally.

The MSSP Challenge Is Even Bigger

For an MSSP, this problem scales quickly.

One customer may have a handful of AI agents.

Another may have hundreds of automated identities.

Another may be running thousands of service accounts and API integrations.

Now imagine monitoring all of that across dozens of customers.

The MSSP needs to understand:

Which identity belongs to which customer?

Is this behavior normal for that customer?

Is the same attack pattern appearing across multiple environments?

Which incident should be investigated first?

This is where centralized, multi-tenant security operations become increasingly important.

A platform such as Seceon OTM can help MSSPs bring identity, endpoint, network, cloud and application security signals into a unified operational workflow.

The objective isn't simply to monitor more identities.

It's to make those identities understandable at security-operations scale.

The AI Agent Security Checklist

Before deploying an AI agent into a production environment, security teams should be able to answer:

What identity does the agent use?
What permissions does it have?
Which applications can it access?
Which APIs can it call?
What data can it retrieve?
Can it create or modify resources?
Can it escalate its privileges?
How is its behavior monitored?
What happens if its behavior becomes abnormal?
How quickly can its credentials or access be revoked?

If those questions don't have clear answers, the agent may already represent an unmanaged attack surface.

The Bigger Shift in Identity Security

The traditional identity model was built around:

People → Accounts → Applications

The modern environment looks more like:

People + AI Agents + Service Accounts + APIs + Workloads → Applications + Data + Infrastructure

That's a much bigger identity ecosystem.

And security operations need visibility across all of it.

AI agents aren't going away.

Neither are automation, APIs, cloud workloads, or machine identities.

The organizations that adapt early will be the ones that treat these identities as first-class security entities, rather than invisible infrastructure.

FAQ: AI Agent Identity Security

What is non-human identity security?

Non-human identity security focuses on protecting machine identities such as service accounts, API keys, workloads, bots, and AI agents that authenticate and access organizational resources.

Why do AI agents need identity security?

AI agents often require credentials and permissions to access applications, APIs, data, and infrastructure. If those identities are compromised, overprivileged, or misused, the agent could potentially perform unauthorized actions.

What is AI agent identity governance?

AI agent identity governance involves managing an agent's identity, credentials, permissions, access lifecycle, and authorized actions throughout its operational lifetime.

Can UEBA monitor AI agents?

UEBA can analyze behavior from users and other entities. In environments where AI agents and automated identities generate telemetry, behavioral analytics can help identify activity that deviates from established patterns.

How can SIEM and XDR help with AI agent security?

SIEM can centralize identity, cloud, application, endpoint, and network events. XDR can help correlate related signals across security layers, giving analysts broader context when investigating suspicious activity.

How does Seceon OTM address this problem?

Seceon OTM combines SIEM, XDR, SOAR, UEBA, threat intelligence, and threat hunting in a unified security operations platform. This allows security teams to correlate identity behavior with endpoint, network, cloud, and other security telemetry.

Is AI agent security important for MSSPs?

Yes. MSSPs managing multiple customer environments need visibility into human and non-human identities across different organizations. Centralized and multi-tenant security operations can help make that monitoring more scalable.

The New Identity Perimeter

The identity perimeter is no longer just about employees.

It includes everything that can authenticate and take action.

Users.

Service accounts.

API keys.

Workloads.

AI agents.

And the security question is evolving with it.

It's no longer enough to ask:

"Who logged in?"

We need to ask:

"What identity is acting, what is it allowed to do, and does its behavior make sense?"

That's where identity security, UEBA, SIEM, XDR and automated response start coming together.

And as AI agents become more common, that combination may become less of an advanced capability and more of a baseline requirement.

AI agents are becoming part of the workforce.

Their identities need to become part of the security model too.

MFA Is Enabled. So Why Are Attackers Still Getting In?

Anurag Singh — Mon, 31 Aug 2026 08:52:29 +0000

Your organization has MFA. Your users have strong passwords. Conditional access is enabled. So how is an attacker still getting into the account?

This is one of the uncomfortable questions security teams are facing in 2026.

The problem is that attackers don't always need to defeat MFA.

Sometimes, they simply go around it.

Recent attacks against Microsoft 365 environments have included device-code phishing, session-token theft, password spraying and other techniques designed to obtain authenticated access even when MFA is enabled.

And that changes the identity security conversation.

The question is no longer:

"Do we have MFA?"

It is:

"What happens after authentication succeeds?"

MFA Protects the Login. What Protects the Session?

Think about what happens when you sign into a SaaS application.

You enter your credentials.

You complete MFA.

The application verifies you.

Then it gives your browser a session token.

From that point forward, the application often uses that session to recognize you.

That's convenient.

But it also creates another security problem.

If an attacker obtains that authenticated session, they may not need your password or another MFA challenge to continue operating as you.

The attacker isn't necessarily breaking MFA.

They're stealing the proof that MFA already happened.

This is why session-token theft and session hijacking have become important identity-security concerns.

The Attack Doesn't Always Look Like a Login Attack

Imagine this.

An employee signs into Microsoft 365 normally.

MFA succeeds.

Nothing looks suspicious.

A few minutes later, an attacker starts using a stolen session.

Now the security team sees:

An authenticated user accessing a SaaS application.

A new device or unusual location.

Unusual mailbox activity.

A privileged resource being accessed.

Large amounts of data being downloaded.

Suspicious communication from an endpoint associated with the account.

Individually, some of these events may not trigger a high-confidence incident.

Together, they tell a very different story.

That's where identity security becomes a security operations problem.

The Real Problem Is the Context Around the Identity

Identity systems can tell you that authentication happened.

Endpoint security can tell you what happened on the device.

Network security can tell you where the traffic went.

Cloud security can tell you what resources were accessed.

But an account takeover rarely stays inside one of those categories.

The attacker may move through all of them.

That's why modern detection needs to connect:

Identity + Endpoint + Network + Cloud + SaaS + User Behavior

Instead of asking:

"Was this login legitimate?"

Security teams increasingly need to ask:

"Does everything this identity is doing after the login make sense?"

This Is Where UEBA Becomes Important

User and Entity Behavior Analytics, or UEBA, isn't simply about detecting a suspicious login.

It's about understanding behavior.

For example:

A finance employee normally accesses a small group of applications during business hours.

Suddenly, the same identity accesses several unfamiliar resources, downloads large amounts of data, and starts interacting with systems it has never used before.

The login itself might have been valid.

The behavior isn't.

That's the kind of distinction behavioral analytics can help security teams identify.

And this is where identity signals become much more useful when correlated with the rest of the security environment.

Why SIEM Alone Isn't the Whole Answer

SIEM remains critical because security teams need centralized visibility and historical security data.

But collecting identity logs isn't the same as understanding an identity attack.

Consider this chain:

MFA authentication

↓

New device

↓

Unusual user behavior

↓

Suspicious endpoint activity

↓

Abnormal network connection

↓

Sensitive data access

↓

Potential account takeover

If every signal lives in a different security product, the analyst has to manually connect the dots.

That costs time.

And during an active attack, time matters.

Where Seceon OTM Fits

This is one of the areas where Seceon's Open Threat Management (OTM) Platform can be relevant.

OTM brings together capabilities including:

SIEM + XDR + UEBA + SOAR + Threat Intelligence + Threat Hunting

within a unified security operations platform.

That matters because an identity anomaly shouldn't necessarily be investigated as an isolated identity event.

It can be correlated with endpoint activity.

Network behavior.

Cloud activity.

Threat intelligence.

And other security signals.

For example:

An unusual login occurs.

UEBA identifies behavior outside the normal baseline.

XDR connects the identity activity with an endpoint anomaly.

Threat intelligence adds context around suspicious infrastructure.

SIEM provides the broader event history.

SOAR can help automate appropriate response actions.

Now the analyst isn't looking at six unrelated alerts.

They're looking at a potential attack chain.

The identity is the starting point. The surrounding behavior tells the story.

The Biggest Identity Security Mistake

One of the biggest mistakes organizations can make is treating authentication as the finish line.

Authentication should be the beginning of continuous trust evaluation.

A user successfully passing MFA doesn't automatically mean:

Every subsequent action is legitimate
Every device associated with the session is trustworthy
Every resource request is normal
Every application interaction is expected
Every session should remain valid

Security needs to continue after authentication.

That's especially important as organizations rely more heavily on cloud applications, SaaS platforms, APIs and remote access.

What Should Security Teams Monitor After MFA?

If you're reviewing your identity-security strategy in 2026, don't stop at MFA deployment.

Look at what happens after the user authenticates.

Session Activity

Monitor unusual sessions, devices, locations and access patterns.

User Behavior

Look for activity that significantly differs from the user's normal behavior.

Privilege Changes

Watch for unexpected privilege escalation or access to sensitive resources.

Application Activity

Monitor unusual SaaS and cloud application usage.

Endpoint Signals

Correlate identity activity with what is happening on the user's device.

Network Behavior

Look for unusual destinations, connections or traffic patterns associated with the identity.

Data Access

Watch for abnormal downloads, transfers or access to sensitive information.

The important word here is:

Correlation.

One event rarely tells the whole story.

What About Phishing-Resistant MFA?

This doesn't mean MFA is no longer useful.

Quite the opposite.

Strong authentication remains an important security control, and phishing-resistant methods can significantly improve resistance to credential-based attacks.

But identity security shouldn't depend on a single control.

Even with stronger authentication, organizations still need visibility into:

What happened after access was granted?

Because attackers don't always need to compromise the authentication mechanism itself.

They may compromise the endpoint.

Steal an active session.

Abuse an authorized identity.

Exploit excessive permissions.

Or operate through a trusted application.

Why This Matters for MSSPs

For an MSSP, identity monitoring becomes even more complicated.

Imagine managing security for 50 customers.

Each customer has:

Different identity providers.

Different SaaS applications.

Different users.

Different access policies.

Different normal behavior.

Different risk profiles.

An MSSP can't realistically investigate every identity event manually.

The platform needs to help separate:

Normal behavior → Suspicious behavior → Potential attack

and provide enough context for analysts to act.

This is where a unified security operations approach can become valuable.

With Seceon OTM, MSSPs can bring SIEM, XDR, UEBA, SOAR and threat intelligence into a centralized security operations workflow rather than treating identity activity as a completely separate security problem.

The Identity Perimeter Is Changing

The old security model was largely:

Protect the network perimeter.

Then it became:

Protect the endpoint.

Then:

Protect the identity.

But today, none of these exist in isolation.

An identity can be compromised through an endpoint.

An endpoint can be controlled through a malicious application.

A compromised identity can access cloud resources.

Cloud activity can lead to data exposure.

And network activity can reveal the attack.

The modern security perimeter is increasingly a connected ecosystem.

That's why security teams need visibility across the entire attack chain.

The Question Security Teams Should Be Asking

Don't ask only:

"Is MFA enabled?"

Ask:

"If an attacker gets past the login, how quickly would we know?"

That's a much harder question.

And it's the one that matters.

Because authentication tells you who successfully entered.

Security operations need to determine whether that person is actually behaving like themselves.

That's where identity analytics, UEBA, XDR, SIEM, threat intelligence and automated response start working together.

And that's the direction Seceon is taking with OTM.

Not just detecting the login.

Understanding what happens next.

FAQ: MFA Bypass and Identity Security

Can attackers bypass MFA?

Yes. Attackers can use techniques such as adversary-in-the-middle phishing, device-code phishing, MFA fatigue, credential theft and session-token theft to obtain or abuse authenticated access.

Does MFA prevent account takeover?

MFA significantly reduces the risk of many credential-based attacks, but it isn't a complete account-takeover defense. Attackers can target sessions, tokens, endpoints, applications and users after authentication.

What is session-token theft?

Session-token theft occurs when an attacker obtains a token representing an already authenticated session and uses it to impersonate the legitimate user.

What is UEBA?

UEBA stands for User and Entity Behavior Analytics. It analyzes behavioral patterns to identify activity that deviates from what is considered normal for a user or entity.

How can SIEM help detect identity attacks?

SIEM can centralize identity, endpoint, network, cloud and application events, making it easier to investigate activity across different security domains and build a timeline of an incident.

How does Seceon OTM help with identity-related threats?

Seceon OTM combines SIEM, XDR, UEBA, SOAR, threat intelligence and threat hunting to correlate security signals across different environments. This can help security teams connect unusual identity behavior with endpoint, network and other security events.

Is Seceon OTM useful for MSSPs?

Yes. OTM is designed to support centralized and multi-tenant security operations, helping MSSPs monitor and investigate security activity across multiple customer environments.

MFA Was Never Supposed to Be the Whole Security Strategy

MFA is important.

Strong authentication is important.

Identity controls are important.

But none of them answer the most important question by themselves:

What is this identity doing right now?

That's the question modern security operations need to answer continuously.

Because the attacker doesn't care whether your dashboard says:

"MFA: Enabled."

They care whether they can operate as a trusted identity after authentication.

And that's why identity security is no longer just an IAM problem.

It's a SOC problem.