Every investigation starts the same way — re-explaining your environment, your log sources, your detection standards, before you can even get to the actual analysis. Multiply that setup tax across every new chat you open for the same investigation, and you’re spending more time re-briefing the AI than hunting threats.

Projects solves this. Available within Agentic Threat Research — the AI-assisted workspace in Prime Architect for detection engineering and threat research — Projects let you group multiple chats under a single shared context, so you only have to set the stage once. Define your data schema, log sources, detection structure, and expected output up front, and every chat in that project automatically inherits it. No more re-pasting the same background into every new session — the AI already knows how your environment works before you type your first question.

Think of a project as a workspace built around a specific investigation focus — a threat campaign, your or a customer environment, a detection engineering initiative, an ongoing incident. Everything the AI needs to reason correctly about that focus lives in one place, and every chat inside it starts from that same, fully-briefed baseline. Projects sit right in the left panel of Agentic Threat Research alongside your regular chats, and everything you already rely on there — custom prompts as well as the built-in Agentic AI tools — works the same way inside a project, just with your context already applied.

Contact Sales

Why It Matters

• Consistency across your own investigations. Every chat you open inside a project starts from the same baseline context, so your results stay comparable and repeatable across sessions, instead of depending on what you happened to type into the prompt that day.
• Faster investigations. Skip the setup tax entirely. Open a new chat and get straight to the analysis — the context is already loaded, so the AI can go from question to answer instead of question to clarifying-question.
• Institutional knowledge, built in. Upload your internal playbooks, incident reports, environment documentation, and other security-related reference materials so the AI reasons with your organization’s actual standards and history, not generic assumptions about how a SOC should work.
• Precision by design. Set rules once — clarify assumptions before acting, require precise technical language, suggest tuning ideas for noisy detections — and every chat in the project follows them automatically, without you having to repeat yourself.
• A dedicated workspace per investigation. Keep separate projects for separate focuses — a threat campaign, your or a customer environment, a detection engineering initiative — so the context loaded into each one is always exactly what that investigation needs, without unrelated work affecting it.

A Quick Example

Say you’re running a project focused on lateral movement detection. You attach your data schema so the AI understands your field naming conventions, list out your log sources (EDR, VPN, identity provider, and firewall logs) so it knows what evidence is actually available, and upload your detection structure and expected output template so every finding comes back in the same format you use for triage. You also drop in a couple of relevant internal playbooks and prior incident reports covering similar activity. From that point forward, every new chat you open in that project can answer questions like “does this authentication pattern match known lateral movement TTPs in our environment?” grounded in your actual data model and your own case history — not a generic response — without you having to re-explain any of it.

Getting Started

1. Create a project. In Prime Architect, go to the Agentic Threat Research mode, select Projects in the left panel, and then select Create Project. Give it a name.

2. Define the shared context. Pick either or both:

• Instructions: Click the pencil icon in the Instructions section and write a prompt describing how the AI should behave in this project — for example, your data schema, log source details, detection structure and expected output format, or key rules like clarifying assumptions and using precise technical language. Select Save. You can revisit and edit this anytime via the same pencil icon.

• Resources: Click the plus (+) icon in the Resources section, select Upload Files, and attach your reference material — playbooks, incident reports, environment docs, or other security references. You can upload up to 5 files, each up to 15 MB and 500k tokens. Supported formats: PDF, TXT, CSV, JSON, PNG, JPG/JPEG (PDFs up to 1,000 pages). 

Everything you add here applies automatically to every chat in the project.

3. Start working. Open the project and start a new chat — it inherits the context immediately, no extra steps required. All chats you create within the project are grouped together and available under the chat panel, so your investigation history stays organized in one view instead of scattered across a general chat list.

4. Keep it organized. As a project grows, you can rename or delete individual chats at any time — just click the three-dot menu next to a chat and select the option you need. This makes it easy to keep active investigations clearly labeled and archive ones that are closed out, without losing the shared context that the rest of the project still relies on.

Set the context once. Investigate faster, every time after.

The post Projects in Agentic Threat Research: Context That Sticks appeared first on SOC Prime.

Security teams are drowning in threat reports. Every week brings a new advisory, a new vendor write-up, a new blog post describing the latest campaign — and every one of them demands hours of manual reading, cross-referencing, and translation into something your SOC can actually act on. Deep Threat Research changes that equation entirely.

Deep Threat Research is an agentic AI tool available within Agentic Threat Research mode in Prime Architect. It takes any threat report and instantly transforms it into structured, decision-ready threat intelligence — complete with a clear threat summary, precise MITRE ATT&CK mappings, and a full set of interactive visualizations that show exactly how an adversary operates. What used to take an analyst hours of manual triage now happens in minutes, freeing your team to focus on what matters most: threat detection and threat mitigation.

What Deep Threat Research Solves

Every threat report contains value, but that value is locked inside dense paragraphs of prose. Deep Threat Research unlocks it automatically. It reads the report the way your most experienced analyst would — extracting the adversary’s tactics, techniques, and procedures, identifying relevant indicators, and mapping everything against the MITRE ATT&CK framework — then hands you a complete intelligence package: investigation guidance, mitigation recommendations, response actions, associated threat actors, and even AI-generated detection rules ready for deployment.

