Two new connectors, for SAP API Management and Traefik, plug Wallarm into more of the platforms that already front your APIs. Their traffic gets inspected right where it flows, and the APIs behind it land in the same Console as the rest of your estate.

These connectors are for one situation: your APIs sit behind SAP API Management or Traefik, and you want Wallarm working at that gateway. If your current deployment already sees that traffic, you're set. Carry on.

What's new

SAP API Management

Protect the APIs you publish through SAP API Management. Wallarm inspects their traffic at the gateway, so the attacks against those APIs, and the APIs themselves, show up in the Console you already use. Run it inline to block malicious requests before they reach your backend, or out of band to inspect copies of the traffic without adding a millisecond to response time.

Traefik

A Wallarm middleware plugin for Traefik 2.x and 3.x in Kubernetes. No sidecars, no traffic mirroring. Requests route through a Wallarm node you host, so inspection and enforcement stay on infrastructure you control.

Same detection, same inventory

Traffic through either connector feeds the same attack detection and API Discovery as the rest of your deployment. There's no new dashboard to learn. Attacks show up in Attacks, and the APIs show up in API Discovery, right where you'd look for them.

Your detection hasn't changed. What's changed is where you can put it.

Learn more in the SAP API Management connector and Traefik connector documentation, or see all Wallarm connectors.

Attack traffic can create a lot of noise. Incidents represent the signal.

An incident is an attack that hit a real security issue in your application and got a response proving it worked. The new Incidents page puts that signal in the same interface you already use for Attacks. The attacks that matter most now get the same investigation flow as everything else.

There's nothing to install and nothing to migrate. The new page shows up in your dashboard automatically.

Only confirmed incidents appear here. If it's on this list, it got through.

What's new

A dashboard for what got through
See requests with incidents over time. Alongside the chart you get the top source IPs, endpoints, hosts, attack types and subtypes behind them, plus a breakdown of the response codes your application sent back.

A month of incidents, and who and what was behind them.

Grouped the way you investigate
Incidents are grouped by attack type, then HTTP method, domain, path, and the parameter the payload landed in. Open any level to drill down, all the way to individual requests.

The exact attack that became the incident
One request can carry several attack payloads, and usually only some of them hit a vulnerability. The request details now mark the one that raised the incident, so you don't have to guess which payload did the damage.

One incident, 120 requests, and the RCE payload flagged with the vulnerability it exploited.

Severity on every row
The Security Issues column shows the severity and state of each linked issue. If something is critical and still open, you'll see it without clicking in.

Shareable views
Your filters and time range live in the page address. Reload, bookmark, or drop the link in a ticket, and the same view opens for whoever clicks it.

Export
Export the incidents in your current view, filters included, for incident response or reporting.

Links into Incidents from the Threat Prevention dashboard and from Security Issues now open the new page.

Your detection and your security issues haven't changed. What's changed is how fast you get from "something got through" to the exact request that did it.

Learn more in the Incidents documentation.

Your WAF rules just got a lot easier to read. Same rules, same enforcement, new interface.

There's nothing to install and nothing to migrate. Your existing rules carry over exactly as they are, and the new interface shows up in your dashboard automatically.

Rules are where Wallarm's detection depth becomes yours to direct. A rule can target any part of a request, including a value buried deep inside a nested payload. The problem was never what rules could do. It was seeing what they covered without opening them one at a time. That's what we fixed.

What's new

Every rule type in one view
Browse all of your rule types from a single panel instead of clicking through a tree of hosts and paths. Pick a type to narrow the list, or look at everything at once. Each view has its own address, so you can bookmark a filtered list or send it to a teammate.

Every rule type, right from the start.

Visible request targeting
You can now see the exact part of the request each rule applies to, right in the list. A rule might point at a value several layers deep: a field inside a JSON object, inside a Base64 segment, inside a JWT, inside a request header. The full path shows up on the row. So the next time someone asks which of your parameters a rule covers, you can just look.

Filters for applications and scope
Narrow the list to specific applications, or separate the rules Wallarm creates and manages for you (marked Default, and not editable) from the ones your team built. Filters live in the address bar, so your view survives a reload.

Rule management in the list
Enable or disable a rule without deleting it, duplicate one as a starting point for the next, and clear out the ones you don't need anymore. All from the list, with endpoints, applications, and last updated on every row.

Creating a rule works the same way. You build the target one step at a time, choosing from the options that are valid at each step.

Cookie → JWT → Base64 → JSON → sub, built one step at a time.

