Primod 2026.10.0: See the Request, the Code and the Cloud Behind Every Attack

Today we release Primod 2026.10.0, and I am very excited to share it with you. For months our team worked on this release day and night, and we are very proud to see it come to life. With it, Primod moves beyond vulnerabilities and misconfigurations to threat detection and traffic visibility. For the first time, we can show the whole story of an attack: the request that started it, the code that ran and the cloud it can reach.

Meet Primod CADR

An alert fires: a shell started inside a container in production. Your EDR has done its job. It saw the process on the host.

Now the real questions start. Which HTTP request started it? Which library, which function, which line of code? Is that vulnerable code something you knew about? And what can this workload reach in your cloud: which roles, which buckets, which databases?

Today those answers live in five tools. Over the last three months we built them into one.

Cloud Application Detection and Response (CADR) watches your applications where they run, in Kubernetes and on Docker hosts. It connects every event into one chain:

HTTP request
Workload
Function that ran
Process and syscall
Cloud identity
Data in reach

EDR protects your hosts and endpoints, and you should keep it. CADR is the layer above it, built for cloud applications. Here is what we shipped.

The runtime picture: the packages and CVEs on disk, the functions that ran, and the cases they led to.

Theme 1

Catch the attack

Detection Built on Behavior

Primod's sensor uses eBPF to watch what your workloads do at the kernel level, with no code changes. Detection rules look for behavior, not for tool names: container escapes, new persistence through cron, systemd or SSH keys, reverse shells, curl | sh downloads, and requests to the cloud metadata service. Every detection maps to MITRE ATT&CK, and the dashboard shows the tactics you face as a matrix you can click.

Runtime detection is now part of every Primod plan, Free included.

Click a technique on the ATT&CK matrix, and the incidents open already filtered by it.

Detection for AI Agents

AI agents now run code in production, and a prompt injection turns the model's output into an action on your host. Primod reads the call stack behind every process start, file read and connection, so it knows when the code that acted was an agent's tool call or a model loader. It detects five behaviors, each mapped to the OWASP Top 10 for LLM Applications and to MITRE ATLAS, the ATT&CK of AI systems:

A tool call starts a shell or a network tool such as curl or nc (OWASP LLM05, LLM06).
A tool call reads a credential file: cloud keys, a kubeconfig, a service account token, SSH keys or a .env file (OWASP LLM02, LLM06).
A tool call reaches for cloud credentials through the metadata service (OWASP LLM06).
A model file opens a network connection while it loads (OWASP LLM03).
A model file starts a process while it loads (OWASP LLM03).

Primod recognizes tool calls in LangChain and LangGraph, LlamaIndex, the OpenAI Agents SDK, MCP servers in Python and C#, Spring AI, LangChain4j, Semantic Kernel and Microsoft.Extensions.AI, and model loads in PyTorch, scikit-learn (joblib) and NumPy.

One Case per Attack

Alert queues fill up because one attack fires many alerts. Primod groups detections that share a process tree into one attack, and gives each rule on each workload one case. Your team sets the status, the owner and the verdict (true positive, false positive, or benign activity) once, with a note and a full history.

The queue by triage state, then one case: set its status and add a note, once for the whole attack.

Evidence, Already Attached

Open a case and the investigation is already done. You see:

the HTTP request that triggered the detection
the call stack and the process tree, side by side, with each syscall in plain words
the commands with their arguments, and every connection with its Kubernetes name
the indicators of compromise, ready to copy
the workload's context: its posture, its exposure, and the cloud role of its node
a supertimeline of container activity, and whether the processes kept running afterwards

The intrusion graph draws the whole execution path, from the caller to the syscall to the target. The misconfigurations and vulnerabilities of that workload show up as objects on the same graph.

The request, the function pipeShell and the shell it started, then the call stack next to the process tree.

Theme 2

Fix what actually runs

Software Composition Analysis on Every Node

Primod scans every container image on the node where it runs. No registry access is needed, and images are rescanned every 24 hours. It covers OS packages and the main language ecosystems, including Go, Java (Maven), npm, Python (PyPI), .NET (NuGet), Ruby, Rust and PHP. Host kernel CVEs are shown apart from image CVEs, because the kernel belongs to the node, not to your image.

Go
Java
npm
Python
.NET
Ruby
Rust
PHP

Runtime Reachability: the CVEs That Ran

A scanner lists every CVE on disk. Most of that code never runs. Primod watches which functions actually execute in production and matches them to the vulnerable function of each CVE, by its full type-qualified name, against the package version in the image.

The result is a funnel: total packages → CVEs on disk → function executed → fix available. You can try it yourself in the Primod demo workspace: 9,206 packages carry 2,690 known CVEs, but the vulnerable function actually ran for only 10 of those CVEs (12 findings), and 10 of the findings already have a fix.

Each finding has a lifecycle (active, fixed, removed), so you can report what you fixed, what is new, and what went away.

The funnel, then a Tomcat function that ran in a live request, and the stack frame that triggered it.

Theme 3

See how your apps talk

An EDR sees the processes on a host. Primod also sees the application on it: which service calls which, over which protocol, and what each service is.

Your Services and Their Traffic

The traffic map draws who calls whom in each cluster and on each Docker host, from live traffic. Each call shows its protocol, request rate, p95 latency and error rate. Select a service to see the routes it serves with their status codes, and every peer it talked to, with new connections marked.

Search the HTTP request log over 30 days in seconds, for example GET */.env* or status:5xx, and see the real client behind your load balancer.

