ZioSec tests and defends AI agents by attacking them the way an adversary would. Security and AI teams use it to find out whether their agents can be manipulated before an attacker does, and to turn what they find into evidence auditors and regulators accept.
It also works on the other side of the problem: applications and APIs increasingly face traffic generated by autonomous AI attackers, which looks less like one bad request and more like a coordinated campaign.
At A Glance
| Vendor | ZioSec |
|---|---|
| Category | AI agent red teaming and AI traffic defence |
| Identities covered | AI agents, including custom agents, Claude Code and agents built on MCP or A2A |
| Deployment | Platform, API or scoped engagement; Voidhawk self-hosted on Kubernetes or as a hosted edge |
| Agentic AI | Autonomous attack trees against AI agents; AI-assisted traffic investigation in Voidhawk |
| Headquarters | Boulder, United States |
| Market classification | Agentic AI Identity |
What ZioSec Does
Agents now call tools, talk to other agents and hold credentials, so a single successful prompt injection can become data theft or privilege escalation. ZioSec’s view is that the way to know whether an agent is safe is to attack it, continuously and in a way tailored to that agent, and to report each weakness in a form engineering can fix and a GRC team can file. The same thinking applies in production, where defenders need to see AI-driven attack campaigns across many requests and stop them before they reach the services agents depend on.
Products
AI Red Teaming Platform
Teams shipping AI agents need proof that those agents resist manipulation, both for their own assurance and for frameworks such as the EU AI Act. The AI Red Teaming Platform attacks agents with prompt injection, tool misuse, agent to agent exploits, privilege escalation, data exfiltration, system prompt extraction and credential abuse, built through an Attack Builder interface. An AI engine plans a tree of attacks for each agent and runs it in real time, so the attacks follow that agent’s own tools and connections instead of a generic list of prompts. It comes in three forms:
| Platform | Continuous validation across a whole agent fleet |
|---|---|
| API | Point it at an agent endpoint and receive evidence back |
| Scoped engagement | A fixed-scope pentest led by ZioSec experts, which can roll into a platform subscription |
Findings map to the EU AI Act, NIST AI RMF, ISO/IEC 42001, AIUC-1 and OWASP AISVS.
Voidhawk
Voidhawk defends applications and APIs against autonomous AI attackers. It is in active development, with design partnerships open. It gives packet-level visibility of request and response payloads between applications and APIs, and correlates signals across IP addresses, sessions and time to recognise a campaign rather than a single odd request. Analysers, heuristics and lightweight models inspect traffic at line speed, and harder cases go to deeper AI investigation. Voidhawk can block in real time or pass signals and evidence to SOC workflows and AI SOC platforms.
How It Works
The red teaming platform is a service used through its interface or API. Voidhawk runs either in the customer’s cluster or in ZioSec’s cloud.
| Component | What it does |
|---|---|
| Self-hosted | A Helm chart installs Voidhawk into one namespace of a Kubernetes cluster (version 1.27 or later, with GPU capacity for inference). Request data and calibration stay in the customer’s infrastructure, updates arrive as signed OCI artifacts, and ZioSec never opens inbound connections into the cluster. |
| Hosted edge | ZioSec runs the edge and inspects traffic before it reaches the customer origin. |
| Controller and proxies | A single controller with read-only cluster access builds a cached routing table from Ingresses and Services. Two proxies form the data plane; they hold no Kubernetes API credential and keep routing from cache through controller restarts. |
| Inference nodes | One or more nodes, each with its own GPU, calibrate fields and decide ambiguous cases. |
| Attachment modes | Voidhawk attaches through ext_proc, the recommended mode for Envoy-family gateways with dry-run support; through mirroring, which sees requests only and cannot block; or through TLS passthrough, where it computes JA3/JA4 fingerprints. Each request produces one structured verdict, available as JSON logs, through a query API or in optional PostgreSQL. |
Identities And Systems Covered
| AI agents | Custom agents, Claude Code and any agent built on MCP or A2A |
|---|---|
| Agent credentials and privileges | Tested for abuse and escalation |
| Applications and APIs | Traffic between them inspected by Voidhawk |
| Kubernetes | Ingresses, Services and HTTPRoutes read by self-hosted Voidhawk |
Integrations
| Area | Integrations |
|---|---|
| GRC and trust | Drata, Vanta, Archer, ServiceNow GRC (via API) |
| Gateways (ext_proc) | Envoy Gateway, Istio, Contour, Gloo, kgateway, raw Envoy |
| Gateways (TLS passthrough) | Traefik, HAProxy, NGINX Ingress, F5 |
Company Background
| Headquarters | Boulder, Colorado, United States |
|---|---|
| Leadership | Aaron Walls, CEO |
| Investors | Part of the F4 Fund startup portfolio |
Note: This overview is compiled from ZioSec’s publicly available information as of 3 November 2026. It is provided for information only. NHI Mgmt Group does not endorse any vendor, and nothing on this page represents the opinions of NHI Mgmt Group.