Instead of starting from a blank page, your team starts from a fully-formed picture of the threat: who’s behind it, how it moves, what it touches, and how to stop it.

Contact Sales

What You Get

Once an analysis completes, results are generated and appear one after another. Some sections are ready to read right away, while others display as tiles you simply click to open and explore in more detail — just scroll down to move through the full analysis. Overall, Deep Threat Research organizes its findings into clear, digestible sections:

• Summary – the essential facts of the threat, distilled from the report
• Investigation – guided next steps for analysts
• Mitigation – best-practice actions to reduce impact

• Response – recommended steps once malicious activity is confirmed
• Actors – the threat actors tied to the activity
• MITRE ATT&CK Techniques – the specific behaviors and techniques adversaries used, mapped directly to the framework
• Detections – existing SOC Prime Platform detections plus new AI-generated rules, ready to copy, translate into your SIEM’s language, validate, or save straight to your repository

• Simulation – ready-made simulations of the malicious activity for testing your defenses

On top of that, four interactive visualizations bring the intelligence to life:

• Attack Flow – the adversary’s full attack sequence based on MITRE ATT&CK, viewable as a diagram or matrix and exportable as MMD

• Cyber Kill Chain – maps the threat across all seven Lockheed Martin stages, from Reconnaissance to Actions on Objectives, so you can spot detection opportunities at every phase

• Pyramid of Pain – breaks down every extracted indicator into six tiers, from Hash Values and IP Addresses up through Domain Names, Network/Host Artifacts, Tools, and TTPs, so you can see at a glance how resilient your detection coverage really is

• Diamond Model – connects the four pillars of any intrusion — Adversary, Capability, Victim, and Infrastructure — and shows how they link together

Getting Started

Getting from a raw report to full threat intelligence takes just a few steps:

1. Open Prime Architect and select the Agentic Threat Research mode.
2. Click Code Editor in the upper-right corner and paste in the text of your threat report. 
3. Select Analyze.

4. Choose Deep Threat Research from the list of analysis types.
5. Click the Enter icon to run the analysis.

That’s it. Within moments, your results appear — summary, investigation and mitigation guidance, ATT&CK mappings, detections, simulation, and all four visualizations, ready to explore, click into, and act on.

The Value You Gain

Deep Threat Research doesn’t just summarize a report — it operationalizes it. By pairing AI-driven analysis with the structure of MITRE ATT&CK and the SOC Prime Platform’s detection library, it turns every threat report your team encounters into a springboard for faster investigation, sharper mitigation, and stronger detection coverage. Less time reading. More time defending.

The post From Raw Threat Reports to Actionable Defense: AI-Powered Deep Threat Research appeared first on SOC Prime.

Get more relevant, more accurate answers from Prime Architect by giving your AI agent the context it needs — no more copy-pasting excerpts or describing an incident from memory. In Prime Architect, every chat is a space to work through detection engineering and threat research tasks with AI, whether you’re writing a custom prompt or running one of the built-in Agentic AI tools. Now you can bring your own reference materials into that conversation directly: upload playbooks, incident reports, environment documentation, screenshots, and other reference materials into your chat, and let the AI work from the real source.

Why It Matters

Better context means better output. When an AI tool works from your actual playbook, incident report, or environment documentation, its analysis is grounded in your real data rather than a secondhand summary. You can write your message and attach files together, and the AI agent treats the attached files as context for that message — whether you’re running a custom prompt or one of the purpose-built AI tools in Prime Architect. Instead of retyping the key details of an incident or manually condensing a lengthy report before you can even start your analysis, you simply hand the AI the source document and move straight to the insight.

Flexibility for every workflow. Not every analyst wants to work the same way. That’s why there are three different ways to attach a file — a manual upload button, drag and drop, and clipboard paste — so you can choose whichever fits your current task and habits. Dragging a report straight from your desktop, pasting a screenshot you just captured, or browsing for a file through the upload menu all lead to the same result: your AI agent working with richer, more accurate context.

Built for how security teams actually work. Detection engineers and threat researchers rarely start from a blank page — they start from an existing playbook, a prior incident write-up, environment documentation, or a screenshot of a suspicious event. This feature meets that reality head-on, letting you carry that material directly into your conversation instead of translating it into a prompt by hand.

How to Add a File

There are three simple ways to get a file into your chat message in Prime Architect.

Option 1: Upload manually

1. Click the + icon in the chat input area and select Add Files and Images.

2. Select a file from your device.
3. The file appears in the input area and begins uploading.

Option 2: Drag and drop

1. Locate the file on your computer — for example, in Finder or File Explorer.
2. Drag the file into the chat panel in Prime Architect. You can drop it anywhere in the chat window, including the message history area or the input field.

3. The file appears in the input area and begins uploading.

Option 3: Paste from clipboard

1. Copy an image, screenshot, or file — take a screenshot, copy an image from another app, or select a file in your OS file explorer and press Cmd+C / Ctrl+C.
2. Click into the chat input field to make it active.
3. Paste using Cmd+V / Ctrl+V.
4. The file appears in the input area and begins uploading.

