# Hexes Security — Inline zero trust for Kubernetes workloads

> Hexes learns each Kubernetes workload, writes the policy itself and enforces it inline at layer 7 — network, process, file — for services, AI apps and agents.

- Canonical: https://hexessecurity.com/
- Last updated: 2026-10-16
- Site index for agents: https://hexessecurity.com/llms.txt

_Cloud workloads · Kubernetes clusters · AI agents_

# Others watch. Hexes blocks before the app.

Hexes reads every request at layer 7, allows only what the workload learned to do, and blocks the rest before delivery — not after it executes. No sidecar. No CNI change.

[Try it out](https://hexessecurity.com/company#contact)
[See how it works](https://hexessecurity.com/#how)

Standing guard, so you’re never on your own.

[Customer quote.]

[Name, role, company] -->

_Start here · 2:57_

## Meet Hexes in three minutes.

Autonomous protection for an autonomous world. The idea behind Hexes, in under three minutes.

Intro film · 2:57 · [Watch on YouTube](https://youtu.be/RWtn867Qfl4)

_From reactive to proactive_

## Four questions to ask any runtime vendor.

Every platform now says it stops attacks. The answers to these four tell you what actually happens when a bad request arrives.

1. **Does it read the payload of every connection — or watch syscalls and flows?**Hexes inspects the request itself, on every protocol: HTTP, gRPC, TLS, DNS, MySQL, Redis, Kafka and more.
2. **Does it block before the request reaches the app — or kill the process after it starts?**Hexes enforces in the request path. "Stop attacks as they execute" means the attack executed.
3. **Is the policy an allow-list learned from the workload — or a deny-list of known-bad?**Hexes allows only what the workload learned to do and blocks the rest. Signatures find yesterday's attack; an allow-list doesn't need to know today's.
4. **Does it constrain what an agent may call — or inventory your agents?**Hexes puts each agent under the same learned policy: which tools, endpoints and data it may reach.

The same four answers, by category · What each approach does when the request arrives

| At runtime | Snapshot & scan | Watch the kernel, then kill | Segment by identity | Inspect the request, block before delivery |
| --- | --- | --- | --- | --- |
| When the attack executes | After the next scan | As it executes | n/a — flow-level only | Blocked before it reaches the app |
| What it sees | Cloud API + disk snapshots; optional sensor | Syscalls, processes, flows | L3/L4 identity, some L7 headers | Full payload — L7 protocol inspection of every connection |
| What it does about an attack | Alerts; kills the process | Alerts; kills the process | Drops the flow by label | Blocks the request inline — before it reaches the workload |
| How policy is written | Rules and graphs in the console | Rules, YAML | YAML per service | Learned from the workload's own behaviour, then locked |
| Web attacks and data loss | Separate WAF / DLP products | — | — | WAF and DLP in the same inline path |
| AI-agent and MCP traffic | Inventory (AI-SPM) | — | — | Inspected and enforced like any other L7 flow |

Hexes is not a CSPM or a SIEM. Keep your posture platform and your SOC — Hexes enforces inside the cluster and sends every event to them.

_Autonomous policy_

## Learning. Watching. Enforcing.

You do not write Hexes policy from a blank page: Hexes writes it from the workload, you review it, then it enforces — network, process and file. Three modes make that safe to roll out cluster by cluster; hand-written YAML stays optional, exportable as CRDs when you want it in Git.

Learning

### Learn the baseline

Observe and record. Every connection, protocol, process and file access becomes an explicit allow policy — exportable as CRDs so it lives in Git.

Watching

### Watch it hold

Policy active, enforcement off. Every deviation is an event with full L7 context — the request, not just the flow — routed to your SIEM. Tune, approve, promote.

Enforcing

### Enforce inline

Enforcement on. Anything outside the policy is blocked at layer 7 — unknown egress, an injected request, a rogue shell, a tool an agent was never allowed to call. Per namespace, per workload, per rule.

_Why Hexes_

## Inline zero trust for Kubernetes workloads.

The enforcement layer inside your cluster. It learns each workload, writes the policy, and blocks what falls outside it — network, process, file — at layer 7.

### Observe, then enforce

An inline L7 firewall, WAF and DLP inside the cluster — in the request path, not beside it. Watching mode alerts on deviations; Enforcing mode blocks the request itself.

### Kubernetes-native

No sidecar, no CNI swap. Runs beside Cilium and Calico, works with your existing service mesh; policy as CRDs.

### Compliance, continuous

CIS Kubernetes benchmarks, DISA STIG, PCI / NIST / HIPAA / GDPR templates — continuous reports, not annual scrambles.

### Policy writes itself

Hexes learns each workload's real behaviour and turns it into an explicit allow policy — automatically. You approve; it enforces. Hand-written rules and manual upkeep become optional, not a prerequisite.

### Supply chain, built in

Image scanning, admission gates, signatures, SBOM and VEX — the evidence your auditors ask for.

### A proven core, respectfully built

Empowered by the NeuVector open-source project, and respectful of it. Licence intact, credit given; the next generation is ours.

_Constrain agents_

## Agents are workloads. Hexes treats them that way.

Model endpoints, agent frameworks and MCP tool servers run in your clusters and talk over the same protocols. Some platforms inventory your agents, some filter prompts, some use AI to sort their own alerts. Hexes puts each agent under a learned policy of what it may call — tools, endpoints, data — enforced inline.

### Agent-to-tool traffic

See which agent calls which tool, over which endpoint, with what payload — and block the call that falls outside the learned policy.

### Model endpoint egress

Allow-list the model providers a workload may reach by FQDN; DLP on prompt and response payloads for secrets and regulated data.

_Fits what you already run_

## Keep your platform. Add enforcement.

Runs on any conformant Kubernetes — Helm or Operator, including air-gapped and sovereign environments. Every event carries its full layer-7 context and goes where your analysts already look.

Runs on

Kubernetes · Red Hat OpenShift · Rancher by SUSE · Cilium · Calico · Docker

EKS · AKS · GKE · Istio · Helm · Operator · CRDs / GitOps · Harbor · GitHub Actions · GitLab CI · Sigstore · Air-gapped

Sends events to

Palo Alto Networks Cortex XSIAM · CrowdStrike Falcon · Microsoft Sentinel

Cortex XSIAM · Falcon NG-SIEM · Microsoft Sentinel · Google SecOps · Splunk · Elastic · OCSF · Syslog / webhook · Prometheus

Third-party marks belong to their owners and indicate compatibility, not endorsement.

_Try it out_

## One cluster. One bad request.

Hexes is getting ready. Bring one cluster, send one bad request, and watch it get blocked before it reaches the app.

[Try it out](https://hexessecurity.com/company#contact)[Read the FAQ](https://hexessecurity.com/faq)

---

_About Hexes Security:_ Hexes Security builds commercial cloud-workload security for Kubernetes: inline zero-trust enforcement at layer 7 — network, process and file — from policy learned from each workload (Learning → Watching → Enforcing). It is empowered by the NeuVector open-source project (Apache-2.0), which Hexes credits and respects, and extends that engine for eBPF, AI-agent and MCP traffic, and the software supply chain. Hexes is not open source, not a CSPM/CIEM, not a SIEM and not a CNI. NeuVector is a trademark of SUSE; Hexes is independent and not affiliated with SUSE.