A Go service, the PostgreSQL and ClickHouse calls it makes, the routes it serves, and the outside services it calls.

Apps That Name Themselves

You do not tag anything. Primod works out what each service is from the evidence in its traffic: the protocol, the container image, the domain it calls, its name and its language. It recognizes 300 products this way. Inside your cluster, that means databases, queues, gateways, identity and observability tools. Outside it, that means services from OpenAI, Anthropic and Gemini to Stripe and Sentry. Each one shows with its logo, and its details say which evidence named it.

Search by product, not by host name: "gemini" finds generativelanguage.googleapis.com, and "redis" finds Valkey. Pick a product, and the map keeps only the services that talk to it. In one click, you see which workloads send data to an AI model provider.

Theme 4

See the whole cloud

Google Cloud Joins AWS and Azure

Connect your Google Cloud projects and Primod scans them on a schedule, maps them into the security graph, and checks them against CIS Google Cloud benchmarks. The graph resolves who can do what: project, bucket and service account role bindings, custom roles, public access, and the impersonation routes that let one identity act as another.

From the Internet to admin-vm: an Internet-exposed workload with admin or escalation rights.

New Compliance Benchmarks

New this quarter: CIS Google Cloud 3.0 and 5.0, PCI DSS 4.0.1 for Google Cloud and Azure, and Primod's identity benchmark (CIEM) for Google Cloud. PCI DSS 4.0.1 for AWS now follows AWS's own published control mapping.

The full list covers AWS Foundational Security Best Practices, CIS AWS 1.2 to 5.0, CIS Azure 2.1, CIS Google Cloud 3.0 and 5.0, PCI DSS 4.0.1 for all three clouds, and CIEM for all three. The newest version of each benchmark comes first.

Frameworks compared, lowest score first, then the CIS Google Cloud 5.0 report and its failing controls.

Misconfigurations in One Place

The posture section is new: one scope selector across your accounts, subscriptions and projects. A control that several frameworks report is listed once, and every control shows its status over time. Kubernetes misconfigurations get the same treatment, grouped by control.

Attack Graphs for Your Cloud

The security graph opens on your top issues, each drawn as a path that starts at the Internet. Examples: an Internet-facing workload with vulnerable code that ran, a role anyone can assume, an identity that can make itself admin, or instance credentials a workload can reach through the metadata service. Ask questions such as "Which data can the Internet reach?" or "Who can become admin?", and start from any resource to see what it reaches and who reaches it.

For AWS and Google Cloud, the graph resolves effective permissions. On our own AWS account, it agreed with AWS's IAM policy simulator on all 3,422 unconditional permission checks we compared.

From the Internet to a load balancer: its Internet exposure, and what it can reach.

Clusters You Forgot About

Primod lists every EKS, GKE and AKS cluster that your cloud integrations find, next to the sensor status of each: no sensor, sensor silent, or protected. Clusters without a sensor come first, with a link to set one up.

Theme 5

Run it your way

Kubernetes or Plain Docker, One Command

Install the sensor on Kubernetes with one kubectl command, or on a plain Docker host with one curl | sh and Docker Compose. Docker hosts get the same features: the workload and traffic maps, vulnerabilities with host, container and binary, and detections.

One command for a Docker host, one for Kubernetes.

Sensor Health

A new fleet page shows every sensor installation, every node and every component, with its status and, when something fails, the reason and the time.

The fleet summary, then each node, then each of its 31 components.

Faster, Everywhere

We rebuilt the slowest reads in the product. On our staging data, the CVE drawer went from 144 seconds to under 1.4 seconds, the incident list from 6.3 seconds to 31 milliseconds, and a 30-day request search now takes 0.4 to 3 seconds.

A Versioned REST API

The new versioned REST API has 34 operations, 10 scopes, an OpenAPI document, a reference, and a playground inside the product. Keys are hashed and shown only once.

API keys, each with its own scopes and MCP switch. Then the API reference, with a ready curl example for every operation.

An MCP Server for Your AI Assistant

The Primod MCP server lets Claude or any MCP client ask Primod questions in plain language, such as "Summarize this week's open incidents and their evidence." Switch it on per API key. It has 13 read-only tools and cannot change anything.

Claude Code asks Primod about an AI agent incident. Seven read-only tool calls later: where it happened, what happened, and what to do now.

Audit Log (Enterprise)

Every change through the console or the API is recorded, with logins and organization switches. Filter by actor, action and outcome, export to CSV, or forward it to your SIEM through the API.

Certified for Red Hat OpenShift

The Primod sensor is now Red Hat certified. Its two container images, the runtime sensor and the gateway collector, passed Red Hat's certification for OpenShift and are listed in the Red Hat Ecosystem Catalog. If you run OpenShift, you install Primod from images that Red Hat tested against its criteria and scans for vulnerabilities continuously.

Your turn

See it for yourself

Try Primod 2026.10.0

We built this release around one belief: an alert should come with the whole story, not only its last step. With Primod 2026.10.0, that story starts at the HTTP request and goes through the code that ran to the cloud the workload can reach.

Everything in this post is live in the Primod demo workspace. Open a case and follow the attack, trace a request through the traffic map, or ask the attack graph what the Internet can reach. No sign-up is needed.

When you are ready, install the sensor on your own cluster or Docker host with one command. Runtime detection is part of every plan, Free included. And if you want us to walk you through it, or you have something you want us to build next, talk to us. We would love to hear from you.

Weekly email

Runtime Evidence

One email a week: a runtime finding worth understanding, how it was investigated, and what to check in your own clusters. No product pitches in disguise; unsubscribe in one click.