A few things to know: You can attach up to 3 files per message, with a maximum size of 5 MB per file. Supported formats include PDF, TXT, CSV, JSON, PNG, and JPG/JPEG — covering the most common document, data, and image formats used in security workflows. Depending on the size of your files, it may take a moment to process them before they’re ready to be used as context, especially for documents with many images or visual elements.

Make It Part of Your Workflow

Whether it’s a playbook pulled from your files, a screenshot of a suspicious alert, or an incident report you’ve had open all day, getting it into Prime Architect takes just a click, a drag, or a paste. Stop summarizing your evidence — start uploading it, and let your AI agent do the deeper work.

The post Bring Your Files Into the Conversation appeared first on SOC Prime.

Security teams don’t have a data shortage — they have a data flood. A single incident can throw off hundreds of thousands, sometimes millions, of log events, and making sense of them under time pressure is exactly the kind of work that breaks people and tooling alike. SOC Prime built LogTotal to take that pressure off, without asking teams to hand over the raw evidence to do it.

The problem: every “send us the logs” request is a privacy decision

Endpoint events, identity logs, cloud audit trails, syslog, Windows Event Logs, application JSON — this is the raw material of detection, hunting, and response. When something breaks, the first ask is almost always the same: send the logs.

That request used to stay inside a closed environment. Now it rarely does. Logs get attached to vendor tickets, dropped into collaboration tools, uploaded to SaaS analyzers, pasted into AI chat windows, copied into shared workspaces. Each hop widens the circle of people, systems, and jurisdictions that can see the original values.

The risk is easy to miss because logs look operational rather than confidential. In practice, one authentication event can carry a username, a source IP, a workstation name, a session cookie, and a bearer token in an Authorization header. A payment-adjacent log can contain a PAN-shaped number. A Windows file path can leak a home-directory username. A field labeled UserName or x-api-key often holds the value in plain text, even when the rest of the line looks harmless. Under GDPR and similar regimes, most of that counts as personal data — and a leaked token or key isn’t a historical record, it’s a live access path.

Refuse to share the logs and you slow down the investigation. Share them raw and you risk violating policy, contracts, or regulation. Manual redaction doesn’t scale, isn’t consistent across analysts, and often strips out the exact identifiers an investigation needs to correlate events.

This isn’t hypothetical. SOC Prime built LogTotal partly in response to HuggingFace’s July 2026 security incident, in which the team’s attempt to send roughly 17,000 events to frontier AI models was blocked by guardrails — forcing a fallback to a local GLM model with GPU and VRAM requirements most organizations simply don’t have. LogTotal is built to handle that same job — at up to 1,700,000 events — without anyone needing frontier-model access or a private GPU cluster.

Why simple redaction doesn’t hold up

Most redaction approaches fail in one of two directions.

Static masking — turning every IP into the same placeholder, every user into USER — destroys the thing that makes investigation possible: correlation. If ten failed logons all collapse to the identical token, you can no longer tell a single compromised account from a credential-spray attack hitting ten different people.

Plain find-and-replace fails the other way. It misses values in unusual encodings or nested JSON, and it over-redacts things that only look sensitive — version numbers shaped like IPs, UUIDs used as message IDs, well-known non-sensitive hostnames. Unkeyed hashing doesn’t solve it either: a raw hash of a common value can be reversed by dictionary-guessing, and identical unsalted hashes across different organizations can accidentally link unrelated incidents together.

LogTotal was built to avoid both failure modes.

How it actually works

1. Sanitization happens locally, in your browser, before anything is sent anywhere. You can download the sanitized log at any point — you always have a clean copy of exactly what was analyzed.
2. Your files never leave your control unsanitized, and nothing is stored. LogTotal doesn’t retain your logs after analysis, and SOC Prime has no need to — the platform isn’t training on your data.
3. Upload in your native format. LogTotal auto-detects EVTX, CEF, JSON/NDJSON, and syslog — no manual conversion.
4. Your sanitized events are correlated at scale. LogTotal runs them against roughly 1,000,000 detection rules and a dataset of 13,000 labels, then applies Higher Order Sigma Rules and agentic AI correlation to connect related events into a coherent picture — up to 1.7 million events, in under a minute.
5. You get an investigation, not a dump. Results are structured as findings on the LogTotal site, not a wall of raw matches.

However, log sanitization is only the first stage of LogTotal once it’s out of the preview. Coming soon is something even more powerful: sanitized logs checked against tens of thousands of behaviour rules, with matches correlated around Higher Order Sigma rules for active threats.

Where teams can use this

