One system generated data. A connector moved that data somewhere else. Another platform processed it.

That model works well for traditional security integrations, such as sending alerts from an EDR platform to a SIEM or triggering a SOAR playbook from a security event.

AI agents are changing that model.

An AI agent does not always need a continuous stream of raw data. Sometimes, it simply needs to ask:

“What critical vulnerabilities are open right now?”

Or:

“Show me the incidents associated with this user.”

Or even:

“Isolate this endpoint after I receive approval.”

This changes what we expect from a connector.

Instead of acting only as a data pipe, the connector starts becoming an intelligent interface between the agent and the security platform.

This shift toward connector intelligence is one of the reasons Model Context Protocol, or MCP, is becoming increasingly relevant.

What Is MCP in Simple Terms?

Model Context Protocol provides a standardized way for AI applications and agents to interact with external tools, systems, and data.

Think about a traditional API integration.

A developer normally needs to understand:

• API endpoints

• Authentication

• Request formats

• Parameters

• Response schemas

• Error handling

The application then needs custom logic to work with that API.

MCP adds a standardized interface between the AI system and those capabilities.

Instead of expecting an AI agent to understand every underlying API, an MCP server can expose clear tools that the agent can discover and use.

For example, a security platform could expose tools such as:

get_incident

search_alerts

find_vulnerabilities

get_asset_risk

create_ticket

isolate_endpoint

The AI agent can select the appropriate tool according to what the user wants to accomplish.

Traditional Connector vs MCP Connector

The difference becomes easier to understand with an example.

Imagine a vulnerability management platform.

A traditional connector might continuously pull vulnerability findings and send them into a SIEM.

The basic flow looks like this:

Security Product → Connector → SIEM

The connector's main responsibility is moving and transforming data.

An MCP-enabled interface works differently.

An AI agent might ask the vulnerability platform:

“Which internet-facing assets have critical vulnerabilities?”

The MCP server provides the tools required to answer that specific request.

The flow becomes:

AI Agent → MCP Interface → Security Product → Relevant Response

The important difference is intent.

Traditional connectors generally move predefined data.

Agent interfaces allow an AI system to request the information or action it needs for a particular task.

The Connector Is Becoming an Interface

This represents a major change for security product companies.

Historically, building an integration meant answering questions such as:

• Which API should we call?

• How often should we poll it?

• Which fields should we collect?

• How should we normalize the data?

• Where should we send it?

Those questions still matter.

But agent-driven integrations introduce another layer.

Teams now also need to ask:

• What should an AI agent be allowed to discover?

• Which actions should it perform?

• How should tools be described?

• What context does the agent need?

• Which operations require approval?

• What permissions should each tool receive?

The connector is no longer simply translating data.

It is presenting the capabilities of a security product to an AI agent.

That means the way connectors are designed may become just as important as the APIs behind them.

Good APIs Do Not Automatically Create Good Agent Interfaces

A security vendor may already have a powerful REST API.

That is a strong foundation.

But exposing every API endpoint directly to an AI agent may not create a good experience.

Imagine a product with 200 API endpoints.

Technically, an MCP server could expose hundreds of tools corresponding to those endpoints.

But should it?

Probably not.

Agents work better when available capabilities are clear and meaningful.

Instead of exposing several low-level API operations, the MCP interface might provide one task-oriented tool:

Get high-risk assets

Behind that tool, the connector could:

1. Query assets

2. Retrieve vulnerability data

3. Apply risk filters

4. Normalize the results

5. Return useful context

The complexity stays behind the interface.

The agent receives information it can actually understand and use.

This Is Where Connector Intelligence Matters

Building an MCP interface should not simply mean converting REST endpoints into tools.

A better question is:

What does an AI agent actually need from this product?

That requires understanding both the technology and the security use case.

For a SIEM platform, useful agent capabilities might include:

• Search security events

• Retrieve incident details

• Find related alerts

• Investigate an entity

• Check detection status

For an EDR platform, they could include:

• Retrieve endpoint information

• Check endpoint risk

• Find recent detections

• Start an approved investigation

• Isolate a compromised device

For a threat intelligence platform:

• Look up an indicator

• Retrieve reputation

• Find related campaigns

• Enrich an IP, domain, or file hash

These are not simply API mappings.

They are security capabilities presented in a way an agent can understand.

Designing that layer requires many of the same engineering principles already used in professional security connector development, including authentication, API handling, normalization, reliability, permissions, and lifecycle maintenance.

Read Access and Action Are Very Different

Security becomes especially important when MCP tools can perform actions.

There is a major difference between:

“Show me information about this endpoint.”