Your rules and the way they're enforced haven't changed. What's changed is how fast you can find, read, and manage them.

Your findings list tells you what's wrong. It can't tell you what's reachable.

Attack Paths works from a different input: the actual shape of your estate. Which AWS resources are exposed, which roles can be assumed by whom, which principals can read what. Those relationships are what a path is built from, whether or not anything along the chain has ever been flagged as a problem.

It's live in Infrastructure Discovery now, and there's nothing to install. If your AWS accounts are already connected, it's in your dashboard.

What's new

Paths built from configuration, not from CVEs A path exists because something is exposed, some permission is broader than intended, and something valuable sits at the end of it. Findings from Security Hub, Inspector, and GuardDuty can raise a path's priority, but they never create one and never gate one. Plenty of the paths worth your time have no finding attached anywhere along the chain.

Ranked paths, shown as a map Every path runs from an entry point, through any pivots along the way, to a crown jewel. You get the whole chain as a map, with a severity band and a plain-English reason it landed where it did.

Crown jewels you choose yourself You decide what counts as high value in your estate. Pin and unpin assets from the console, and path scoring reorganizes around your choices instead of our assumptions about your business.

Key nodes: entry points and choke points Entry points are ranked by what they actually open up. Choke points are the nodes that the most paths run through, which is usually where a single change does the most work.

Identity, not just network reachability Paths follow IAM as closely as they follow the network: role chaining, pass-role, policy attachment, self-escalation, and principals holding effective admin through AWS managed policies.

Why it matters

A severity list ranks problems one at a time, and it's genuinely good at that. What it can't do is tell you that a role you granted a vendor two years ago, with "read-only" in its name and a wildcard in its policy, sits one hop from every secret you own. There's no CVE on that role and nothing about it is broken. Someone made a reasonable call and the blast radius grew around it quietly. That's a path, and paths are what this is for.

Where to find it

Infrastructure Discovery → Attack Paths. 

Attack Paths is included in your Infrastructure Discovery license. No separate SKU, no add-on charge.

Full details in the Infrastructure Discovery documentation.

Wallarm is pleased to announce our new Attacks interface.

There’s nothing to install. The new interface will be automatically added to your existing dashboard.

Designed to match the way security teams investigate threats, the new experience makes it easier to identify attacks, spot patterns, and drill into the details that matter.

What's new

Interactive Dashboard
Navigate attack trends and spot anomalies across your traffic. Apply filters directly from charts, tables, and statistics to quickly narrow the scope of your investigation.

Customizable Views
Save views with your preferred columns, filters, time range, and grouping. Create dedicated dashboards for specific attack types, applications, hosts, or incidents.

Attack Investigation Flow
Drill into any attack to inspect request-level details, including source IP, host, URI, payload, parameters, classifications, headers, and the full raw request.

Interactive Request Grouping
Group attacking requests by attack type, source IP, host, path, or a custom combination to reveal patterns that are difficult to spot one request at a time.

Customizable Export
Export attack data using your selected filters, columns, time range, and grouping. Tailor exports for incident response, reporting, compliance, or offline analysis.

Your API security is already covered. What's changed is what's behind those APIs. AI agents are making decisions, accessing data, and calling external services right now, and most security teams can't see any of it. Not because they're not paying attention, but because no tool was built to show them.

Today that changes. We're launching the Wallarm AI Control Platform: two products that close the loop from estate-wide discovery through runtime enforcement through continuous compliance evidence. No new vendor to onboard. It extends the platform you already run.

What's shipping today

Infrastructure Discovery

Connect your AWS accounts once and get a continuously updated inventory of everything in your estate. EC2, VPC topology, EKS clusters, Lambda functions, API Gateway, IAM, and Bedrock models and agents, across every account and every region, in one searchable table.

• Cross-account discovery via IAM role assumption, no write permissions required
• Live relationship graph with blast-radius traversal and attack-path analysis
• AWS Security Hub findings sync, placed on the graph node they affect with full asset context
• Field-level drift detection between every scan, with CloudTrail creator attribution on every asset
• Customer-authored detection and triage rules in Common Expression Language
• Scheduled and on-demand scans; policy audit log for every triage decision

AI Hypervisor

A Kubernetes DaemonSet that instruments every AI workload at runtime via a mutating admission webhook, with zero application code changes. Label a namespace, and coverage begins within minutes. Works across Python, Go, Node.js, Java, Ruby, and generic containers.