• Incident response with external retainers. Sanitize a log packet with a key you retain. The retainer can still cluster hosts, users, and addresses — and you can map tokens back internally if a specific identity needs to be named in a privileged briefing.
• Vendor support and TAC cases. “The log file that shows the error” is famous for containing environment details unrelated to the ticket. Sanitizing before you attach it cuts accidental disclosure without turning the file into noise.
• Detection engineering and rule testing. Sample logs are how detections get written and validated — and how production identities leak into git history, CI artifacts, and demo environments. Sanitizing fixtures once, with a key shared inside the team, keeps examples correlatable while stripping secrets.
• Pre-SIEM or pre-lake sharing. Not every pipeline needs a commercial processor to redact a batch file. For exports, one-off hunts, and cross-team handoffs, a local sanitizer is the control people will actually use.
• GDPR and privacy reviews. Pseudonymization isn’t a blanket exemption, but replacing identifiers with keyed tokens before a file leaves the organization is a concrete technical measure — one you can point to and describe: what was removed, what was retained, how tokens were generated, who holds the key.
• AI-assisted analysis without exposing raw telemetry. Whether the destination is LogTotal, an internal model, or a restricted vendor environment, the question is the same: does the model need the actual password, or does it need to know a secret was present and the same user touched three hosts?

Try LogTotal

The SOC Prime Platform exists to help security teams anticipate, detect, validate, and respond to threats faster. That mission has never required collecting customer secrets. LogTotal extends it to private event analysis at community scale. 

Security teams should not have to choose between a thorough investigation and a defensible data-handling story. Sanitize first. Correlate on tokens. Keep the key. Analyze the evidence that remains.

Explore LogTotal at https://logtotal.com. 

Join the SOC Prime Platform to improve visibility into threats most relevant to your business. To help you get started and drive immediate value, book a meeting now with SOC Prime experts.

The post LogTotal Public Preview: Free, Private Security Log Analysis in Under a Minute appeared first on SOC Prime.

Every day, your SOC drowns in isolated alerts — a suspicious login here, an odd process spawn there, a strange outbound connection somewhere else. Individually, each one looks like noise. Together, they might be the early signature of a coordinated adversary campaign already unfolding inside your environment. The problem isn’t a lack of data — it’s a lack of connection.

Attack Chains changes that equation. Instead of asking your analysts to manually stitch together dozens of low-confidence signals, Attack Chains does it for them automatically — correlating historical scan results across your SIEM, EDR/XDR, and Data Lake (Prime Hunt), or real-time event streams as they’re generated, before that data even reaches your SIEM (Prime Detect). Either way, it doesn’t correlate against a static, generic rule set — it correlates against Active Threats: newly identified, real-world threats as they’re published to detect potential Attack Chains before they become confirmed incidents. That means your detection logic is only ever as current as the threat landscape itself. 

Where to find it: Attack Chains lives as its own tab inside both Prime Hunt and Prime Detect. If you’re working with historical data, go to Prime Hunt → Attack Chains. If you want real-time correlation before data hits your SIEM, go to Prime Detect → Attack Chains.

Always Watching for What’s New

Once you’re in Attack Chains, the Monitored Threats tab shows every Active Threat your environment is being correlated against. Attack Chains stays current without any effort on your part. The moment a new threat is identified in the wild, it’s already part of what your environment is being checked against — no waiting for a rule update, no manual research cycle. You still decide what matters most to your organization, focusing correlation on the threats most relevant to your industry or risk profile.

Enable or disable individual threats, or apply bulk actions to manage several at once — right from the Monitored Threats list — so your correlation scope always reflects what actually matters to your organization.

And if a threat’s detection coverage isn’t actually working — whether it hasn’t been scanned yet or a rule isn’t properly connected — you’ll see it right away, instead of finding out after the fact. Here’s what that looks like:

A green checkmark means a threat’s detection coverage is fully in place. An issue label flags a gap — click it to see exactly what’s missing.

The Picture Attack Chains Give You

Once a chain forms, it’s not just a correlated pile of events — it’s an investigation-ready story, at both a program-wide and case-by-case level.

At a glance, your Attack Chains Overview gives you a real-time pulse on your overall exposure: how many chains have been built, how many active threats are currently being watched, how many hosts are involved, and how much of your detection coverage is actually firing. It’s the kind of summary that turns “are we being targeted?” into a number you can check in seconds.

Click into any individual chain from the Attack Chains tab, and your team gets:

• An AI-generated summary of the detected activity, so analysts get immediate context 
• A visual timeline of adversary techniques, showing exactly how the attack progressed step by step — with techniques already confirmed by detection rules, plus activity caught through fuzzy pattern matching (Prime Hunt) 
• Threat actor and technique attribution, mapped to industry-standard frameworks, so scoping and context-building start immediately instead of from scratch
• A clear match, showing how closely the activity lines up with a known attack pattern — so your team knows exactly how seriously to treat it
• Full asset and environment context — which host, which part of your infrastructure, and which of your data sources picked it up — so there’s no guessing where to look next
• A direct path back into your existing tools, letting analysts pivot straight into the underlying events without losing time or context
• A built-in investigation trail, tracking the status of the Attack Chain from first detected to fully resolved, and nothing falls through the cracks

Low-confidence noise is filtered out by the AI, so what reaches your team by default is what actually deserves their attention — with the option to dig into everything else whenever they choose to.

Bringing It All Together: Configuring Attack Chain Correlation

With the threat intelligence and the picture it produces in mind, here’s how you tell Attack Chains exactly how to correlate it:

1. Set the chain-forming threshold — the minimum percentage of a threat’s technique sequence that must match before Attack Chains are formed
2. Define the correlation window — how close together in time events must occur to be correlated
3. Define the lookback window — how far back the engine searches when hunting for related events (Prime Hunt only)
4. Choose your data sources — include or exclude the SIEM, EDR/XDR, and Data Lake sources (Prime Hunt) or topics (Prime Detect) feeding correlation, and optionally auto-enroll new ones as they’re added
5. Review data-sharing settings — hostname data needs to be transmitted and stored for correlation to work, which may require explicit consent (Prime Hunt)
6. Save and click Run — Attack Chain monitoring is live from that point on, continuously checking your environment against the newest threats as they emerge
   

CHECK AVAILABLE DETECTIONS

The post Attack Chains: See the Full Story Behind Every Threat appeared first on SOC Prime.

Running a threat intelligence program today means operating across more tools, more workflows, and more organizational complexity than most platforms were originally designed to handle. The intelligence is there. The question is whether the platform is keeping up with how your team actually needs to use it.

SOC and CTI teams have spent the last two years integrating AI tools into real investigative work, and the results have been meaningful. Analysts move faster through reports, surface connections more quickly, and spend less time on the mechanical parts of initial triage. But the threat intelligence platform sitting at the center of that work has remained largely separate from it, a destination analysts navigate to rather than an environment agents can operate inside. The gap between understanding a threat and recording it in a TIP is still, in most teams, a human problem. The EclecticIQ MCP Server is built to close it.

For years, defense organizations have adapted commercially developed cyber threat intelligence platforms to fit military intelligence processes. This arrangement was often accepted as a practical necessity. Commercial platforms delivered valuable capabilities, while intelligence teams developed processes to align outputs with doctrinal requirements, reporting structures, and command expectations.

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

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

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

Every Alert. Investigated. Now.

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

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

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

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

The Native Platform Advantage

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

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

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

Autonomy With Accountability

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

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

What Customers Are Doing With It

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

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

Singularity Credits

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

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

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

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

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

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

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

Third-Party Trademark Disclaimer:

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

Cybersecurity teams face a familiar problem. Too much data, not enough insight.

Cyber is no longer a supporting capability. It now shapes how defense organizations plan, assess, and act.

Counting intelligence outputs is simple: volume, velocity, coverage. The real question is this: does your intelligence improve decisions under pressure, with confidence you can defend?

You cannot confidently choose threat intelligence integrations and services when you have to commit before you can validate operational impact. That is how you end up with tools that look good on paper, but do not always reduce triage time, improve detection quality, or support response the way you hoped.

Disinformation is no longer just a nuisance.  It’s a weapon leveraged by both state and non-state actors.  For information operations analysts tracking influence campaigns across elections, national security threats, and coordinated disinformation efforts, the challenge is growing. Whether you work in a government agency, intelligence service, election security organization, or corporate trust and safety team, the tools at your disposal were not built for this fight.  

Threat intelligence teams deal with a constant influx of data from multiple providers, often describing the same threat actor, malware, or vulnerability in slightly different ways. Instead of speeding up analysis, this duplication adds friction and slows decisions. 

A telemetry pipeline has become a core layer in modern security operations because teams no longer send data from applications, infrastructure, and cloud services straight into a single backend and hope for the best. In 2026, most environments are distributed across cloud, hybrid, and on-prem systems, which means more services, more data sources, more formats, and more operational complexity for teams that already struggle to keep visibility, control costs, and respond quickly. 

Splunk’s State of Security 2025 found that 46% of security professionals spend more time maintaining tools than defending the organization. Cisco’s research adds that 59% deal with too many alerts, 55% face too many false positives, and 57% lose valuable investigation time because of gaps in data management. When too much raw telemetry flows into the stack without filtering, enrichment, or routing, the result is higher bills, slower investigations, and more noise for already stretched teams.

That is why telemetry pipelines are gaining momentum. They give organizations a control layer to normalize, enrich, route, and govern telemetry before it reaches SIEM, observability, or storage platforms. What began primarily as a way to control volume and cost is quickly becoming a must for modern security operations. Gartner suggests that by 2027, 40% of all log data will be processed through telemetry pipeline products, up from less than 20% in 2024.

As that model matures, the next logical step is not just to manage telemetry better, but to make it useful earlier. If teams are already adding a pipeline to reduce noise, control spend, and improve routing, it makes sense to move part of the detection process closer to the stream itself rather than waiting for every event to land in downstream tools first. Solutions like SOC Prime’s DetectFlow act as an additional detection layer running directly on the stream. Instead of using the pipeline only for transport and optimization, DetectFlow applies tens of thousands of Sigma rules on live Kafka streams with Apache Flink, tags and enriches events in flight, and helps teams act on higher-value signals much earlier in the flow.

What Is Telemetry?

Before talking about telemetry pipelines, it is important to define telemetry itself.

Telemetry is the evidence systems leave behind while they run. It shows how applications, infrastructure, and services behave in real time, including performance, failures, usage, and health. 

For enterprises, that evidence is valuable because it shows what users are actually experiencing, where bottlenecks form, when failures begin, and where suspicious activity starts to flicker. For security teams, telemetry is even more important because it becomes the raw material for detection, investigation, hunting, and response.