and:

“Isolate this endpoint.”

The first retrieves information.

The second changes the environment.

An enterprise MCP implementation therefore needs to consider:

• Authentication

• Authorization

• Least-privilege access

• User identity

• Tool permissions

• Audit logging

• Approval workflows

• Credential management

This becomes even more important when an AI agent can take actions across multiple security platforms.

An agent should not receive broader permissions simply because it can access a tool.

Every capability needs appropriate controls around it.

MCP Does Not Replace Traditional Integrations

MCP should also not be viewed as a replacement for every existing connector.

A SIEM may still need continuous ingestion of millions of security events.

That is a good use case for a traditional connector.

At the same time, an AI assistant may need to query the same product for specific information.

That is a good use case for an MCP interface.

Both can exist together.

Traditional connector: moves telemetry continuously.

MCP interface: provides agents with contextual access to information and capabilities.

Future security products may therefore need multiple integration interfaces serving different purposes.

What Security Vendors Should Start Thinking About

Security vendors preparing for agent-driven ecosystems should look beyond one simple question:

“Do we support MCP?”

Instead, teams should ask:

• Which product capabilities should agents access?

• Which capabilities should remain read-only?

• Which actions require human approval?

• How should tools be named and described?

• What context should each tool return?

• How will agent activity be logged?

• How will authentication work?

• Who maintains the interface when APIs change?

These decisions determine whether an MCP implementation becomes genuinely useful or simply another technical checkbox.

From Connector Development to Agent Interface Engineering

Security integrations are entering a new phase.

Traditional connector engineering focuses heavily on APIs, ingestion, transformation, normalization, authentication, and workflow automation.

Those skills remain important.

But AI agents introduce another requirement:

Designing interfaces that machines can understand and safely operate.

That means modern integrations increasingly need to combine:

API engineering + security knowledge + connector architecture + agent interface design

For security vendors, this creates a significant opportunity.

A well-designed MCP interface can make product intelligence accessible through AI assistants, automated workflows, developer environments, and emerging agent ecosystems.

But simply exposing an existing API through MCP is not enough.

The real value comes from deciding what capabilities should be exposed, how they should be structured, and how AI agents can use them safely.

That is the next evolution of connector engineering.

ForshTec Systems works with security vendors, ISVs, MSSPs, and technology companies to engineer integrations and connectors across modern cybersecurity ecosystems, from traditional SIEM, SOAR, and XDR integrations to the emerging agent-driven interfaces shaping the next generation of security products.

But there is another question that becomes increasingly important after deployment:

How are those integrations packaged, supported, and maintained?

A connector may work today, but APIs change, authentication methods evolve, schemas drift, and SIEM platforms introduce new requirements.

That makes connector packaging and ownership an important part of long-term SIEM operations.

Microsoft Sentinel, Splunk, and Elastic all provide mature integration ecosystems, but they approach connectors differently.

A Connector Is More Than Data Ingestion

At its simplest, a connector moves data from a security product into a SIEM.

This can happen through REST APIs, Syslog, CEF, agents, forwarders, webhooks, or other mechanisms.

But getting data into the platform is only the beginning.

The SIEM must also understand that data.

This means parsing fields correctly, handling timestamps, identifying users and hosts, and mapping events into a common schema.

Each platform has its own normalization approach:

• Microsoft Sentinel: ASIM

• Splunk: CIM

• Elastic: ECS

Without normalization, analysts may have to write different queries for every vendor. With a common schema, detections and investigations can operate more consistently across multiple data sources.

Packaging Changes the Operational Experience

SIEM connectors are not always delivered as standalone ingestion components.

A connector package may also include:

• Parsers

• Dashboards

• Detection rules

• Hunting queries

• Visualizations

• Alert templates

• Automation content

• Documentation

This is where Sentinel, Splunk, and Elastic begin to differ.

Some ecosystems are more solution-oriented, while others give engineering teams more modular control.

Microsoft Sentinel: Solution-Oriented Packaging

Microsoft Sentinel uses a relatively solution-centric approach.

Through Sentinel solutions and Content Hub, organizations can deploy integrations together with supporting security content such as analytics rules, workbooks, parsers, hunting queries, and playbooks.

For new partner-developed connectors, Microsoft's Codeless Connector Framework (CCF) has become particularly important.

Microsoft's current solution guidelines require partners to use CCF for new data connectors instead of Azure Functions unless an exception is needed. CCF manages the connector's polling infrastructure, scaling, and health monitoring without requiring customers to deploy a separate service.

For organizations, this can reduce infrastructure management around API-based connectors.