• Parses every major model provider: Anthropic, OpenAI, AWS Bedrock, Azure OpenAI, Google Gemini, and more
• Attributes every LLM call back to the originating user or session, across internal service hops
• Real-time sensitive data detection: credit cards, SSNs, passport numbers, API keys, JWT tokens
• Session kill switch by user subject or W3C trace ID, enforced at the kernel, no restart required
• Agent behavior certificates that pin and enforce what each agent is permitted to do
• Continuous compliance report: AI inventory, coverage heatmap, session logs, PII egress records
• SIEM, SOAR, and ticketing integrations for findings and policy violations

EU AI Act enforcement starts in August 2026. If that's on your radar, AI Hypervisor generates the compliance evidence you'll need continuously, not on demand when an audit appears. Getting it running now means you won't be assembling spreadsheets in July.

Learn more in our documentation for AI Hypervisor and Infrastructure Discovery, or request a demo. 

MCP servers provide structured access to privileged systems for AI agents and external integrations. That’s great for enabling things like automated project management, embedded billing, and AI-driven developer workflows. But it also creates a new attack surface that existing security tools were not designed to secure. 

That's why we built MCP Protection, a feature that extends the discovery, visibility, and control you already rely on for APIs to your externally exposed MCP servers.

With MCP Protection, you can:

• Discover exposed MCP servers, tools, and resources
• Correlate MCP and user sessions for full activity visibility
• Enforce granular access and schema-based controls for tool usage

MCP Protection is included in Wallarm Advanced API Security.

Check out this overview of AI and MCP capabilities in the doc hub for more info.

API Discovery now detects how every endpoint in your inventory is authenticated, and how consistently that authentication shows up in real traffic. Bearer tokens, API keys, AWS Signature v4, Basic, cookie-based auth, and the rest. It's all classified, tracked, and filterable.

If you've ever wondered whether that one internal endpoint really requires a token or just usually does, this is for you.

What's new

Per-endpoint authentication status. Every endpoint gets classified as Consistent, Partial, or Missing, based on a rolling 7-day window of production traffic. No guessing, no spec-reading. Just what's actually happening on the wire.

A filter for unauthenticated endpoints. Open the inventory, flip the filter, and you've got a list of exposed APIs in seconds. This is the one most teams will want bookmarked.

Per-parameter coverage on the endpoint detail page. You can see exactly which header, cookie, or parameter is carrying the credential, and what fraction of requests include it. Useful when "Partial" shows up and you need to know why.

Why it matters

Missing auth is one of those problems that's obvious in hindsight and invisible until something goes wrong. Specs say one thing, traffic says another, and the gap is where breaches live. This grounds the answer in what your APIs are doing right now, not what a YAML file claims they do.

Availability

Upgrade your filtering nodes to NGINX Node 6.10.0 or Native Node 0.23.0 (or newer) to start receiving authentication data.

Full guide: docs.wallarm.com/api-discovery/authentication

Sometimes you need visibility into your APIs without touching production traffic.

Wallarm’s TCP traffic analysis engine now supports AWS VPC Traffic Mirroring, so you can mirror traffic from your AWS environment to a Wallarm Node and see what’s happening across your APIs, without adding latency or changing your request path.

What you get

Mirror traffic directly from your AWS Elastic Network Interfaces (ENIs) and unlock:

• API Discovery — Know what APIs you actually have
• API Session analysis — Understand how they’re being used
• Attack detection — See threats targeting your APIs

All out-of-band. No impact to live traffic.

What’s new

• Support for Geneve-encapsulated traffic (used by AWS Traffic Mirroring)
• Support for VXLAN encapsulation
• Native compatibility with AWS traffic mirroring workflows

Why it matters

Some environments require absolutely zero added latency. Others just prefer to observe instead of actively block.

This gives you a clean way to get API visibility and threat detection in AWS without changing how your traffic flows.

Get started

Check out the documentation to start mirroring your AWS traffic to Wallarm.

The new Wallarm NGINX Ingress Controller 7.0 is now available. This release is based on the open-source NGINX Ingress Controller and is fully integrated Wallarm security services. It replaces all previous versions based on the Community NGINX Ingress Controller, which is end of life in March 2026.

Who should upgrade: Teams currently running the Community-based Wallarm Ingress Controller are strongly encouraged to migrate. The upstream Community NGINX project has been retired. If you are running previous versions of the Wallarm NGINX Ingress Controller, there will be no further security updates, bug fixes, or updates of any kind. 

A migration guide from Wallarm is available.

Full deployment guide: https://docs.wallarm.com/7.x/admin-en/installation-kubernetes-en/