Put differently, telemetry is the trail of digital footprints your environment leaves behind. Useful on its own, but much more powerful when it is organized before the tracks disappear into the mud.

What Are the Main Types of Telemetry Data?

Most teams work with four main telemetry categories grouped under the MELT model: Metrics, Events, Logs, and Traces.

Metrics

Metrics are numerical measurements collected over time, such as CPU usage, memory consumption, latency, throughput, request volume, and error rate. They help teams track system health, identify trends, and spot anomalies before they become visible outages.

Events

Events capture notable actions or state changes inside a system. They usually mark something important that happened, such as a user login, a deployment, a configuration update, a purchase, or a failover. Events are especially useful because they often connect technical activity to business activity.

Logs

Logs are timestamped records of discrete activity inside an application, system, or service. They provide detailed evidence about what happened, when it happened, and often who or what triggered it. Logs are essential for debugging, troubleshooting, auditing, and security investigations.

Traces

Traces show the end-to-end path of a request as it moves across different services and components. They help teams understand how systems interact, how long each step takes, and where delays or failures occur. Traces are especially valuable in distributed systems and microservices environments.

Some platforms also break telemetry into more specific categories, such as requests, dependencies, exceptions, and availability signals. These help teams understand incoming operations, external service calls, failures, and uptime. 

Telemetry Data Pros and Cons

Telemetry data can be one of the most valuable assets in modern operations, but only when it is managed with purpose. Done well, it gives teams a real-time view of how systems behave, how users interact with services, and where risks or inefficiencies begin to form. Done poorly, it becomes just another stream of noisy, expensive data.

Telemetry Data Benefits

The biggest advantage of telemetry is visibility. By collecting and analyzing metrics, logs, traces, and events, teams can see what is happening across applications, infrastructure, and services in real time.

Key benefits include:

• Real-time visibility into system health, performance, and user activity
• Proactive issue detection by spotting anomalies before they turn into outages or incidents
• Improved operational efficiency through automated monitoring and faster workflows
• Faster troubleshooting by giving teams the context needed to identify root causes quickly
• Better decision-making through data-backed insights for product, operations, and security teams
  
  

To get the full value, telemetry needs to be consolidated and handled consistently. A unified telemetry layer helps reduce mess across tools, improves scalability, and makes data easier to analyze and act on.

Telemetry Data Challenges

Telemetry also comes with real challenges, especially as data volumes grow. The most common ones include:

• Security and privacy risks when sensitive data is collected or stored without strong controls
• Legacy system integration across different formats, sources, and older technologies
• Rising storage and ingestion costs when too much low-value data is kept in expensive platforms
• Tool fragmentation makes correlation and investigation harder
• Interoperability issues when systems do not follow consistent standards or schemas
  
  

This is exactly why telemetry strategy matters. The goal is not to collect more data for the sake of it, but to collect the right data, shape it early, and route it where it creates the most value. In cybersecurity, that difference is critical. The right telemetry can speed up detection and response, while unmanaged telemetry can bury important signals under cost and noise.

How to Analyze Telemetry Data 

The best way to analyze telemetry data is to stop treating analysis as the last step. In practice, good analysis starts much earlier, with clear goals, structured collection, smart routing, and storage policies that keep useful data accessible without flooding downstream tools. 

Define Goals

Start with the question behind the data. Are you trying to improve performance, reduce MTTR, monitor customer experience, detect security threats, or control SIEM costs? Once that is clear, decide which signals matter most and which KPIs will show progress. For a product team, that may be latency and error rate. For a SOC, it may be detection coverage, false positives, and investigation speed. This is also the stage to set privacy and compliance boundaries so teams know what data should be collected, masked, or excluded from the start. 

Configure Collection

Once goals are clear, configure the tools that will collect the right telemetry from the right places. That usually means deciding which applications, hosts, cloud services, APIs, endpoints, and identity systems should send logs, metrics, traces, and events. It also means setting practical rules for sampling, field selection, filtering, and schema consistency.

Shape and Route the Data 

Before data reaches SIEM, observability, or storage platforms, it should be shaped to fit the goal. That can mean normalizing records into consistent schemas, enriching events with identity or asset context, filtering noisy data, redacting sensitive fields, and routing each signal to the destination where it creates the most value.

Store Data With Intent

Not all telemetry needs the same retention period, storage tier, or query speed. High-value operational and security data may need to stay hot for rapid search and alerting, while bulk historical data can move to cheaper long-term storage. The key is to align retention with investigation needs, compliance obligations, and cost tolerance. 

Analyze, Alert, and Refine

Only after that foundation is in place does analysis become truly useful. Dashboards, alerts, anomaly detection, and visualizations work much better when the underlying telemetry is already clean, consistent, and routed with purpose. Machine learning and AI can make this process more effective by helping teams spot unusual patterns, detect anomalies faster, and identify changes that may be easy to miss in high-volume environments.

That is especially important in security operations, where the real challenge is turning telemetry into better decisions with less noise. This is exactly why a pipeline-based approach becomes so valuable. When telemetry is already being normalized, enriched, and routed upstream, analysis can start earlier, before raw events pile up in costly SIEM platforms.