For technology vendors, however, it means integrations need to follow Microsoft's publishing and connector-development requirements.

Sentinel is a strong fit when:

• You want cloud-native connector management

• You prefer packaged security content

• Your environment is heavily Microsoft-oriented

• You want to minimize customer-managed connector infrastructure

Splunk: Modular and Flexible

Splunk traditionally takes a more modular approach.

A Technology Add-on (TA) may handle data collection, source types, field extraction, and normalization, while another Splunk application provides dashboards, searches, reports, or security content.

This gives engineering teams significant flexibility.

For example, an organization can use a TA for ingestion while developing its own dashboards and detections.

Normalization commonly revolves around Splunk's Common Information Model (CIM). Mapping fields correctly to CIM can make the same detection logic work across multiple technologies.

Ownership is another important consideration.

Splunkbase currently differentiates applications into Splunk-built, Cisco-built, partner-built, and community tiers. Splunk-built applications are developed and maintained by Splunk teams, while partner and community applications have different support and ownership models.

So finding a connector on Splunkbase should not automatically end the evaluation.

Teams should also ask:

• Who maintains it?

• Is it CIM-compatible?

• When was it last updated?

• Which Splunk versions are supported?

• What happens when the source API changes?

Splunk is a strong fit when:

• You need extensive customization

• Your environment contains many different technologies

• Your team wants granular control over ingestion

• You have engineering resources for managing integrations

Elastic: Integration Packages Built Around ECS

Elastic provides integrations as packages that can contain both data collection configuration and supporting assets.

Elastic Agent integrations can include ingestion and transformation rules, configuration options, dashboards, visualizations, documentation, and, in some cases, alert templates. Many are based on the Elastic Common Schema (ECS).

Elastic Agent and Fleet provide centralized management for deploying and updating integrations and agent policies.

ECS plays an important role in the model.

Instead of every integration creating completely unrelated field structures, ECS provides common field definitions for concepts such as users, hosts, IP addresses, processes, networks, and events.

That can make cross-source searching and detection easier.

Elastic is a strong fit when:

• You value schema-driven data architecture

• You combine security and observability data

• You need flexible ingest pipelines

• You want centralized agent and integration management

Certification Is Really About Ownership

When evaluating integrations, the word certified should not be treated simply as a marketplace badge.

The operational question is:

Who is responsible when the integration breaks?

An integration may generally be:

Platform-maintained: Developed and supported by the SIEM vendor.

Partner-maintained: Developed by a technology vendor or approved partner.

Community-maintained: Developed by external contributors with potentially different support expectations.

All three models can provide useful integrations.

The difference becomes important when an upstream vendor changes an API, introduces OAuth changes, modifies pagination, or changes the structure of returned events.

Without clear maintenance ownership, a connector can quickly become technical debt.

What Security Teams Should Evaluate

Instead of comparing SIEMs based only on connector counts, evaluate each important integration across four areas.

1. Data Collection

How does the connector retrieve data?

API, agent, Syslog, webhook, or additional middleware?

2. Normalization

Does it properly map data into ASIM, CIM, ECS, or another common structure?

3. Packaged Content

Does the integration include detections, dashboards, parsers, alerts, or other immediately usable content?

4. Maintenance

Who updates the connector when the source product or SIEM platform changes?

This final question is often the most important over the long term.

There Is No Universal Winner

Sentinel, Splunk, and Elastic each provide capable integration ecosystems.

The difference is largely in how those ecosystems are structured.

Sentinel leans toward cloud-managed, solution-oriented integration.

Splunk provides extensive modularity and customization.

Elastic combines package-based integrations with ECS and centralized Fleet management.

The better question is therefore not:

"Which SIEM has more connectors?"

It is:

"Which connector model fits the way our security and engineering teams operate?"

For vendors building integrations, the same principle applies.

Getting logs into a SIEM is only the first step. A production-ready connector also needs reliable parsing, schema mapping, scalable ingestion, documentation, packaging, and a clear maintenance path.

ForshTec Systems helps security technology vendors build and maintain integrations across Microsoft Sentinel, Splunk, Elastic, SIEM, SOAR, XDR, and other cybersecurity ecosystems, helping turn raw product data into integrations that security teams can actually use and maintain.

It made sense when enterprise environments were smaller. Today, organizations generate enormous volumes of telemetry across endpoints, cloud platforms, identity systems, SaaS applications, networks, and security tools.

The problem is that more data does not automatically mean better security.

In many environments, a significant portion of ingested telemetry provides limited value for real-time detection but still contributes to SIEM ingestion, processing, indexing, and storage costs.

