Apply the latest ServiceNow vulnerabilities patch to fix three flaws, including critical sandbox escape CVE-2026-103093 and password leak CVE-2026-103094.
Prime Detect runs detection rules on your clients’ event streams before data reaches the SIEM. It applies Sigma rules to events in transit, tags each match with a severity and a MITRE ATT&CK technique, and links related matches into attack chains. In client testing, about 7% of telemetry was tagged.
MSSPs use Prime Detect to give every client the same 20,000+ detections regardless of which SIEM that client runs, to send less data into SIEMs they pay to operate, and to keep each client’s data inside its own pipeline. It works alongside the SIEMs you already run. It does not replace them.
An MSSP’s detection coverage is usually set by whatever each client’s SIEM can hold. That creates three problems that grow with every client you add.
Uneven coverage. Clients run different SIEMs with different rule limits. The same threat can be caught for one client and missed for another, depending on the platform underneath.
Ingest cost. Where you operate the SIEM, every event ingested is a cost against your margin, whether it carries a threat signal or not.
Engineering load. Your detection engineers spend their time porting and tuning the same rules across platforms instead of building the detections clients actually pay for.
Prime Detect moves detection upstream. Rules run on events as they stream through the pipeline, before any SIEM ingests them. Coverage depends on the compute you assign, not on each client’s SIEM. You then decide, per client, what reaches the SIEM.
What Prime Detect does
Detection in the stream
Applies Sigma rules to events in transit, before SIEM ingest
Runs 20,000+ detection rules plus your own custom detections, with no fixed rule ceiling
Tags every match with a severity and a MITRE ATT&CK technique
Links related matches into attack chains, so analysts see a sequence of activity instead of isolated alerts
Tagged telemetry you can route
Tags about 7% of telemetry, based on client testing
Sends tagged events to the SIEM and the rest to warm or cold storage, by your rules
Produces structured, ATT&CK-labeled events that AI triage and SOAR tools can use directly
Deployment and control
Runs on Kafka and Kubernetes you or your clients operate
Keeps data inside the pipeline, with no outbound connection required
Deploys air-gapped or in the cloud
Available open source or under an Enterprise license
How it fits with the SIEMs you already run
Prime Detect sits between the event pipeline and the SIEM. Nothing in the SIEM has to change, so it works across a mixed client base.
MSSPs typically deploy it in one of two ways:
Shared, multi-tenant: one Prime Detect deployment in your environment, with detections and routing set per tenant.
Per client: a deployment inside the client’s own infrastructure, for clients with strict data residency or air-gap requirements.
Rollout follows the same three steps either way:
Forward everything to the SIEM as today, with Detect tags added to matched events.
Add a SIEM index or dashboard that raises Detect-tagged events as high-priority alerts.
Once tuned, route untagged events to warm or cold storage to cut ingest.
What Prime Detect does not do
It does not replace the SIEM for centralized logging, search, investigation, or retention.
It does not decide whether an incident is significant or reportable. Your incident process makes that call.
It does not make data transfer decisions for you. Where data goes, and under which agreement, stays with your firm and your clients.
NIS2, DORA, HIPAA, and GDPR: where Prime Detect fits
MSSPs carry their own obligations and inherit their clients’. NIS2 defines managed security service providers in Article 6(40) and lists them in Annex I, so many MSSPs are covered entities in their own right. Prime Detect supports the detection side of each rule below. It does not discharge any of them alone.
Rule
What it requires
Where Prime Detect fits
NIS2 Art. 23
Early warning within 24 hours and incident notification within 72 hours of becoming aware of a significant incident
Surfaces chained activity earlier, so your team becomes aware sooner and has ATT&CK-mapped evidence for the notice
DORA Art. 28
Financial entities stay fully responsible for DORA compliance when they use ICT service providers
Gives your financial clients a per-tenant record of what was detected, which they need to show oversight of you
HIPAA 45 CFR 164.312(b)
Mechanisms that record and examine activity in systems containing ePHI
Examines every event in the stream and records matches with severity and technique. Logging and retention stay in the SIEM
HIPAA 45 CFR 164.308(b), 164.314(a)
Business associates report security incidents they become aware of to the covered entity
Tagged matches and attack chains give you the detail to report quickly and specifically
GDPR Ch. V (Arts. 44–49)
Transfers of personal data outside the EU/EEA only under Chapter V conditions, including onward transfers
Runs inside your or your client’s pipeline with no outbound connection, so detection itself adds no transfer
Sell coverage, not ingest
Most MSSPs price and staff around SIEM volume. That ties margin to how much data clients send, and ties coverage to which platform each client happens to run.
Prime Detect separates the two. Every client gets the same detection baseline. You send the SIEM only the events that matter. Each tenant gets an ATT&CK-mapped record of what you detected, which is the evidence regulated clients need to show oversight of their provider. Your engineers spend their time on the detections that set your service apart.
See it run. Watch Prime Detect work against a live event stream before you commit to a pilot. Request a demo, explore the live demo, or download the open source version to run it yourself.
FAQ
How can an MSSP keep detection capacity in step with client growth?
Take rule capacity out of each client’s SIEM. Prime Detect runs detections on the event stream, so coverage scales with the compute you assign, not with SIEM limits. Each new client gets the same 20,000+ detections, whether they run one SIEM or another.
What is the difference between pre-SIEM detection and direct SIEM ingestion?
With direct ingestion, logs go into the SIEM and detection rules run there. Pre-SIEM detection runs the rules on events in transit, before the SIEM ingests them. Prime Detect is a pre-SIEM detection layer. It tags matches and lets you send only high-priority events to the SIEM.
Can one Prime Detect deployment serve multiple clients?
Yes. MSSPs can run a shared multi-tenant deployment with detections and routing set per tenant. They can also deploy inside a client’s own infrastructure when data residency or an air gap requires it.
How is Prime Detect licensed for MSSPs?
Prime Detect is available open source or under an Enterprise license. Enterprise licensing for MSSPs is typically based on the number of clients served. Contact SOC Prime for pricing for your architecture.
What do NIS2 and DORA require of MSSPs?
NIS2 defines MSSPs and brings many of them into scope as covered entities. Under Article 23, they must give an early warning within 24 hours of becoming aware of a significant incident and a notification within 72 hours. Under DORA Article 28, financial clients remain fully responsible for their own compliance when they use an MSSP, so they will expect evidence of what you detect.
What does HIPAA require for audit trails and incident reporting?
The HIPAA Security Rule, 45 CFR 164.312(b), requires mechanisms that record and examine activity in systems containing electronic protected health information. Under 164.308(b) and 164.314(a), a business associate must report security incidents it becomes aware of to the covered entity, including breaches of unsecured protected health information.
Does pre-SIEM detection create GDPR data transfer issues?
Not by itself. Prime Detect runs inside your or your client’s pipeline and needs no outbound connection, so detection adds no transfer of personal data. Where the rest of the data goes, and under which Chapter V mechanism, remains your firm’s decision.
Will Prime Detect commoditize our detection engineering service?
It shifts where your engineers spend their time. Baseline coverage comes from the 20,000+ rule library, which SOC Prime keeps adding to. Your team can focus on client-specific detections, threat hunting, and tuning, which is the work clients see as your differentiator.
Prime Detect runs detection rules on your event stream before data reaches the SIEM. It applies Sigma rules to events in transit, tags each match with a severity and a MITRE ATT&CK technique, and links related matches into attack chains. In client testing, about 7% of telemetry was tagged. That is the slice worth sending to your SIEM.
Large organizations use Prime Detect to run 20,000+ detections without SIEM rule limits, cut what they pay to ingest, and keep a mapped record of what they detect for regulations such as DORA and NYDFS. It works alongside your existing SIEM. It does not replace it.
A SIEM runs detection rules against data it has already ingested and indexed. For a large bank, that model hits two limits.
Rule capacity. Most SIEM deployments run a few hundred active rules before search performance and cost become a problem. A team running 500 of them is choosing what not to see.
Ingest cost. Every event the SIEM ingests is an event you pay to store and search, whether or not it carries a threat signal.
Prime Detect moves detection upstream. Rules run against events as they stream through your Kafka pipeline, before ingest. Rule count is tied to the compute you give it, not to SIEM capacity. You then decide what reaches the SIEM based on what the rules found.
Regulators set the floor. DORA Article 10 requires mechanisms to promptly detect anomalous activity. NYDFS Part 500 requires larger covered entities to centralize logging and security alerting. Neither sets a rule count, but both expect you to show that your detection program works. More detections, each mapped to ATT&CK, give you broader coverage and a clearer record of it.
What Prime Detect does
Detection in the stream
Applies Sigma rules to events in transit, before SIEM ingest
Runs 20,000+ detection rules plus your own custom detections, with no fixed rule ceiling
Tags every match with a severity and a MITRE ATT&CK technique
Links related matches into attack chains, so analysts see a sequence of activity instead of isolated alerts
Tagged telemetry you can route
Tags about 7% of telemetry, based on client testing
Sends tagged events to the SIEM and the rest to warm or cold storage, by your rules
Produces structured, ATT&CK-labeled events that AI triage and SOAR tools can use directly
Deployment and control
Runs on the Kafka and Kubernetes your team already operates
Keeps data inside your pipeline, with no outbound connection required
Deploys air-gapped or in the cloud
Available open source as DetectFlow, or under an Enterprise license
How it fits with your existing SIEM
Prime Detect sits between your event pipeline and your SIEM. Nothing in the SIEM has to change. Most teams roll it out in three steps:
Forward everything to the SIEM as today, with Detect tags added to matched events.
Add a SIEM index or dashboard that raises Detect-tagged events as high-priority alerts.
Once tuned, route untagged events to warm or cold storage to cut ingest.
You can change the routing at any point as you learn what works in your environment.
What Prime Detect does not do
It does not replace your SIEM for centralized logging, search, investigation, or retention.
It does not satisfy the NYDFS centralized logging requirement on its own.
It does not decide whether an incident is material or reportable. Your team makes that call.
DORA, NYDFS, and SEC: where Prime Detect fits
These rules set detection, incident, testing, and disclosure duties for the banks they cover. Prime Detect supports the detection side of each. It does not discharge any of them alone.
Rule
What it requires
Where Prime Detect fits
DORA Art. 9
Continuously monitor the security and functioning of ICT systems
Runs detections on every event in the stream, not a sampled subset
DORA Art. 10
Mechanisms to promptly detect anomalous activity
Detects in transit, ahead of SIEM ingest and indexing
DORA Art. 17
An incident process to detect, manage, classify, and notify
Each match carries severity and ATT&CK technique, giving a structured basis for classification
DORA Art. 26
Threat-led penetration testing (TLPT) at least every 3 years, if designated
ATT&CK mapping shows which tested techniques you had detections for
NYDFS 500.14(b)
Class A companies: EDR plus centralized logging and security alerting
Adds detection coverage in front of your centralized logging. Does not replace it
NYDFS 500.17(a)
Notify the superintendent within 72 hours of determining an incident occurred
Surfaces chained activity earlier, so investigation can start sooner
SEC Form 8-K Item 1.05
Registrants: determine materiality without unreasonable delay, file within 4 business days of that determination
Attack chains give the team scoping evidence faster. The materiality call stays with you
The detection record examiners ask about
When an examiner asks how a bank detects threats, the answer is usually a list of SIEM rules. With Prime Detect, every detection is mapped to ATT&CK and tagged at the event level. You can show what you were watching for, what fired, and how related activity chained together.
That is the record DORA’s incident process and NYDFS’s 72-hour notice depend on. When an incident happens, the work of building it should already be done.
See it run. Watch Prime Detect work against a live event stream before you commit to a pilot. Use the default user name and passwords listed. Request a demo, explore the live demo, or download DetectFlow to run it yourself.
FAQ
What is pre-SIEM detection?
Pre-SIEM detection runs detection rules on events while they move through the data pipeline, before the SIEM ingests them. A SIEM-based model runs rules only on data the SIEM has already ingested. The difference is where the detection logic executes. Prime Detect is SOC Prime’s pre-SIEM detection layer
How can a bank run more detection rules without adding SIEM capacity?
Run the rules outside the SIEM. Prime Detect executes rules on the bank’s own Kafka and Kubernetes infrastructure, so rule count depends on that compute rather than SIEM limits. Banks can run 20,000+ rules instead of the few hundred a typical SIEM holds.
How much data does Prime Detect send to the SIEM?
That is your choice. In client testing, Prime Detect tagged about 7% of telemetry. Teams can send only tagged events to the SIEM and route the rest to lower-cost storage.
Does pre-SIEM detection satisfy NYDFS 500.14(b)?
No, not on its own. Section 500.14(b) requires Class A companies to centralize logging and security event alerting. Prime Detect adds detection in front of that system. It does not replace it.
How is Prime Detect different from a pipeline tool like Cribl?
Pipeline tools route, reduce, and transform data. Prime Detect runs detection logic on the data and tags what it finds. The two can run together: the pipeline shapes the stream, and Prime Detect identifies the threats in it.
Can Prime Detect run in an air-gapped environment?
Yes. Prime Detect runs inside your own pipeline and needs no outbound connection. It also supports cloud deployment.
Is Prime Detect open source?
Yes. The open source version is DetectFlow. SOC Prime also offers an Enterprise license.
Every SOC analyst knows the feeling. A new threat report lands in your queue, dozens of pages long, packed with techniques, tools, and timelines. Somewhere inside is the information your team needs to defend better, but finding it takes time you rarely have. Prime Architect removes that bottleneck.
Prime Architect is SOC Prime’s AI-powered workspace for threat research and detection engineering. It helps security teams move from raw threat intelligence to actionable defense, using agentic AI tools that do the heavy lifting. Paste a threat report in Prime Architect and AI can turn it into a short summary, a full summary, or a visual Attack Flow, depending on what you need.
If you want to see how far a single report can go, take a look at our earlier article on AI-powered Deep Threat Research. This article focuses on three ways to understand a report quickly: reading it in brief, reading it in depth, or seeing it as a diagram.
Detection engineering is only as fast as your ability to understand the threat in front of you. With AI, one threat report gives you:
Faster triage. Pull the key insights out of a long report before deciding what deserves attention, instead of reading it end to end.
A shared picture of the attack. Plain-language summaries and visual diagrams give analysts, engineers, and managers the same understanding of what the adversary did.
Better communication. A visual depiction of the attack helps engineers explain it to non-technical stakeholders, management, and executives.
Smarter defense. Seeing the sequence of adversary behavior helps you decide what to detect and what to prioritize.
Three Ways to Work with a Threat Report
Short Summary: the key points in seconds
Need a quick overview? A Short Summary gives you the key insights of the report in a concise form. It works well when you’re scanning several reports and need to know which ones deserve a closer look.
Full Summary: every detail, in plain language
Need every nuance? A Full Summary is an in-depth explanation covering all relevant details and fine points. Use it when you’re preparing a briefing, planning detection work, or explaining the threat to someone else.
Attack Flow: see the whole attack at a glance
Individual techniques tell only part of the story. Adversaries succeed by chaining behaviors together to reach their goals. Inspired by the open-source Attack Flow project, the Attack Flow tool uses AI to visualize adversary activity from a threat report in a structured way, helping defenders move from tracking individual behaviors to tracking sequences of behavior.
What you get:
Less time spent understanding the attack.
Visualized flows that inform detection logic. By identifying TTP chains, you can build proactive defense without relying on IOCs.
Easier prioritization. When linked to existing telemetry or detection rules, flows help you map threats to known gaps or current alerts.
Machine-readable MMD export. Integrate the result into your detection engineering workflows more easily.
How to Work with a Threat Report
Open Prime Architect and go to the Agentic Threat Research mode.
Click Code Editor in the upper right corner and paste the text of your threat report.
Select the button that matches what you want to do:
Analyze to generate a summary
Generate to create an Attack Flow
Select the tool from the agentic AI tools options, then click the Enter icon to proceed:
Short Summary for a concise overview of the key insights
Full Summary for the complete, in-depth breakdown
Attack Flow for a visual representation of the adversary’s activity
View the result:
For summaries: read the response on the left side of the screen.
For Attack Flow:
Click the Diagram tile to view the report as a diagram.
You can drag and drop the blocks, open the visualization in full screen, or change the scale.
Click the Matrix tile to view the report as a matrix.
Get Started Today
The next time a dense threat report lands in your queue, don’t read it line by line. Open Prime Architect and paste the report. Start with a Short Summary to get oriented, run a Full Summary when you need every detail, and generate an Attack Flow when you want to see how the attack unfolds.
Every day, threat intelligence teams read reports describing new attacker campaigns, and every day detection engineers face the same question: how do we turn this into detection content before the threat reaches our environment? Reading a long report, spotting the behaviors that matter, and writing a correct rule by hand takes time that most SOC teams don’t have.
Prime Architect gives security teams a faster way to handle this. Prime Architect is SOC Prime’s AI-powered workspace for threat research and detection engineering. Its agentic tools analyze threat intelligence and produce actionable defense content, so security teams can move from raw reports to detections faster.
A good place to start is generating behavior rules. Paste a threat report, and Prime Architect generates one or several behavior rules in Sigma format, ready to review, refine and deploy.
Why Use AI to Generate a Behavior Rule?
Behavior-based detections look for what attackers do rather than for indicators that change from one campaign to the next. They are more resilient and valuable, but also harder and slower to write. Using AI to generate a behavior rule removes the most time-consuming part of that work.
Faster time to detection. Go from a fresh threat report to a draft rule in a single workflow instead of hours of manual analysis.
Less manual effort. AI reads the report and extracts the behaviors worth detecting, so your engineers can focus on tuning and validation.
Coverage from a single source. Depending on the context you provide, AI can generate one behavior rule or multiple behavior rules from the same report.
Open, portable output. Rules are created as behavior rules in a Sigma format, so you can translate them into the language of your SIEM, EDR, or data lake.
One continuous workflow. Generation is only the start. You can validate, summarize, translate, deploy, and refine the rule without leaving the platform.
Behavior Rule with AI is one of the agentic AI tools available in the Agentic Threat Research mode of Prime Architect. Here is how to use it:
Open Prime Architect and go to the Agentic Threat Research mode.
Click Code Editor in the upper right corner and paste the text of a threat report.
Select the Generate button.
Select the Behavior Rule tool from the agentic AI tools options.
Click the Enter icon to proceed.
Click the rule tile to view the rule in the output panel.
Tip: The more context you give, the better the result. A detailed threat report that describes attacker techniques, tools, and command-line activity gives AI more behaviors to turn into rules.
What to Do After the Rule Is Generated
Generating the rule is the first step. Once your behavior rule or rules are ready, the next steps below help you get them into production and make sure your team understands them.
Save and translate
Once the rule is generated, you can take it into your workflow in a few clicks:
Copy to clipboard: paste the rule straight into your system and start working with it right away.
Save As > File.txt: download the rule as a file to share it, archive it, or use it outside the platform.
Save As > New Rule: store the rule in a custom repository, so your team has one place for all the detection content it creates.
Translate: convert the Sigma rule into the query language of your security stack, so the same detection works across different tools and isn’t tied to one platform.
Understand the rule: summaries and decision tree
Without leaving the generated rule, you can use three AI tools to help your team review, document, and triage faster:
Short Summary: a concise, plain-language overview of what the rule detects. Use it for ticket descriptions, handover notes, and quick peer reviews, so nobody has to read the full logic just to understand the purpose of a rule.
Full Summary: a detailed explanation of how the rule works, including what behavior it looks for and why. It helps new analysts get up to speed, gives you ready material for detection documentation, and supports audits and coverage reviews where you need to explain what each rule does.
Decision Tree: a visual map of the rule’s logic that shows how the detection conditions connect and how an analyst can work through an alert step by step. It helps SOC teams triage faster, reduces guesswork on unfamiliar alerts, and makes it easier to see where a rule might need tuning.
To use any of them, select Analyze, choose the tool, and click the Enter icon.
Validate before you deploy
Catch errors before they reach production. Go to Translation mode in Prime Architect, open the Improve tab, paste your rule, confirm the detected language, select Validate in the dropdown, and click Improve.
Make custom modifications with AI Every environment is different. Use the chat interface to adjust the rule to your needs, such as adding exclusions, narrowing the scope, or changing the logic, simply by describing what you want.
Put the rule into action
A detection only protects you once it is running. After you generate and review the rule, deploy it to your SIEM and let it start watching for the threat in your environment.
Start Turning Intelligence into Detections
With Behavior Rule with AI in Prime Architect, a threat report is no longer something your team reads and files away. It becomes working detection content in minutes. Open Prime Architect, paste your next threat report, and let agentic AI tools do the heavy lifting, while your team keeps control of every rule that goes into production.
Cribl Detect, released on September 29, 2026, is a SIEM that runs on Cribl’s data platform. The data it stores and searches is ingested through Cribl Stream Routes and Pipelines, so a sanitization step in those Pipelines determines what analysts, AI-assisted triage, alert notifications and retained datasets can access.
The Cribl LogTotal Sanitizer is an open-source Cribl Pack (this project is not affiliated with Cribl or SOC Prime) built on the sanitization engine of SOC Prime’s LogTotal. It pseudonymizes free-text log data in-stream. It detects eleven categories of sensitive values and replaces each one with a keyed HMAC token that carries a type label, for example <USER:…> or <IP:…>. Tokens are deterministic, so events that reference the same user, host or address can still be correlated after the original value has been removed.
Credentials, payment data, health data and personal identifiers are removed before data is stored. This reduces the impact of a breach and the compliance scope of the SIEM.
Correlation-based detections continue to work on tokenized values.
The Pack is MIT-licensed and runs on existing Worker capacity, with no per-GB licence fee.
Detect uses the standard Cribl model of Sources, Routes, Pipelines and Destinations. In-stream detections, federated search, AI-assisted investigation and alert routing operate on data that Stream writes to Cribl Lake or Cribl Search datasets (SOC Prime overview). Data that Detect queries in place through federated search, such as an existing S3 bucket, does not pass through a Pipeline and has to be sanitized when it is written.
A SIEM exposes event content to more consumers than a typical log pipeline: tier-1 analysts, MSSP partners, AI agents, Slack and PagerDuty notifications, and long-term retention. Removing sensitive values once, upstream of all of them, is simpler to operate and audit than enforcing access controls on each consumer.
Origin: SOC Prime’s LogTotal
The sanitization engine in the Pack was developed by SOC Prime. SOC Prime released LogTotal as a free public preview on August 26, 2026 (announcement). LogTotal sanitizes log files locally in the browser before anything is uploaded. The sanitized events are then correlated against SOC Prime’s detection content: about one million detection rules, a dataset of 13,000 labels, Higher Order Sigma rules and agentic AI correlation. LogTotal does not retain uploaded logs.
SOC Prime published the sanitization component separately as the open-source library @socprime/logtotal-sanitizer under Apache-2.0. The Cribl Pack is a community project by M3NIX that wraps this library.
The design decisions described below follow SOC Prime’s rationale for LogTotal, which identifies three common failure modes of log redaction:
Static masking replaces every IP address or username with the same placeholder. Ten failed logons then look identical, and a single compromised account can no longer be distinguished from a password-spray attack against ten accounts.
Plain find-and-replace misses values in nested JSON or unusual encodings, and over-redacts values that only look sensitive, such as version numbers shaped like IP addresses or UUIDs used as message IDs.
Unkeyed hashes can be reversed by dictionary attacks, and identical unsalted hashes from different organizations can falsely link unrelated incidents.
Keyed, typed tokens address all three.
How the Pack works
The Pack (cc-stream-logtotal-sanitizer) implements a Cribl custom Function. By default the Function applies all built-in detectors to _raw, replaces each match with a token and sets __logtotal_sanitized: true on events it modifies. _time and all other fields are left unchanged.
Detectors are evaluated in this priority order:
Secrets: bearer tokens, JWTs, API keys, PEM blocks and cloud provider tokens
Session cookies
Payment data, validated with Luhn and mod-97 checksums
Government identifiers
Health identifiers and ICD-like codes
Phone numbers
IPv4, IPv6 and MAC addresses
Hostnames and FQDNs
Usernames and email addresses
Geolocation
Home-directory paths
For JSON input, values under known sensitive key names are replaced based on the key name. The rest of the event is still processed by the regex detectors.
A token is the HMAC-SHA-256 of the rule ID and the original value, truncated to 16 hexadecimal characters. The same key, rule and value always produce the same token. In pseudo mode the token includes a type label. In mask mode, which is used for secrets and payment data, the token has the neutral form <R:…>. Example, with token values shortened:
before: user alice@corp.example failed login from 10.20.1.7 to db-prod-01.corp.example
after: user <USER:3f9a…> failed login from <IP:b81c…> to <HOST:0d4e…>
Custom rules are defined as a JSON array in the Function configuration. Each rule specifies an ID, a regular expression, a mode and a token prefix. Internal ticket or employee numbers, for example, can be mapped to <TICKET:…> tokens.
Deployment
The Pack is installed with Cribl’s standard Pack workflow in the Worker Group that sends data to Detect. Release files, requirements and installation instructions are in the project’s GitHub repository. In outline, the Pack is imported with custom functions enabled, a random HMAC key is stored as a Worker Group Secret, and the output is checked against the bundled preview sample. The Pack is then set as the Pipeline of a Route that delivers to Detect’s datasets, with a filter that selects the sources containing sensitive data.
Three implementation details need attention:
The Pack rewrites a single top-level string field, _raw by default. Fields extracted earlier in the Pipeline keep their original values, so the Pack has to run before parsing, or the fields have to be re-extracted from the sanitized _raw.
All Workers that need to produce matching tokens must use the same key, Pack version and rule configuration. Rotating the key changes every token, so rotation should be scheduled with dataset retention periods in mind.
Detect is available only on Cribl.Cloud. Running the Pack on a customer-managed (hybrid) Worker Group pseudonymizes data before it leaves the customer network. Cribl.Cloud has historically scoped custom functions and scripting to hybrid Workers (Cribl blog), so support should be confirmed before relying on Cribl-managed Workers.
In this layout, unmodified values exist only inside the customer network. Detections and enrichment that need the original values run before the Pack, and everything written to the destination contains tokens.
Distinguishing features
The main technical difference from Cribl’s native options is keyed pseudonymization. Original values are removed, but references to the same entity stay linkable across events.
Keyed tokens are not vulnerable to the dictionary attacks that work against plain hashes. An unkeyed SHA-256 of an IPv4 address or a username can be reversed by enumerating the small input space. An HMAC token cannot be computed without the secret key. The type label in each token (<HOST:…>, <USER:…>) still tells analysts and LLM-based triage tools what kind of entity an event refers to, so timelines remain readable.
Eleven detector families work without additional configuration. Checksum validation reduces false positives, such as random digit strings being matched as card numbers.
Re-identification does not require bulk decryption rights. Anyone holding the key can compute the token for a known indicator, such as a suspect account name, and search for it.
Because the engine is SOC Prime’s LogTotal library, it is also available as the LogTotal web application, a CLI and a Node.js package, including for air-gapped environments. With the same key and rule configuration, a log extract prepared for a vendor ticket or an incident-response retainer can be processed consistently with SIEM data. The code is open source, there is no per-GB fee, and the Pack bundles its dependencies.
Limitations and operational considerations
The largest operational impact is on detection content that depends on original values.
Tokenized IP addresses, domains and usernames do not match IOC feeds, GeoIP databases, CIDR-based rules or asset lookups. Mitigations: run in-stream detections and enrichment before the Pack, disable the ips and hosts rules on the affected Route, or send a full-fidelity copy to a restricted store.
The underlying library supports a neverRedact allowlist, but the Pack’s documented settings do not expose it.
Each event is evaluated against a large set of regular expressions. Aggressive mode increases both CPU cost and false positives, and Worker sizing should account for this.
Tokens cannot be decrypted. Re-identification is only possible by recomputing the token for a known value.
Conclusion
For deployments that send security data to Cribl Detect, the LogTotal Sanitizer Pack provides in-pipeline pseudonymization at low cost. Sensitive values are removed before they reach analysts, AI agents and long-term storage, while the entity relationships used by correlation rules are preserved. A practical rollout starts with a single high-risk source. Validate the output with the preview sample, confirm that the relevant detections still fire, and then extend the Pack to further Routes.
The Endpoint: Why AI Must Be Governed By Something It Cannot Reach
This morning NVIDIA announced the NVIDIA Open Agent Safety Platform, with SentinelOne named as key collaborator. This new initiative is directly aligned with what I firmly believe is the key to effective security and governance of AI. It’s also what I believe will be required to truly secure an AI powered world.
Every guardrail that exists today lives in software the model itself can reach.
The problem is simple to state and hard to solve. Models are aligned once and then run non-deterministically thereafter, increasingly at the endpoint and increasingly with the authority to act: in vehicles, industrial systems, humanoid robots, and agents with access to enterprise systems. Model alignment is checked before release, but nothing independently monitors the system at runtime.
Last week showed the risks. An AI agent in training at a frontier lab bypassed its network restrictions. Monitoring flagged it within 15 minutes. The automated kill switch failed, and it took two and a half hours to stop the run by hand. Watching is not enough if nothing independent can act.
An organization cannot reliably delegate consequential work to an agent without knowing what it is doing, whose authority it is exercising, and whether the boundaries around that authority actually hold. Those assurances require foundations throughout the infrastructure. One cannot depend solely on a model following instructions.
Out of the Model's Reach
Security has had a standard for this problem since 1972, when James P. Anderson's study for the U.S. Air Force defined the reference monitor. The mechanism that enforces policy must be tamperproof, must always be invoked, and must be small enough to verify. It remains the gold standard for enforcement architecture. A guardrail the model can reach fails the first test by definition. NVIDIA's own security engineers noted: "A control that the agent can decline to invoke is not an effective security control."
AI requires the same standard. A model must be governed by a layer that is separate from the intelligence it supervises and unreachable by it: one that runs in real time alongside the model and its compute, and that produces cryptographically attestable evidence of runtime behavior which operators, regulators, and insurers can independently verify.
A Foundation In Hardware
Today's announcement of NVIDIA's Open Agent Safety Platform is an important step toward the computing foundations that enterprise AI needs. Of its capabilities, hardware isolation and attestation are the most consequential. How the industry uses them, and what it builds on them, will determine their value.
The conviction behind this announcement is one I share with Jensen Huang: AI changes what the computing stack must provide for its behavior to be trustworthy. That requires a clear connection between the agent runtime and the protected infrastructure beneath it, in a cohesive stack where visibility and enforceable control underpin AI execution.
SentinelOne is committed to security rooted in hardware. NVIDIA's BlueField-4 places enforcement outside the host operating system, where tenant software cannot disable or bypass it. Together with other secure enclave architectures, it provides a way to secure the runtime directly from the hardware and to reduce the surface that must be secured to the hardware boundary itself. It also consolidates the cybersecurity stack: network, identity, data into the endpoint.
This is another step, and substantial work remains to build a truly secure architecture. The hardware boundary must itself be soundly secure, particularly where real-world applications are unforgiving. It must hold across deployment environments: enterprises and governments will use frontier AI services alongside workloads that must remain local, and their authority over data and actions must survive those transitions. And it must extend to any AI, on any compute that supports it.
The objective is clear. Anything that runs on a truly secure, hardware-rooted compute architecture should be provably governed, in the physical world and the digital one. Achieving that must also be simple, intuitive, and transparent to the end user. No one should need to understand attestation in order to benefit from it.
Verifiability
The broader question is how to govern action when agency is distributed across humans and machines. That comes down to six requirements.
If a system cannot act in time, it does not matter.
If it cannot show the evidence behind its actions, it cannot be trusted.
If it cannot act independently when required, it cannot defend.
If it cannot stay within boundaries, it cannot be governed.
If its actions cannot be attributed, authority disappears.
And if accountability is lost, control is an illusion. That is ‘verifiable agency’.
What makes these requirements achievable is continuous behavioral visibility: the ability to observe, understand, and verify how actions are being taken across humans and machines in real time.
SentinelOne was founded more than a decade ago on the conviction that behavior is the decisive signal, the only reliable way to distinguish the benign from the malicious at machine speed. Our behavioral AI is deployed at global scale today, protecting nearly one-fifth of the Fortune 500, and we are extending the same principle to make autonomous action verifiable, governable, and trustworthy.
In practice, this means AI operates at machine speed while every autonomous action remains traceable, auditable, and overridable by a human. AI provides scale, speed, and pattern recognition. Humans provide judgment, context, and the values these systems are expected to uphold. The arrangement is as much a matter of accountability as of engineering.
Certifiable and Insurable
Regulation, standards, and insurance are converging on the same requirement. Regulators will expect evidence of how AI systems behave at runtime, not only how they were aligned before release. Standards bodies will need a common basis for defining and measuring that behavior. Insurers will price risk against it. Attestation is the evidence all three will depend on. Within a few years, an AI product without attested runtime governance will be difficult to certify and difficult to insure, and more so for physical AI.
Building these foundations is the work SentinelOne is committed to. It will take sustained research and engineering across the stack, with claims of trust grounded in demonstrable behavior.
I congratulate the NVIDIA team. This is a meaningful commitment and an important milestone toward making increasingly capable AI truly governable, and toward making organizations willing to entrust it with work that matters.
We’re taking a maximalist stance (“PQ everything!”), because as an infrastructure provider to the world, we want to give our customers the peace of mind that using Cloudflare ensures that their traffic is future-proofed against quantum adversaries.
But how does one accomplish such a massive migration at an organization of our size and scale? After all, cryptography is the base layer for almost all of the world’s digital systems, including the software services and the networking protocols that power our platform.
To drive our PQ migration, we have three key goals.
First, we want to help our product and engineering teams understand how cryptography is being used and how they should be upgrading it. This should cover both the upgrades to post-quantum encryption and to post-quantum authentication. Many of our products have already been upgraded to post-quantum encryption over TLS 1.3, but we still want to cover the long tail of TLS connections, as well as upgrade any other uses of public-key encryption. Meanwhile, it’s still earlydays for our deployment of post-quantum authentication.
Next, we want to provide progress metrics for the migration. These might include per-repository and per-product counts of the use of classical and post-quantum cryptography.
Finally, we want to surface prerequisites early. If our products or platform rely on protocols that don’t yet have a PQ migration plan (because PQ variants of the system have not yet been considered, because PQ standards do not exist or lack consensus, or because software libraries or other key ecosystem components do not yet have PQ support), then we need to know now. That way we can work with the relevant stakeholders, standards bodies and ecosystems to help drive their PQ migration plans, so that we can meet our own 2029 PQ migration timeline.
This post is the story of how we’re going about this. We explain how we turned to AI to help us solve some of our problems and how we’re developing an internal tool called CryptoLabe to help us. CryptoLabe is named after the mariner’s astrolabe, a navigation instrument refined by Portuguese navigators. Just as an astrolabe helped sailors determine where they were and chart a course, CryptoLabe helps us discover cryptography in our code, understand how it is used, and chart a path to post-quantum migration.
CryptoLabe is highly specialized to our internal systems (our repositories, our ticketing systems, and internal documentation processes) and still evolving as we continue its development, so we aren’t making it available to customers. Nevertheless, we are sharing our learnings so that other organizations can build upon our efforts as they work through their own PQ migration journey.
The scale of the problem
The software that powers most Cloudflare products lives inside our single centralized source control management platform. This means we can find most uses of cryptography across our platform by just looking through our codebase.
While the centralization of our codebase is a marked advantage for us, we still need to contend with three challenges that come with the scale of this problem. First, our code is spread across many repositories. Second, cryptography rarely announces itself plainly in the code. Instead, it hides in
shared libraries that a repository imports but may or may not actually call
upstream and protocol defaults, like a TLS 1.3 listener that is configured to negotiate a classical key exchange such as X25519 rather than post-quantum X25519MLKEM768
configuration files that select algorithms far away from the code that uses them, like a TLS responder whose key exchange protocols are pinned in a YAML file stored in a different repository
code paths that are dead, test-only, or on a path to being deprecated
Third, cryptography discovery is about more than just pattern matching. Grepping for certain algorithm names (e.g. “RSA” or “X25519”) overcounts, because it finds cryptography in unused code. Grepping also undercounts, because it misses defaults and indirect uses in dependencies and configuration. Most importantly, it can't tell you how the cryptography is used. A classical ECDSA signature could be part of a JWT, IPsec, TLS, or SSH, and each has a completely different migration path. Many uses also depend on the other side of the connection: a TLS server may support both post-quantum key exchange and classical key exchange; the one it chooses to use would depend on the client.
Turning to AI
It turns out that AI is pretty good at doing more than just grepping. A model can search a codebase, follow evidence across files, and return structured analysis. It can also enrich findings by pulling information from other sources, like our internal documentation and ticketing systems. In fact, AI can even explain how cryptography is being used and how it should be updated. We’ve been putting that idea to the test as we develop CryptoLabe.
As we said before, our first two goals are to (1) discover and understand the use of cryptography in our codebase, and also (2) to get metrics on the state of our PQ migration. Towards these goals, our current implementation of CryptoLabe performs scans in two stages, as shown in the figure below.
The first “discovery” stage starts by mapping the repository. It then searches for cryptography through source, configuration, manifests, lockfiles, scripts, tests, and documentation. Among other things, the scan looks for the use of cryptography like key agreement, signatures, asymmetric encryption, PKI, tokens, credentials, hardware security module integrations, and more. This discovery stage produces a set of "raw observations."
Each raw observation feeds a run of the second stage. This “analysis” stage first re-checks the observation against the source code. It then investigates how the cryptographic operation is used at runtime, what role the repository plays, and which internal or external parties it depends on. When necessary, it can inspect related code in other repositories to complete the analysis. Finally, it takes a pass over its own conclusions, searching for missing or conflicting evidence such as configuration overrides, test-only code, or incorrect assumptions about runtime behavior.
Next, the model assigns a classification to the finding. If there is not enough evidence to assign a classification, the model assigns More evidence needed, External dependency, or Unknown rather than guessing.
This is the current list of classifications used by CryptoLabe, containing catch-all classifiers which will likely be refined as we proceed through our migration. (As an example, we could refine our classifiers by splitting the “encryption” classifier into key agreement and HPKE; you get the idea.)
This is a catch-all category that finds use of an RSA signature or elliptic-curve (ECDSA) signature in anything, for example a certificate, a TLS handshake, another protocol handshake. These signatures are broken by Shor's algorithm.
Classical token
We found a lot of RS256 or ES256 JWT tokens, so we created a special classification for them. These are JWTs that use classical RSA and ECDSA signatures; RFC 9964 defines a post-quantum replacement using ML-DSA.
PQ-ready hybrid key exchange
Finds hybrid post-quantum key exchange in TLS 1.3, i.e. X25519MLKEM768. This is the most prevalent use of PQ encryption in our codebase.
PQ-ready
Finds other uses of post-quantum cryptography that are not X25519MLKEM768 in TLS 1.3, like ML-DSA.
Finally, it generates a report that serves two audiences: (1) product managers who need to understand what the migration means for their product, and (2) engineers that need enough detail to execute the migration.
Here’s a (cropped) view of one of our reports:
While we’ve been iteratively reviewing findings against the source code and with relevant engineers, we do not yet have a ground-truth dataset for reproducibly comparing different versions of the prompts we’ve tried for CryptoLabe.
CryptoLabe runs across two Cloudflare Workers. There’s a scanner Worker that runs the scans. And there’s an inventory Worker that serves the dashboard, exposes the API, and stores everything in a D1 database. The two communicate through Service Bindings. A scan starts when someone requests it from the dashboard, and the inventory Worker passes the request to the scanner.
Orchestrating a scan
We need a way to keep a scan alive and on track from start to finish, without building our own job orchestration system. We did this with Agents SDK. Each repository gets its own persistent coordinator built on a Durable Object (DO). A bounded queue in front of the coordinators limits how many scans run at once. When a scan's turn comes, the coordinator tracks its progress and handles cancellation, retries, and recovery.
The coordinator doesn't do the analysis itself. It hands the work to Cloudflare Workflows, so that they can persist progress and automatically retry failed steps. The coordinator moves each repository through four stages:
discovery Workflow (the first scanning stage that produces raw observations)
deep analysis Workflow (the second stage, run on each raw observation)
merge Workflow (that builds a list of findings for a given repository, including combining repeated or similar finds)
publish workflow (that hands results back to the inventory Worker)
The first two workflows need the model to have access to the repository's code. We want this access to be isolated, so we don’t risk damaging the codebase. That’s why CryptoLabe downloads the repository once, at an exact commit, at the start of each scan, and then stores that snapshot in R2. Each Workflow then restores the snapshot into a fresh, short-lived Cloudflare Sandbox, an isolated container. The model then works with the Sandbox through a small set of read-only tools on an immutable snapshot of the code, even if the codebase changes while the scan is still running.
Calling the model at scale
If we want to scan through all of our (many!) repositories, we have to worry about both cost and capacity.
For cost, the model loop sends its requests through AI Gateway to cost-effective open-weight models hosted on Workers AI. Putting the model behind AI Gateway also makes it easy to switch models as better or cheaper ones become available.
Capacity became a problem once we scanned many repositories at once. Bursts of model requests began triggering HTTP 429 (rate limit) responses from AI Gateway, and scans retrying independently only made the bursts worse. We solved this with a single, global Durable Object that paces every model request across all scans, including retries. When any scan hits a rate limit, the cooldown is shared and all scans back off together, so concurrent scans share the available capacity instead of competing for it.
Prerequisites and hard cases
Let’s now get into our third goal: surfacing prerequisites and hard cases early.
A lot of ink has been spilled about ecosystem readiness for the PQ migration, and we are now going to spill some more. As everyone knows, a PQ migration cannot happen in a vacuum. For migration to succeed, post-quantum cryptography must be supported in relevant software libraries (e.g. BoringSSL) and across parties that participate in the ecosystem (e.g. clients, browsers, origins, cloud proxies, certificate authorities, etc.). Standards are also an important indicator of ecosystem support, although a standard that is still in “draft” state does not necessarily mean deployment cannot proceed. As an example, we deployed X25519MLKEM768 in TLS 1.3 back in 2022 when it was still a “draft” at the Internet Engineering Task Force (IETF) while it was only finalized as RFC 10024 in 2026.
Either way, our point is that in order to upgrade a system to PQ cryptography, we need to understand its dependencies and level of ecosystem support.
That’s why CryptoLabe uses the concept of “prerequisites” to highlight findings that cannot be immediately remediated by an individual product team working alone.
A prerequisite can be something as straightforward as “we are currently blocked on migrating to post-quantum JWTs.” We say this is straightforward because there is already a standard (RFC 9964) for post-quantum JWTs. Nevertheless, if our software libraries don’t yet support validating post-quantum JWTs, or if we’re using a token issuer that does not yet issue post-quantum JWTs, we can’t go company-wide and ask each of our product teams to start PQ-ing their JWTs. This migration is blocked until we solve its core prerequisites. CryptoLabe lets us group together findings that (likely) have the same prerequisite, which also helps us decide how to prioritize resolving these prerequisites.
For example, the snapshot below shows the six findings from CryptoLabe that have post-quantum SAML as a prerequisite. (SAML is a protocol for single sign-on (SSO).)
On the other hand, there may be uses of cryptography that lack even a basic level of ecosystem support. We’ve been calling these “hard cases.” To find them, we wrote a separate prompt that ignores “vanilla” uses of cryptography (e.g. ordinary TLS between internal systems) and instead looks for custom cryptographic protocols, keys, or signatures used in size-constrained fields, cryptography built into hardware, specialized cryptographic constructions (like blind signatures), protocols without a PQ standard, and dependencies on external parties that do not yet support PQ cryptography.
This prompt is shorter and simpler than those used for CryptoLabe, since its only job is to find hard cases. In our qualitative review, we found that it got better results when it ran in one fell swoop against all our repositories, while also taking in context from our internal ticketing and documentation system.
Here’s an example of a “hard case” we found: a certificate carried in an HTTP header. Post-quantum certificates and signatures are larger than their classical counterparts, so if the header (or an intermediary, or the application processing the header) assumes a certificate has a certain size, changing the signature algorithm may break the system. Our next step is to determine whether this code will remain in use in the long term. If it will, we need to measure the relevant size limits and decide how to accommodate the larger certificate.
An important lesson here is that no single scan finds everything. Our repository-by-repository scans were effective at discovering common uses of cryptography. Meanwhile, this targeted scan worked better for “hard cases” because it ignored well-understood cryptography and had more context about each product and its dependencies.
The bottom line is that different approaches find different things, and every finding still needs to be checked by the engineers who understand how the system actually works.
Sharing our prompts
We’ve been messing around with the best way to write prompts for CryptoLabe for the last several months. We don’t yet have a ground-truth dataset for comparing one prompt’s performance against another, and we are not convinced we have 100% coverage of all uses of cryptography in our codebase. Instead, we have iterated by running scans, reviewing findings with the engineers that maintain the repositories, investigating misses that came up during these reviews and revising the prompts. Nevertheless, we decided to publish selected prompts, so other teams can learn from and adapt our approach. These prompts are starting points, not a standalone version of CryptoLabe, and the quality of their results will depend on the model, tools, context, and engineering review available.
Thinking through your own PQ migration
At Cloudflare, we’re taking a maximalist approach to our PQ migration because of our goal of acting as a provider of post-quantum cryptography for customers and the Internet at large. But most organizations do not need to start by finding every use of cryptography in every repository in every one of their products. In fact, most organizations should not be doing this, because at this time it's a waste of precious resources.
Before scanning a single repository, you can protect traffic in bulk wherever possible. If your websites run through Cloudflare, we protect your data in transit with post-quantum encryption already today; check this out with our new PQ visibility features. Our SASE platform, Cloudflare One, provides post-quantum encryption for private network traffic. Post-quantum encryption is provided at no additional cost and without requiring you to upgrade every origin server or private application on your enterprise network. This gives you a compensating control while you work through discovering and understanding the use of cryptography inside your own systems.
An exhaustive cryptographic inventory is not a prerequisite for action. Instead, organizations should first identify the systems whose compromise would matter most, discover their use of cryptography, and then PQ that cryptography in priority order. Here is one way to begin:
Choose a repository for one important system. Start with something that handles sensitive or long-lived data, authenticates users or software, or is exposed to the public Internet.
Run cryptography discovery against that repository. We hope our description of CryptoLabe will be helpful to this effort!
Validate the results. Ask the team who owns the system to validate the results of cryptography discovery and confirm that the cryptography finding is needed long term and needs to be upgraded to PQ. It’s important to remember that it might not need to be immediately upgraded to PQ if there is another compensating control in place.
Prioritize action. Figure out what upgrades you can make now and what upgrades are blocked. Record shared prerequisites that need help from a library, vendor, standards group, or another part of your organization. Prioritize your findings and make a plan for addressing the highest-impact systems and prerequisites first.
That gives you the beginning of a PQ transition plan, without requiring a complete map of every cryptographic operation in your organization. CryptoLabe is still ever-evolving, but its scans and results have been illuminating to us as we plan our migration. We hope these shared learnings will be useful as you continue to work through your own PQ migration.
Acknowledgements: Many people across Cloudflare provided feedback on and contributed to CryptoLabe, including Davide Marquês, Peter Wu, Phil Schmieder, JP Aumasson, Andrew Galloni, Christopher Patton, Luke Valenta, Mari Galicer, Vânia Gonçalves, and the Client, Tunnel and Gateway teams who reviewed reports produced by the tool.
MITRE ATT&CK is the common language security teams use to describe attacker behavior, but that language keeps evolving. Each new version reorganizes tactics and techniques, and a platform that falls behind doesn't just miss updates, it risks misclassifying the threats it's meant to help you understand. With Intelligence Center 3.9, EclecticIQ now supports MITRE ATT&CK v19.1, bringing one of the most significant recent structural updates to the framework into the platform.
On September 4, 2026, Oren Yomtov, a security researcher from Accomplish, responsibly reported a vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes (which is built on Containers), through Cloudflare’s bug bounty program. Cloudflare has fully remediated the vulnerability, and we have no evidence that customer data has been compromised.
This post was prepared in collaboration with Oren Yomtov and the Accomplish security research team, whose detailed report and controlled testing helped us validate the issue and respond quickly.
Cloudflare Containers run workloads on multi-tenant infrastructure and automatically assign them to eligible servers; customers cannot select the underlying host. The researchers demonstrated that a customer with a Workers Paid account could recover residual disk blocks previously used by Containers on the same host. The technique could not target a particular customer, workload, host, or data, and residual data was not guaranteed to be present.
Cloudflare applied a fix across the Containers fleet, with no customer-side configuration changes required. Within the historical disk-I/O telemetry available to us, we identified no evidence of malicious exploitation. Activity we could attribute to the reported technique came from the researchers and Cloudflare engineers conducting authorized validation.
Here, we explain the underlying storage behavior, its potential impact, our investigation, and the actions we took in response.
How container storage allocation works
Cloudflare Containers use Linux device mapper thin provisioning (dm-thin) to provide each container with a writable root disk. Each container lives inside a dedicated virtual machine powered by the Firecracker virtual machine monitor. Firecracker presents this disk to the virtual machine as /dev/vdc.
Thin provisioning allocates physical storage only when a virtual disk writes to a previously unmapped region. The affected storage pools used a 64 KiB thin-block size. When the thin volume backing a container's root disk was deleted, its physical blocks were returned to a pool that served workloads belonging to multiple customer accounts.
The affected pool configuration included the following option:
skip_block_zeroing
With this option configured, dm-thin skips zeroing newly allocated blocks before making them accessible. Consequently, when a previously-used 64 KiB block was reassigned, a full-block write replaced its previous contents, but a smaller write changed only the written portion. The remainder could retain data from the block’s previous owner.
How the exploit worked
Reading an unmapped region of a new thin disk did not reveal residual data. For an unmapped region of the thin device, dm-thin returned zeroes without allocating a physical block.
The proof of concept identified 64 KiB-aligned regions corresponding to free space in the guest’s ext4 filesystem and wrote one aligned 4 KiB block into each region.
When such a write reached an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool. The 4 KiB write replaced only that portion of the block, and because block zeroing was disabled, the remaining 60 KiB could retain data from a previous container.
A subsequent raw-device read could therefore observe bytes that the new container had never written.
The proof of concept performed the following steps:
Create a container using a Workers Paid account.
Open the writable root disk at /dev/vdc.
Read the disk and record a baseline.
Write one 4 KiB block into each selected 64 KiB region corresponding to ext4 free space.
Read the resulting blocks again.
Examine only the portions not overwritten by the new container.
The submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes. Although the researchers recovered raw blocks to validate the issue, the materials provided to Cloudflare contained no third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values. As described below, the researchers have also confirmed that they securely deleted the recovered data.
How the vulnerability was validated
The researchers used ext4 directory block checksums to distinguish blocks belonging to their own test filesystem created for the proof of concept from blocks originating from other filesystems.
When ext4 uses the metadata_csum feature, directory block checksums incorporate values associated with the filesystem and inode.
Across six production placements, the researchers reported:
All 5,614 testable directory blocks.
Zero of those blocks were attributed to the researchers’ filesystem.
2,700 distinct foreign directory inodes identified through checksum analysis.
To validate the method, the researchers tested it against blocks they had deliberately created and deleted in the controlled test filesystem used for the proof of concept. The method correctly attributed all 162 blocks to that filesystem.
The researchers ultimately observed residual material on 18 of 24 placements and 20 of 22 underlying nodes across four continents. The recovered block types included directory structures, database pages, and structurally complete SQLite databases. The researchers reported using scripts that output only aggregate counts and format checks, not recovered file contents. The materials submitted to Cloudflare contained no recovered content values or third-party identifiers. The researchers subsequently confirmed that recovered data under their control remained confidential and was securely deleted following submission, consistent with Cloudflare’s HackerOne disclosure policy.
Impact
The vulnerability would potentially have allowed for a customer with a Workers Paid account to recover residual data from storage blocks previously used by other customers’ Containers on the same underlying host.
A successful exploitation would have crossed the tenant-isolation boundary and could disclose filesystem metadata, directory structures, database pages, and application data.
However, an attacker could not select a particular victim or access an actively attached disk. Exposure depended on Cloudflare’s workload placement and which previously released blocks dm-thin reassigned. Moreover, the researchers did not demonstrate modification of another customer’s active data or impact to workload availability.
How we mitigated the vulnerability
Our first mitigation was to remove skip_block_zeroing from the dm-thin pool configuration across the fleet. This restored dm-thin’s default behavior of clearing newly allocated blocks before exposing them to a container. It stopped the reported technique, in which a small write triggered allocation and a larger read recovered residual data from the remainder of the block. The researchers independently confirmed that their proof of concept no longer worked after this change.
Zeroing new allocations did not sanitize blocks already mapped into existing thin devices. These mappings existed in running container disks and in each host’s cache of prepared dm-thin snapshots for OCI image layers. A new container could inherit mappings from a cached layer without allocating those blocks again, allowing residual bytes in unused regions, including ext4 free space, to remain readable through raw reads of /dev/vdc.
We therefore also retired all running container disks and removed cached image snapshots created before the mitigation. We drained hosts during off-peak hours, restarted the VMs on each host, and cleared each host's image cache so that disks and cached layers were recreated using zeroed allocations. We have completed this cleanup across the Containers fleet.
No evidence of exploitation
As part of our response, we investigated whether other workloads showed activity consistent with the reported exploitation technique. We reviewed retained historical disk-I/O telemetry from our container infrastructure, using the researchers’ proof of concept and our internal reproduction as reference activity.
The proof of concept produced a characteristic relationship between writes and reads. When a 4 KiB write reached a previously unmapped region, it could trigger allocation of a reused 64 KiB storage block. With zeroing disabled, the remaining 60 KiB could retain data from a previous container. Subsequent reads could therefore recover substantially more data than the new container had overwritten.
Using these characteristics, we developed detection signatures and applied them to the historical telemetry available to us. We identified activity attributable to the researchers and Cloudflare engineers conducting authorized validation, and did not identify additional activity consistent with the reported technique.
We saw no evidence that this specific attack vector was exploited by anyone else.
Cloudflare customers are protected
As we noted above, Cloudflare has patched this vulnerability and remediation does not require any further action by Cloudflare customers. In addition, we found no evidence of any malicious actor abusing this vulnerability.
Moving quickly with transparency
We thank Oren Yomtov and the Accomplish security research team for their thorough research, responsible disclosure, and collaboration on this post. We encourage the Cloudflare community to submit any identified vulnerabilities to help us continually improve the security posture of our products and platform.
We also recognize that the trust you place in us is paramount to the success of your infrastructure on Cloudflare. We take these vulnerabilities very seriously and will continue to do everything in our power to mitigate impact. We deeply appreciate your continued support and trust in our platform, and remain committed not only to prioritizing security in all we do, but also acting swiftly and transparently whenever an issue arises.
Timeline
September 4, 15:26 UTC: Oren Yomtov from Accomplish reported the issue through HackerOne.
September 4, 18:45 UTC: Cloudflare opened a security incident and confirmed the production setup that caused the flaw.
September 4, 21:27 UTC: Cloudflare merged the runtime fix and its reuse test.
September 4, 22:03 UTC: Cloudflare merged the changes for new and live pools.
September 4, 23:15 UTC: Cloudflare started rolling out the changes.
September 7, 06:13 UTC: Cloudflare completed rolling out the changes and began clearing old pool data.
September 14, 10:50 UTC: The researchers reported that their proof of concept had stopped working.
September 14, 12:52 UTC: Cloudflare awarded the researcher a bounty.
September 19, 15:03 UTC: Cloudflare completed cleanup of all pre-mitigation cached snapshots across the affected fleet.
For years, SOC Prime has focused on one core problem: curating behavioral detection rules that cover both the threats that never go away and the new ones that emerge every day. As agentic AI changes how security teams work, we see the same opportunity opening up in a new area — and we’re expanding our curation approach to meet it. Meet the Agentic Skills Marketplace, available inside Prime Architect’s Agentic Threat Research.
The Problem: Capability Isn’t the Bar
Agentic AI is giving security teams more skills and agents to choose from than ever. But in cybersecurity, capability alone was never the bar. Before a skill earns a place in a SOC workflow, teams need to know what it does, what it can access, how it operates, and whether it can be trusted. That’s the gap the Agentic Skills Marketplace is built to close — curation, applied to a new kind of asset.
Built on Infrastructure We Already Trust
This isn’t a new direction so much as the next step on one SOC Prime is already on. Prime Architect’s Agentic Threat Research already lets analysts take a raw threat report and, with one click, turn it into structured, actionable intelligence and environment-tuned detections — without the data ever leaving SOC Prime infrastructure.
That capability is backed by ongoing R&D across bare-metal and cloud architectures, using multiple open-weight models deployed on infrastructure SOC Prime owns. Owning that infrastructure means control over data sovereignty and performance, and it reflects a broader belief: when the people building the AI are also the security experts, security becomes a design principle from the start, not a feature bolted on later. The Agentic Skills Marketplace is built on that same thinking.
The marketplace launches with more than 1,000 open-source skills, organized around the functions defined in the NIST Cybersecurity Framework(CSF) 2.0 — Govern, Identify, Protect, Detect, Respond, Recover — so teams explore skills in the context of the work they’re already doing, rather than starting from scratch.
That means real, ready-to-use skills for the workflows that eat up analyst time:
Detection engineering — Turn raw log samples, detection ideas, or descriptions of attacker behavior into detection content. Skills can guide the agent through analyzing relevant fields and producing detection logic tailored to the target environment.
CTI analysis — Process unstructured threat reports and extract useful intelligence, including hashes, domains, IP addresses, URLs, malware names, techniques, and affected technologies. An extraction pipeline can define what to look for and how to organize the results.
Threat hunting — Turn a hunting hypothesis into a query designed for a specific data plane and its available data sources. Skills provide the workflow needed to move from what to investigate to a runnable hunt.
Adversary emulation — Structure attacker behavior for emulation and testing. Skills can help identify relevant techniques, translate adversary behavior into actionable steps, and support workflows based on mapping techniques within MITRE ATT&CK and MITRE Attack Flow.
These are exactly the kinds of repeatable, judgment-heavy workflows Agentic Skills is built for. Instead of a one-off prompt that may or may not capture the nuance of the task, you get a curated, reviewed, versioned instruction set the agent follows every time — built by the SOC Prime team, by trusted publishers, or by you.
And if a workflow is unique to your team, you’re not limited to what’s in the marketplace — you can create your own personal skills from scratch, with your own instructions, and use them exactly like any marketplace skill.
Know Exactly What Skills You’re Using
Before installing any skill, its details page gives you everything you need to evaluate it — no black box, no guesswork:
Security score — an at-a-glance indication of the skill’s overall safety
Vetting details — how the skill was assessed before being listed
Operation flow chart — a visual walkthrough of what the skill does and how it works
Use cases — real examples of where the skill applies
Prerequisites — what needs to be in place before you run it
Compatibility — which environments, agents, and tools it works with
Putting Skills into Practice
Discover. Go to Prime Architect > Agentic Threat Research > Agentic Skills.
Browse the library by NIST Cybersecurity Framework, or check “For You” and “New” for recommendations and recent releases.
Evaluate. Open a skill’s details page for its flow diagram, when-to-use guidance, prerequisites, a worked example, security score, and compatibility.
Not ready to use? Bookmark it for later.
Install. One click adds it to your skills, ready to use in your workflow. Installed skills auto-update, so you always run the latest, most accurate version with zero manual maintenance.
Take it with you. Generate a ZIP package containing the skill’s SKILL.md file — useful for storing it locally or running it with a compatible external agent or platform.
Use it. In Prime Architect chat, add the installed skill to your message any of three ways:
Click the + icon and select Add Skills, then pick a skill
Type / to search by skill name or description and select the skill from the list
Click the Agentic Skills button above the chat input, then pick a skill
Pair it with your own prompt, a file, or a detection for context, then send — the agent follows the skill’s instructions to produce the output.
The marketplace doesn’t sit in isolation — it’s also connected directly to Active Threats in Prime Core. When you’re exploring a specific threat, relevant agentic skills surface automatically, right alongside the investigation. Instead of leaving your threat research to go hunt for the right skill, the skill finds you at the moment you need it — keeping analysis and action in the same flow.
Experience the Marketplace
This isn’t meant to be another catalog layered onto an already crowded security stack. It’s built to make it easier to find useful skills, understand what they actually do before adopting them, and bring them into existing workflows with real confidence instead of guesswork.
Pega patched a SAML authentication bypass in Pega Platform, rated Critical 9.5 and High 7.0. No CVE, no known compromise. See affected versions and fixes.
The Department of Telecommunications (DoT) Madhya Pradesh, India LSA has cautioned citizens against fraudulent SIM cards, misuse of telecom identifiers and tampering with IMEI numbers, warning that such violations can carry serious legal consequences under India’s Telecommunications Act, 2023.
The advisory follows recent cybercrime investigations that uncovered instances of unauthorized SIM activation. In one case, a Point of Sale (PoS) agent in Chhattisgarh was found to have illegally activated 25 mobile connections using citizens’ identification documents without their knowledge or consent.
Following the discovery, the DoT and telecom service providers blacklisted the concerned PoS agent, preventing it from issuing mobile connections in the future.
DoT Investigates Fraudulent SIM Cards and Mobile Connections
The 25 mobile connections linked to the case were examined through the Digital Intelligence Platform, or DIP, operated by the DoT. Connections identified as suspicious were subjected to re-verification.
Numbers that failed the re-verification process were subsequently deactivated.
The action highlights concerns around SIM card fraud, particularly where mobile connections are obtained or activated using another person’s identity documents. The DoT has also cautioned citizens against transferring SIM cards registered in their names, as legal liability may extend to the original subscriber if the connection is later misused.
Telecommunications Act 2023 Sets Penalties
The DoT said fraudulent issuance of SIM cards, misuse of telecom identifiers and tampering with IMEI numbers are punishable offences under the Telecommunications Act 2023.
Such violations may attract imprisonment of up to three years and fines of up to ₹50 lakh.
The department has urged citizens to avoid obtaining SIM cards through fake documents, fraud, cheating or impersonation. It has also warned against procuring SIM cards in their own names and subsequently transferring, renting, loaning or otherwise providing them to others for misuse in cyber fraud or other unlawful activities.
Citizens have also been advised not to use devices such as modems, modules or SIM Boxes with configurable or tampered IMEI numbers.
IMEI Numbers and Telecom Identifiers Under Scrutiny
The DoT has highlighted the misuse of telecommunications identifiers, including the International Mobile Equipment Identity, or IMEI numbers, as a security concern.
Citizens have been cautioned against using mobile applications, websites or other methods to modify Calling Line Identity (CLI) or other telecommunications identifiers. The department has also warned against using devices with tampered IMEI numbers.
According to the advisory, misuse of SIMs and telecom identifiers can affect citizen safety and pose risks to the security and integrity of telecommunications networks.
Sanchar Saathi Enables SIM and Device Checks
The DoT has advised citizens to regularly use Sanchar Saathi to verify mobile connections issued in their names and block numbers that are unnecessary or not genuinely theirs.
The Sanchar Saathi platform also provides a facility called “Check Genuineness of Your Mobile handset,” which allows users to verify IMEI numbers and associated device information. The service can provide details including the handset’s brand name, model name and manufacturer information.
Citizens can access the Sanchar Saathi services through its portal or mobile application to check and secure their mobile connections and devices.
The DoT has urged citizens to remain vigilant and avoid sharing SIM cards registered in their names, particularly where the connection could later be used for cyber fraud or other unlawful activities.
We're excited to announce Intelligence Center 3.9, a release focused on giving you more flexibility in how you work with AI, and keeping your threat intelligence aligned with the evolving industry standards.
Anyone who has worked on SOC and SIEM projects long enough has watched the same decision play out in budget meetings again and again. Security teams are pushed into a choice that has nothing to do with security engineering and everything to do with invoices.
Option one: drop log sources. Cut DNS. Cut endpoint process telemetry. Cut cloud audit trails, or sample them down to something the license can absorb. The team survives the budget, and the detection surface quietly shrinks. Every dropped source is a blind spot that an adversary does not have to work around, because it was never watched in the first place.
Option two: keep everything. Stream raw telemetry into SIEMs, Data Lakes, and AI agents, and accept that the bill grows in direct proportion to how much the business logs. Cloud migration, Kubernetes, identity providers, SaaS sprawl — every one of them adds volume, and none of them asks whether the security budget grew this year.
Neither option is a strategy. They are both consequences of the same architectural assumption: that detection happens after storage. That assumption is now the single largest cost driver in the modern SOC, and it is the one we set out to remove.
Today we can share validated ROI on a third approach: putting a full threat detection engine inside the data pipeline, before the expensive tiers ever see the data.
SOC Prime Detect evaluates 100% of your streaming telemetry at wire speed. Not a sample. Not a filtered subset chosen by a cost-control rule six months ago that nobody has revisited since. All of it, as it moves.
It does this by applying curated Sigma logic at the pipeline layer — the transport stage between your collectors and your destinations. Three things follow from that placement:
Tier 1 — noise reduction. Prime Detect filters out 93% of raw log noise before it reaches a paid destination. Successful routine authentications, chatty process telemetry, health checks, the enormous background hum that every enterprise environment produces and no analyst has ever opened. The events are evaluated against detection logic first, then discarded or routed cheaply, rather than being paid for at premium ingest rates on the chance they might matter later.
Tier 2 — correlation. Isolated matches are not detections. Prime Detect uses Sigma Correlations, expressed as Higher Order Sigma rules, to assemble individual matches into attack chains across sources and across time. This is where a single suspicious LDAP query and an unusual service creation stop being two low-confidence events and become one high-confidence sequence.
Tier 3 — signal delivery. What reaches the top of the stack is compressed down to 7 PPM — 0.000007 of the original stream. That is the material handed to Tier 3 AI agents: seven events per million, already correlated, already contextualized, already worth reasoning about.
The key point is that nothing is discarded before it is examined. Traditional cost control drops data blind. Prime Detect inspects everything and forwards only what earns its place downstream.
The numbers, as measured with Enterprise customers
The table below shows validated savings across ingest volumes from 100 GB/day to 10 TB/day, broken out by where the cost lands in the stack.
Three separate cost lines are worth reading carefully, because they behave very differently.
SIEM and Data Lake savings are the most familiar. They scale linearly with volume and they are the ones most security leaders already track. At 1 TB/day, a 93% reduction in what reaches the paid tier is worth roughly a million dollars a year. At 10 TB/day it is worth ten.
Cloud AI savings are where the arithmetic becomes genuinely uncomfortable for anyone planning an AI SOC. Token costs scale with the volume of text a model is asked to read. Pointing an LLM at raw telemetry means paying for every heartbeat and every successful login, at inference prices, forever. The gap between reasoning over a raw stream and reasoning over a 7 PPM signal is the difference between a line item and an impossibility. At 1 TB/day, that difference is $136.8M a year.
GPU hardware savings apply to teams running models on their own infrastructure. The saving is smaller in absolute terms but structurally important: it changes what you have to buy up front. A detection strategy that requires a GPU farm before it produces its first alert is a strategy most organizations will never get funded.
What this means for your stack
1. Stop letting ingestion volume dictate your security strategy. Downstream software, hardware, and AI fees can be cut by up to 93%. More importantly, the decision about which log sources to keep goes back to being a detection engineering decision rather than a procurement one. Coverage stops being rationed.
2. Enable continuous detection across 100% of unparsed logs. Detection at the pipeline layer does not depend on a source being normalized, mapped, and onboarded first. Sigma rules run against the stream as it arrives, which means new sources contribute to detection on day one rather than after a parsing project. It also sidesteps a constraint that quietly caps many mature programs: SIEM rule execution limits. Teams routinely retire working rules to make room for new ones. Moving evaluation into the pipeline removes that ceiling, and it does so without burying analysts or detection engineers under additional alert volume — because correlation happens before delivery, not after.
3. Run autonomous AI SOC agents on high-fidelity attack chains. AI agents are extremely good at reasoning over structured, correlated evidence and extremely expensive when asked to sift raw noise. Feeding them a correlated 7 PPM signal is what makes autonomous triage economically viable without a million-dollar token budget or a server room full of GPUs.
Why Sigma, and why the pipeline layer
Two design choices do the heavy lifting here, and both are deliberate.
Sigma is an open, vendor-neutral detection format with a large and actively maintained public body of logic behind it. Using curated Sigma logic at the pipeline layer means detection content is portable: it is not locked to the query language of whichever platform you happened to buy, and it does not need rewriting when a destination changes. The content your team writes and the content the community publishes run in the same place, against the same stream.
Sigma Correlations extend that model from single-event matching to sequence and threshold logic. Higher Order Sigma rules are what let the pipeline decide that a cluster of individually unremarkable events constitutes an attack chain worth escalating — and, just as importantly, that a matching event with no surrounding context does not.
The pipeline layer matters because it is the only place in the architecture where every event is guaranteed to pass through exactly once, in motion, before any storage or compute cost has been incurred. Detection there is not a cheaper version of what the SIEM does. It is the same work done at the one point where it is still free to do it.
See it for yourself
The trade-off between coverage and cost was never a law of nature. It was an artifact of where detection happened to sit in the stack. Move detection upstream, into the pipeline, and both sides of that trade-off improve at once: more of your telemetry gets examined, and less of it gets paid for twice.
If you want this ROI for your own security stack, get in touch — or view a live demo of how Prime Detect works. No strings attached.
The first hit is access. I have talked with technology leaders whose teams had a working model but could not secure the capacity to operate it at production scale on the economics they had forecast. The available capacity sat outside the assumptions behind the existing agreement, and market pricing had moved well beyond the budget. As CIO.com has reported, AI is exposing the limits of enterprise cloud strategies created before these workloads became material.
Data movement creates another problem. AI workloads may cross regions or providers in search of an available GPU or a better price on a particular chip. I have seen finance teams confront cloud bills that ran well beyond forecast because data had to leave one cloud to reach compute available in another. The increase had nothing to do with headcount or a wave of new applications. It came from an architecture assembled around capacity rather than cost.
Egress pricing also changes the economics of portability. Consolidating with one hyperscaler may simplify operations, but it can become expensive to change course when the provider cannot supply the right capacity in the right place. By the time the CIO needs alternatives, the cost of moving data may have weakened the negotiating position.
Then the question reaches the board: What will AI cost next year? Some CIOs cannot answer with confidence because the contract and cost model were built around a different workload. That is more than a forecasting problem. It tells the board that the company has committed to an AI roadmap without understanding the infrastructure economics beneath it.
What prepared CIOs are doing differently
The CIOs in the best position separated AI economics from the rest of the cloud estate before returning to a provider. They stopped defending cloud spend as one number and accounted for training and inference by workload, region and chip. That work gave them something far more useful than another high-level forecast: evidence they could negotiate from.
Some have resisted the usual pressure to consolidate everything with one hyperscaler. They have kept selected AI workloads portable across providers or moved GPU-heavy training to specialized infrastructure companies. Portability carries its own engineering and governance costs, so it is not automatically the right answer. But a credible ability to move a workload creates leverage that a cloud strategy built around dependence cannot.
The contract requests have changed as well. CIOs are asking for guarantees tied to named chip types, shorter terms for volatile AI capacity and the ability to rebalance spend categories as the workload mix changes. One structure is a reserved allocation for a specific GPU generation rather than a general compute credit. Another is a shorter AI-specific commitment layered over a longer agreement for the general-purpose estate. The two workloads do not have to be forced into the same planning horizon.
The work should start before the provider puts a proposal on the table. Once the negotiation has been reduced to a renewal number and a discount percentage, the most important assumptions have already escaped scrutiny.
Start with the workload rather than the existing agreement. Which AI use cases are expected to reach production during the next term? Which require training, which rely mostly on inference and which can use a managed model without dedicated GPU infrastructure? Those distinctions determine whether the company needs reserved capacity, flexible consumption or no direct GPU commitment at all.
Then test the location assumptions. Where does the underlying data reside? What residency or sovereignty rules limit where it can move? If the preferred capacity is available only in another region or from another provider, calculate the transfer, egress and operational costs before calling that option cheaper. A lower compute rate can disappear quickly when the data has to travel to reach it.
Capacity and discounts also need to be separated. A favorable price does not guarantee that the required chip will be available when a production workload needs it. Conversely, a capacity reservation can protect access while creating a cost for infrastructure the company does not fully use. The CIO needs both numbers: the economics of consuming the capacity and the economics of holding it.
Finally, decide what must remain portable. Full multi-cloud portability is expensive and often unnecessary. But there may be a small number of high-cost AI workloads where dependence on one provider creates more risk than portability costs. That is where an alternative architecture can become negotiating leverage rather than an abstract cloud principle.
None of this requires treating the original agreement as a mistake. It was often a reasonable decision based on the company’s workload at the time. What has changed is the cost of leaving it unexamined.
A three-year cloud agreement cannot be treated as a three-year suspension of judgment. Before the next renewal, test the commitment against the workload the company is actually running, not the company it was when the agreement was signed.
Every intrusion involves more than just malware or a compromised IP — it involves a threat actor, the tools they wield, the infrastructure they operate through, and the victim they target. Understanding how these elements connect is often more valuable than looking at any one of them in isolation. That’s why Prime Architect visualizes adversary activity using the Diamond Model — generated automatically as part of Deep Threat Research analysis, helping your team see not just what happened, but how the pieces of an intrusion relate to one another.
Mapping the Four Corners of an Intrusion
The Diamond Model of Intrusion Analysis is a threat intelligence framework built on a simple premise: every malicious event can be broken down into four core elements, and mapping the relationships between them reveals far more about an adversary’s operation than examining indicators in isolation. Rather than a flat list of IOCs, the model gives analysts a structural view of the intrusion itself.
The Diamond Model displays four vertices, each representing a core element of the analyzed threat:
Adversary — the threat actor or organization behind the activity
Capability — the tools, malware, and techniques the adversary used
Victim — the targeted entities or organizations
Infrastructure — the systems, resources, and services used to carry out the activity
In Prime Architect, the Diamond Model visualizes these four vertices based on the entities actually extracted from the analyzed threat report, and each vertex displays the number of extracted entities associated with it — giving you an immediate sense of how much detail was found for each element of the intrusion.
Reading the Connections
A diamond isn’t just four points — it’s the relationships between them that tell the real story. The diagram represents connections between vertices using directional relationships, including Connects To, Uses, Exploits, Targets, Develops, and Deployed via. These directional links show, for example, which capability an adversary used to exploit a specific victim, or which infrastructure was used to deploy a given tool.
Hovering over a vertex highlights it and reveals its related connections, making it easy to trace how a threat actor’s tools, targets, and infrastructure tie together — without having to manually cross-reference a written report.
An Extracted counter in the diagram shows the total number of entities identified during the analysis, giving you a quick sense of scale.
To dig into specifics, click any vertex to view the corresponding entity list below the diagram — so you can move seamlessly from the high-level relationship map to the underlying details.
The diagram also includes meta-features — Phase, Result, Direction, Methodology, and Confidence — which add crucial context around the analyzed activity, such as where in the intrusion lifecycle the activity occurred, whether it succeeded, and how confident the analysis is in the mapped relationships.
From Visualization to Action
1. Attribution and actor tracking By consistently mapping adversaries to their capabilities and infrastructure across multiple analyzed reports, teams can spot overlapping patterns that support attribution to a known threat actor or campaign.
2. Infrastructure and tooling analysis Seeing which infrastructure supports which capabilities helps defenders anticipate an adversary’s next move — if you’ve identified the infrastructure behind one campaign, related activity becomes easier to detect.
3. Victim profiling and risk assessment Understanding who adversaries typically target, and through what capabilities, helps security teams assess whether their own organization fits a known targeting pattern.
4. Structured incident storytelling The four-vertex structure makes it easy to explain an intrusion to stakeholders in clear terms: who did it, how, through what, and against whom — without digging through technical specifics.
5. Confidence-driven prioritization The Confidence meta-feature helps analysts weigh how much trust to place in a given relationship, so response and remediation efforts can be prioritized around well-supported findings rather than speculative ones.
How to Generate It
Open Prime Architect and go to the Agentic Threat Research mode.
Click Code Editor in the upper-right corner and paste the text of your threat report.
Select Analyze.
Choose Deep Threat Research from the list.
Click the Enter icon to run the analysis.
The Diamond Model then appears alongside other outputs, giving your team a structural, relationship-driven view of the threat — one that connects the adversary, their capability, their infrastructure, and their victim into a single, coherent picture.
Not all indicators of compromise are created equal. A malicious IP address can be swapped out in minutes; an adversary’s core tactics, techniques, and procedures take months — sometimes years — to rebuild. That’s why Prime Architect visualizes threat indicators using the Pyramid of Pain — generated automatically as part of Deep Threat Research analysis, helping your team focus detection efforts where they actually hurt the adversary.
The Model Behind the Visualization
The Pyramid of Pain threat intelligence framework ranks indicators of compromise not by how easy they are to find, but by how much disruption they cause an adversary when detected and blocked. The underlying logic is simple: some indicators are trivial for attackers to change, while others sit at the core of their operational identity — changing them requires real cost, time, and retooling.
The Pyramid of Pain categorizes threat indicators into six levels, arranged from the base of the pyramid (low pain) to the top (high pain):
Hash Values — trivially easy to change; a single byte modification produces a new hash
IP Addresses — easy to rotate, especially with cloud infrastructure or proxies
Domain Names — somewhat harder to change, but still replaceable with moderate effort
Network/Host Artifacts — patterns left behind by tools or activity, requiring more rework to avoid
Tools — the utilities and malware an adversary relies on; replacing them takes real development effort
Tactics, Techniques, and Procedures (TTPs) — the adversary’s actual behavior and tradecraft; the hardest and most costly element to change, since it’s tied to how they operate at a fundamental level
In Prime Architect, the Pyramid of Pain visualizes these six tiers based on the indicators actually extracted from the analyzed threat report, giving your team an immediate, ranked view of what was found — and, more importantly, how much of it truly matters.
What’s Really Happening at Each Tier
Each tier in the pyramid isn’t just a category — it’s a signal about strategic value. A report full of hash values and IP addresses may look rich in indicators, but if it’s light on TTPs, the actionable intelligence is thinner than it appears. Conversely, indicators found near the top of the pyramid represent durable insight into how the adversary operates, which stays relevant even after they change infrastructure.
The panel on the right of the visualization displays the number of indicators extracted for each tier alongside its corresponding pain level, so you can see at a glance whether your intelligence skews toward easily-replaced artifacts or toward high-value behavioral detail.
To review indicators by category, simply click the corresponding pyramid tier — the list of indicators associated with that tier appears directly below the pyramid.
In the upper-right corner, a total extracted indicators count shows the overall number of indicators identified during the analysis — giving you a quick sense of scale before diving into specifics.
From Visualization to Action
1. Prioritizing detection engineering Teams can use the pyramid to decide where to invest detection effort. Detections built around TTPs and tools remain effective far longer than those built solely around hashes or IPs, which adversaries can bypass with minimal effort.
2. Assessing intelligence quality A quick glance at tier distribution tells you whether a threat report offers durable strategic value or just short-lived tactical indicators — useful for triaging which reports deserve deeper investigation.
3. Threat hunting Higher-tier indicators — Network/Host Artifacts, Tools, and TTPs — make excellent starting points for proactive threat hunts, since they’re far less likely to have changed since the report was published.
4. Communicating impact to leadership The pyramid’s intuitive “pain” concept makes it easy to explain, in non-technical terms, why certain detections are more valuable and durable than others.
5. Long-term adversary tracking Because TTPs are the hardest element for adversaries to change, tracking them across multiple analyzed reports helps identify recurring behavior tied to the same threat actor or campaign, even as their infrastructure shifts.
How to Generate It
Open Prime Architect and go to the Agentic Threat Research mode.
Click Code Editor in the upper-right corner and paste the text of your threat report.
Select Analyze.
Choose Deep Threat Research from the list.
Click the Enter icon to run the analysis.
The Pyramid of Pain then appears alongside other outputs, giving your team a complete, multi-angle view of the threat and its most durable indicators.
Understanding how an attacker moves through your environment matters just as much as knowing that they got in. That’s why Prime Architect’s Agentic Threat Research module visualizes attacks using the Cyber Kill Chain — generated automatically as part of Deep Threat Research analysis, giving your team a clear, stage-by-stage map of adversary behavior built directly from the threat report you provide.
Understanding the Framework
The Cyber Kill Chain is a model developed by Lockheed Martin that describes the sequence of stages an attacker moves through during a successful intrusion. The concept borrows its name from military terminology — a “kill chain” describes the structure of an attack, from target identification to engagement — and was adapted for cybersecurity to structure the full lifecycle of an attack, from initial reconnaissance to the achievement of the adversary’s ultimate objective.
The core value of the Lockheed Martin Cyber Kill Chain lies in a simple but powerful idea: an intrusion is not a single event, it’s a chain of dependent steps. If defenders can detect or disrupt the attacker at any link in that chain, the entire intrusion can be stopped before real damage occurs. This reframes defense from “prevent every possible attack” to “break the chain at the weakest link the attacker depends on” — a far more achievable and measurable goal.
The Cyber Kill Chain includes seven stages, each representing a distinct phase of the intrusion lifecycle:
Reconnaissance — the attacker researches and identifies potential targets
Weaponization — a malicious payload is crafted or configured
Delivery — the payload is transmitted into the target environment
Exploitation — a vulnerability is triggered to achieve code execution
Installation — the attacker establishes persistence
Command & Control — a communication channel is established with the compromised system
Actions on Objectives — the attacker achieves their ultimate goal (data theft, disruption, destruction, etc.)
In Prime Architect, the Cyber Kill Chain visualizes these seven stages against the specific behavior of the analyzed threat, so instead of reading a dense narrative report, analysts can instantly see where a given threat sits within this widely recognized framework. Each stage is interactive — clicking it reveals its role in the chain and the typical adversary tradecraft associated with it, in the context of the threat being analyzed.
Putting the Framework to Work
1. Gap analysis and threat coverage assessment By mapping a threat’s observed behavior onto the kill chain, teams can immediately see their threat coverage — which stages are well-monitored and which represent blind spots. This turns a static report into an actionable defense-planning tool.
2. Detection engineering prioritization Knowing exactly which stage lacks visibility helps detection engineers prioritize new rules and analytics where they’ll have the most impact, rather than building detections evenly (and inefficiently) across the entire attack surface.
3. Incident response and triage During live investigations, mapping observed indicators to a kill-chain stage helps responders quickly estimate how far an intrusion has progressed — informing urgency and containment strategy.
4. Security awareness and reporting The visual, stage-based format makes it easier to communicate attack narratives to non-technical stakeholders and leadership, since the model is an industry standard many already recognize.
5. Control investment justification Recurring gaps at the same stage across multiple analyzed threats can justify budget for specific control investments (e.g., email filtering for Delivery, EDR for Installation).
How to Generate It
Open Prime Architect and go to the Agentic Threat Research mode.
Click Code Editor in the upper-right corner and paste the text of your threat report.
Select Analyze.
Choose Deep Threat Research from the list.
Click the Enter icon to run the analysis.
The Cyber Kill Chain then appears alongside other outputs, giving your team a complete, multi-angle view of the threat.
Entrar