Solutions like DetectFlow placе detection logic, threat correlation, and Agentic AI capabilities directly in the pipeline. At the pre-SIEM stage, DetectFlow can correlate events across log sources from multiple systems, while Flink Agent and AI help surface the attack chains that matter in real time and reduce false positives. In practice, that means teams can move detection left and deliver cleaner, richer, and more actionable signals downstream.

Telemetry and Monitoring: Main Difference

Telemetry and monitoring are closely related, but they are not the same thing. Telemetry is the process of collecting and transmitting data from systems and applications. It captures raw signals such as metrics, logs, traces, and events, then sends them to a central place for analysis. Monitoring is what teams do with that data to understand system health, performance, and availability. It turns telemetry into dashboards, alerts, and reports that help people act on what they see.

The difference matters because many organizations still build their strategy around dashboards and alerts alone. Monitoring is important, but it is only one use of telemetry. Security teams also rely on telemetry for investigation, hunting, root-cause analysis, and detection engineering. In other words, telemetry is the foundation, while monitoring is one of the ways that foundation is used.

In fact, telemetry is like the nervous system, constantly gathering signals from every part of the body. Monitoring is like the brain, interpreting those signals and deciding what needs attention. Telemetry feeds monitoring. Without telemetry, there is nothing to monitor. Without monitoring, telemetry remains a raw signal with no clear action attached.

What Is a Telemetry Pipeline?

A telemetry pipeline is the operating layer between telemetry sources and telemetry destinations. It collects signals from applications, hosts, cloud platforms, APIs, identity systems, endpoints, and networks, then processes that data before sending it onward.

The easiest way to think about it is that telemetry sources produce data, but the pipeline gives that data direction. Without a pipeline, downstream tools become catch-all warehouses. With a pipeline, telemetry can be standardized, routed by value, and governed according to policy. That is especially important for security operations, where one class of data may need real-time detection while another belongs in lower-cost retention or long-term investigation storage.

From a business perspective, the value is straightforward:

• Lower cost by reducing unnecessary downstream ingestion
• Better signal quality through normalization and enrichment
• Less analyst fatigue by cutting noisy, low-value events earlier
• More flexibility to send each data type where it creates the most value
• Stronger governance through filtering, redaction, and policy-based routing
  

How Does the Telemetry Pipeline Work?

At a high level, a telemetry pipeline works through three core stages: ingest, process, and route. Together, these stages turn raw telemetry from many sources into clean, useful data to act on.

Ingest

The first stage is ingestion. This is where the pipeline collects telemetry from across the environment: applications, cloud services, containers, endpoints, identity systems, network tools, and infrastructure components. In modern environments, this stage must handle multiple signal types at once, including logs, metrics, traces, and events, often arriving at very different volumes and speeds.

Process

The second stage is processing, and this is where most of the value is created. Data is cleaned, normalized, enriched, filtered, and optimized before it reaches downstream systems. That can include removing duplicates, standardizing schemas, enriching records with identity or threat context, redacting sensitive fields, or reducing noisy data that creates cost without adding much value.

This is also where optimization and governance come in. Instead of treating all telemetry as equally important, teams can shape data according to business and security priorities. High-value signals can be enriched and preserved. Low-value records can be reduced, tiered, or dropped. Sensitive information can be handled according to the compliance policy. In other words, processing is where the pipeline stops being a transport mechanism and becomes a control mechanism. 

Route

The final stage is routing. Once telemetry has been shaped, the pipeline sends it to the right destinations. Security-relevant events may go to a SIEM or an in-stream detection layer. Operational metrics may go to observability tooling. Bulk logs may go to lower-cost storage. Archived data may be retained for compliance or long-term investigation. The point is that the same data no longer has to go everywhere in the same form.

By integrating collection, processing, and routing into one flow, a telemetry pipeline turns data from a flood into a controlled stream. It does not just move telemetry. It makes telemetry usable.

What Kind of Companies Need Telemetry Data Pipelines?

Any company running modern digital systems needs telemetry. The real difference is how urgently it needs to manage that telemetry well. Telemetry pipelines become especially important when blind spots are expensive, which usually means complex infrastructure, regulated data, customer-facing services, or constant security pressure. AWS’s observability guidance is explicitly built for cloud, hybrid, and on-prem environments, which already describes most enterprise estates.

That need shows up across many industries. Technology and SaaS companies rely on telemetry pipelines to protect uptime and customer experience. Financial institutions use them to monitor transactions, improve fraud detection, and keep audit data under control. Healthcare organizations use them to balance reliability with privacy and compliance. Retailers, telecom providers, manufacturers, logistics firms, and public-sector agencies need them because scale and continuity leave very little room for guesswork.

For security teams, the case is even sharper. Telemetry becomes the evidence layer behind detection, triage, investigation, and response. That is why the better question is no longer whether a company needs telemetry, but whether it is still treating telemetry like raw exhaust, or finally managing it like the strategic asset it has become.

How SOC Prime Turns Telemetry Pipelines Into Detection Pipelines