For CISOs and security leaders, the challenge is no longer simply collecting more data. It is deciding which data deserves expensive SIEM capacity and which data can be filtered, routed, or stored elsewhere.

The Hidden Cost of "Ingest Everything"

Traditional SIEM architectures often follow this model:

Collect → Transform → Index → Store → Analyze

Every additional event can increase infrastructure consumption.

Consider telemetry from an endpoint security platform. An organization may generate millions of events every day, including detections, authentication activity, system events, network connections, informational messages, and repetitive records.

Sending all of this directly to the SIEM can create unnecessary costs.

The problem becomes even more significant when multiple security platforms generate overlapping data.

Instead of asking, "What logs can we stop collecting?", security leaders should ask:

"What data actually needs to be in the SIEM?"

That change in thinking is critical.

Filter Data Before It Reaches the SIEM

One of the most effective ways to reduce SIEM costs is to make decisions before ingestion.

An intelligent integration layer can evaluate telemetry at the source and apply routing policies based on factors such as:

• Event severity

• Security relevance

• Source

• Frequency

• Duplication

• Retention requirements

• Detection use cases

High-value events can be sent directly to the SIEM, while lower-value or high-volume telemetry can be filtered, aggregated, or routed to lower-cost storage.

For example:

Critical security alerts → SIEM

Authentication anomalies → SIEM

Routine endpoint events → Selective routing

Historical telemetry → Object storage

Duplicate or low-value events → Suppression

This approach does not mean losing visibility. It means putting data in the right place for its purpose.

Don't Turn the SIEM Into a Data Lake

Another common architectural problem is using the SIEM as the organization's universal security data repository.

SIEM platforms are valuable for detection, correlation, investigation, and security analytics. But storing every raw event in expensive hot storage may not be the most efficient architecture.

A modern Security Data Fabric architecture separates data storage from analytics. Instead of forcing every event into one centralized platform, organizations can keep data across cloud object storage, data lakes, endpoint platforms, and other native systems while maintaining access through federated queries and intelligent routing.

This approach can reduce the need to maintain multiple expensive copies of the same security data while still giving analysts access to the information they need.

For a deeper look at how Integration Engineering supports this architecture, see ForshTec's guide on Security Data Fabric and Integration Engineering.

The result is a more flexible architecture:

Data stays where it makes economic and operational sense.

The SIEM receives the data required for security operations.

Integration Engineering Matters

Reducing SIEM costs is not just a matter of installing a filtering tool.

Modern security environments depend on dozens or hundreds of integrations, each with different APIs, schemas, rate limits, and event formats.

A resilient integration layer needs to handle:

• API rate limiting

• Schema changes

• Duplicate events

• Retry logic

• Data enrichment

• High event volumes

• Pipeline failures

Standardized security schemas such as the Open Cybersecurity Schema Framework (OCSF) can also help organizations normalize data across different vendors and reduce long-term integration complexity.

This becomes particularly important when organizations want to avoid becoming overly dependent on a single security platform.

A Better Way to Think About SIEM Costs

Security leaders should measure SIEM optimization using more than ingestion volume.

Important metrics include:

• SIEM ingestion volume

• Cost per GB

• Percentage of telemetry filtered before ingestion

• Duplicate event reduction

• Detection coverage

• Data pipeline failures

• Investigation performance

The objective should be:

Lower SIEM costs without sacrificing detection capability.

Simply sending less data to the SIEM is not a successful strategy if it creates security blind spots.

The Strategic Shift

The future of SIEM architecture is unlikely to be based on collecting every possible event.

Instead, security teams will increasingly focus on intelligent data placement.

High-value telemetry should receive the expensive processing and analytics it deserves. Other data can be filtered, aggregated, retained in lower-cost storage, or accessed through a federated architecture when needed.

For CISOs, this creates an important opportunity.

SIEM optimization is not merely a licensing exercise. It is an architecture problem.

By combining intelligent ingestion, data routing, standardized schemas, and resilient Integration Engineering, organizations can reduce unnecessary SIEM consumption while maintaining the security visibility their analysts depend on.

The key question is no longer:

"How much security data are we collecting?"

It is:

"How much of that data actually needs to be in the SIEM?"

That is where meaningful SIEM cost optimization begins.

How ForshTec Helps

ForshTec helps organizations engineer integrations and security data workflows across complex security ecosystems. Its capabilities include security connector development, data normalization, intelligent routing, and resilient integrations designed for enterprise-scale environments.

For organizations looking to reduce unnecessary SIEM ingestion while maintaining security visibility, a smarter integration architecture can provide a practical path toward a more efficient Security Data Fabric.