Telemetry pipelines started as a smarter way to move, shape, and control data before it reached expensive downstream platforms. SOC Prime extends that idea further with DetectFlow, which turns the pipeline into an active detection layer instead of using it only for transport and optimization. 

DetectFlow can run tens of thousands of Sigma detections on live Kafka streams, chain detections at line speed, drastically reduce the volume of potential alerts, and surface attack chains that are then further correlated and pre-triaged by Agentic AI before they hit the SIEM. It also brings real-time visibility, in-flight tagging and enrichment, and ensures infrastructure scalability that goes beyond traditional SIEM limits. That moves detection left, closer to the data, earlier in the flow, and far less dependent on costly downstream solutions.

For cybersecurity teams, that is the larger takeaway. Telemetry pipelines are not just an observability upgrade or a cost-control tactic. They are becoming a core part of modern cyber defense. And when detection logic, correlation, and AI move into the pipeline itself, telemetry stops being just something teams store and search later, instead acting on it in real time.

The post Telemetry Pipeline: How It Works and Why It Matters in 2026 appeared first on SOC Prime.

BOSTON, MA — March 12, 2026 — SOC Prime today announced the release of DetectFlow Enterprise, a solution that brings real-time threat detection to the ingestion layer, turning data pipelines into detection pipelines.

Running tens of thousands of Sigma detections on live Kafka streams with millisecond MTTD using Apache Flink, DetectFlow Enterprise enables security teams to detect, tag, enrich, and correlate threat data in flight before data reaches downstream systems such as SIEM, EDR, and Data Lakes. This gives organizations a way to expand detection coverage earlier in the processing flow, enrich security telemetry before downstream analysis, and scale detection on infrastructure they already have.

As detection volumes continue to grow, many SOC teams face the same set of operational challenges, such as delayed detections, rising ingestion costs, infrastructure bottlenecks, fragmented visibility across tools, and difficulty scaling rule coverage without adding more operational overhead. DetectFlow Enterprise is designed to address those pressures by moving detection closer to the data pipeline itself, where events can be inspected, enriched, and correlated in real time.

This release reflects a practical shift in how detection is operationalized. Rather than treating the pipeline as a transport layer alone, DetectFlow Enterprise turns it into an active part of the detection workflow. Teams can manage detections from cloud or local sources, stage and validate updates, and roll out changes safely with full traceability and zero downtime. This new architectural approach also establishes DetectFlow Enterprise as a foundation for unified CI/CD workflows across the SOC Prime Platform, supporting more scalable and efficient security operations.

Teams can also run thousands of detections directly on streaming pipelines with real-time visibility and in-flight tagging and enrichment. They can correlate events across multiple log sources at the pre-SIEM stage, helping surface the attack chains that matter in real time while reducing noise and false positives.

By performing correlation before data reaches the SIEM, DetectFlow Enterprise allows teams to evaluate full telemetry streams against thousands of rules without the performance and cost trade-offs of downstream ingestion. Built on SOC Prime’s Detection Intelligence dataset, shaped by 11 years of continuous threat research and detection engineering, DetectFlow uses Flink Agent to assemble detections, events, and relevant active threat context for AI-powered analysis. This helps security teams surface high-confidence attack chains, improve investigative clarity, and accelerate response to critical threats.

I have spent most of my career working across threat detection, SIEM, EDR, and SOC operations, and one challenge remained constant. Detection logic was always constrained by the performance and economics of the underlying stack. With DetectFlow Enterprise, we are giving teams a way to move beyond those constraints by turning the data pipeline into an active detection layer, running rules at stream speed, enriching telemetry in flight, and helping organizations scale detection without rearchitecting the rest of their security environment.

Andrii Bezverkhyi, CEO and Founder of SOC Prime

DetectFlow is designed to work with existing ingestion architecture, requiring no changes to established SIEM workflows. It supports both air-gapped and cloud-connected deployments, allowing organizations to keep data under their control while extending detection across the broader security ecosystem. It can achieve an MTTD of 0.005–0.01 seconds and help organizations increase rule capacity on existing infrastructure by up to ten times.

About SOC Prime

SOC Prime has built and operates the world’s largest AI-Native Detection Intelligence Platform for SOC teams. Trusted by over 11,000 organizations, the company delivers real-time, cross-platform detection intelligence that helps security teams to anticipate, detect, validate, and respond to cyber threats faster and more effectively.

Pioneering Security-as-Code approach, SOC Prime’s Detection Intelligence is applied to over 56 SIEM, EDR, Data Lake, and Data Pipeline platforms. The company continuously improves its breadth and quality of threat coverage, shipping top-quality signals for AI SOCs and security analysts.

For more information, visit https://socprime.com or follow us on LinkedIn & X.

The post SOC Prime Launches DetectFlow Enterprise To Enhance Security Data Pipelines with Agentic AI appeared first on SOC Prime.

The defense community deserves a threat intelligence platform that speaks their language. With our new Defense TIP mode, EclecticIQ aligns fully with NATO and US military doctrine, eliminating the friction caused by mismatched terminology, structure, and limited interoperability with joint and coalition intelligence workflows. This is a mission-ready capability built to meet the strategic and operational demands of modern defense intelligence.