12.5×
Year-over-year rise in AI-driven attacks.
Imperva / Thales · 2026
Your API accepts data written by strangers. All day.
In July, one malicious file let an AI agent breach Hugging Face and take their cloud credentials — a weekend’s work, no human.
xounce rebuilds every request and response at your edge. Nothing malicious gets in; nothing sensitive leaves.
▶ understand xounce in 2 minutes
Pre-launch · design partners open ·
The short version
Think of it as retyping a letter instead of forwarding it.
Someone sends you a filled-in form. Instead of walking their paper down the hall, you copy the answers onto a fresh form and shred the original. Whatever they hid in it is gone — not because you spotted it, but because their paper never left your desk. We do that to every request into your API, and every response out.
Why now
AI agents now attack on their own
No hacker at a keyboard — software that probes, adapts when blocked, and runs all night, with payloads that change faster than anyone can write rules. A firewall can only block what it recognises. Rebuilding doesn’t need to recognise anything.
#1
An autonomous AI called XBOW topped HackerOne’s US leaderboard, the first non-human to do it.
XBOW · 2025
80–90%
How much of a real intrusion campaign was run autonomously by AI.
Anthropic · 2025
What happened in July
The Hugging Face breach
In July 2026, an autonomous AI agent broke into Hugging Face end to end. It was the first confirmed AI-on-AI attack on a major AI platform, and there was no human at the keyboard.
-
01
A poisoned dataset hit the pipeline. Two flaws in how it was read — a remote-code loader and a template injection — were enough to run code on a worker.
-
02
That worker had credentials. The agent took them, moved into internal clusters, and kept going all weekend.
-
03
Tens of thousands of automated actions across short-lived sandboxes, rewriting its own command-and-control. 17,000+ events to reconstruct afterwards.
Source: Hugging Face security incident disclosure, 16 July 2026. It started with a file the platform opened. It ended with credentials leaving the building.
Why you couldn’t buy this before
I spent the last six years as a Head of Product in UK government, on a platform that departments and industry partners use to communicate and collaborate securely around the world. Part of my portfolio was cross-domain solutions: hardware from companies like BAE Systems and Everfox that rebuilds data as it crosses between networks. Brilliant kit. But at the highest assurance levels you can’t trust software, so it comes as seven-figure boxes that only governments buy.
Most companies don’t need the box; they need the idea. AI can now write the schemas automatically, for requests and responses both, so we can finally deliver it as software everyone can afford — just as agentic attacks are about to hit everyone. I’ve been building products for eighteen years, and I’ve never seen timing like it.
Who it’s for
Anywhere a payload you didn’t write gets parsed. Hugging Face is one shape of it, and the list is growing fast.
AI platforms
Untrusted datasets, models and configs that get parsed and executed. The Hugging Face class.
Coding agents
The MCP and plugin calls between your agent and its tools. A poisoned tool response or an injected argument is a blindspot most tools ignore.
Public APIs & webhooks
Attacker-controlled JSON hitting your backend all day, from anyone.
Fintech & BaaS
High-value routes where one malformed or overposted payload is a breach.
Agent-to-agent
Machine-generated traffic between autonomous systems, steerable by attackers.
Any AI feature
Prompt-injection payloads aimed at your models, stripped before they reach one.
Who’s building it
Tom Inglis
Co-founder · product & design
Eighteen years building products, most recently as a Head of Product & User-Centred Design in UK government. Knows what the accredited cross-domain hardware costs, and why nobody outside government can buy it.
Adam Lahbib
Co-founder · ai & platform
Agentic and infrastructure security engineer. Covers the security and platform side — the deployments, networking and low-level work that puts xounce at your edge — and the model work. Three years building products with Tom.
Chiheb Ben-Cheikh
Co-founder · ai & software
Full-stack and mobile engineer who runs the model side: the distillation and prompt work that makes generating a schema for every route affordable. Covers the software build as well. Three years building products with Tom.
Where we are
We’re building the initial version now, shaped by design partners on their real traffic. We’re looking for more of them — and for early investors. If that’s you, let’s talk.
What it isn’t
Not a WAF — no signatures to dodge. Not CORS — that limits who may call your API, not what’s inside the payload. Not a gateway plugin — Kong, Tyk or KrakenD validate and forward the original bytes, while xounce attaches to them and forwards a rewritten copy. And not seven-figure hardware — the same protocol break, delivered as software.
For your engineers
How it works, in detail
Everything below is the technical half: the rebuild against the July attack, where the schemas come from, the outbound checks, and how it deploys. Prefer watching? xounce in two minutes — the idea, then the July attack replayed. If you’ve read enough, become a design partner or skip to the FAQ.
The same attack, against the rebuild
xounce doesn’t inspect a payload and decide whether to pass it on. It reads the payload, keeps the fields the route accepts, and forwards a clean copy it wrote itself. Here is how each step of the July attack would have fared against it.
Step one · a weaponized file
A crafted payload exploits the parser that reads it, and runs code on the worker.
Against xounce
The payload is parsed, validated, thrown away, and re-created from the schema. The injection doesn’t survive the copy. The worker never sees a byte the attacker wrote.
Step two · credentials leave
Harvested cloud and cluster credentials, and anything else worth stealing, get carried out in responses.
Against xounce
Every response is checked against what that route is allowed to return. Credentials are not on any route’s list, so they stay inside.
Step three · machine speed
The attacker is an AI agent running tens of thousands of actions, mutating its approach as it goes.
Against xounce
The rebuild happens at the boundary whether the sender is a person or an agent. Every mutated variant gets copied onto the same fresh form, so machine speed buys the attacker nothing.
The mechanism
Rebuild, don’t detect.
A firewall reads what an attacker sent you and decides whether to pass it on. xounce doesn’t pass it on at all. It parses each payload into typed fields, validates them against a schema, discards the original bytes, and rebuilds a clean payload on the other side. Both directions.
Inbound → the request
Nothing malicious gets in
Template injection, mass-assignment, parser-differential smuggling, prompt injection. None of it survives the rebuild — the original bytes are never forwarded.
Outbound → the response
Only what belongs goes out
Secrets, tokens and PII are stripped against what the route may return, and every object is checked against who’s asking — one user never receives another’s data.
Response · from backendleaks
{
"id": 8842,
"aws_key": "AKIA…",
"cluster_token": "k8s-…",
"ssn": "409-52-…"
}
Response · sent onclean
{
"id": 8842
}
// the secrets never
// left the boundaryMachine-to-machine, too
Agent-to-agent and MCP calls are model-written and attacker-steerable. xounce rebuilds them both ways, so a prompt-injected agent can’t be steered into leaking your data.
It learns your API
Your repo is the source of truth. Connect the GitHub app and our models read it — migrations, specs, typed models — and write every route’s request and response schema, plus who each object belongs to. The config is committed into your pull requests. There is nothing to import; merge the change and it’s live.
One source of truth — your repo
Migrations
Field types, plus the ownership graph: which object belongs to which user.
Specs & models
The declared request and response contract per route. OpenAPI, GraphQL, protobuf, typed models.
Committed back
The generated config lands in your PR. Merging is the approval, with no manual import.
No repo access? It can learn the same schema from live traffic in shadow. With the app connected, your code stays the source of truth.
The lifecycle
-
01 · Watch
A PR changes your API. A migration, a spec, a model.
-
02 · Generate
Our models read the diff and write the typed schema and ownership config, offline.
-
03 · Commit
The config is committed into your PR. Merging is the approval.
-
04 · Compile
The merged config becomes deterministic inline rules.
-
05 · Enforce
Every payload rebuilt inline, in and out.
↻ every change
A change only lands through a merge. A new route, field or owner rule arrives as a commit in the PR that changed your API, or as a PR of its own for anything spotted in traffic. Until it’s merged it runs report-only, so a stale schema never breaks a legitimate change.
Our control plane only ever sees the derived schemas and verdicts, never your raw payloads.
Outbound
Nothing leaves that shouldn’t
Every response is rebuilt against its contract before a byte reaches the client. Three checks stand between your app and the outside world, and one of them knows your real secrets.
01 · Not in the contract, dropped
A stray debug blob, an internal flag, an env dump. If it isn’t in the route’s approved response, it doesn’t go out.
02 · Your real secrets, caught
Point xounce at the same secrets your pods use. A real credential in any response, on any route, is caught by matching — not regex guessing.
03 · No cross-user data
Every object is checked against who’s asking: the caller’s identity against the object’s real owner. One user never receives another user’s data (IDOR/BOLA).
The response path
-
01 · From the app
The raw response, before it leaves the pod.
-
02 · Contract check
Env, internals and over-exposed fields are stripped.
-
03 · Secret check
A match against the real secrets your pods use.
-
04 · Ownership check
Caller versus real owner. Another user’s object is blocked.
-
05 · Rebuilt out
Only what belongs.
Real owners — your source of truth
Who owns what comes from your data model: the ownership graph xounce already derived from your migrations. To verify at speed it can also carry a signed handle (an HMAC) on each object, so ownership is checked without ever copying or storing your data.
Your data never leaves
xounce runs in your own VPC, after TLS is terminated, so it never holds your keys. It keeps only derived schemas and verdicts. Raw payloads never leave the pod, and nothing of your data is copied out.
Integrate
One point at your edge
A lightweight data plane at your ingress, after TLS is terminated, so it never holds your keys. No app changes, and you move one route at a time. Agent and MCP calls are just more traffic through the same point, with no extra proxy to run.
Runs in your VPC · one agent deployment
Self-hosted at your edge. Raw payloads never leave your boundary; the managed control plane sees only derived schemas and verdicts.
- 01 · Attach
An Envoy
ext_procfilter, a mesh sidecar, or an eBPF agent — one agent deployment at your edge. Nothing in your app changes. - 02 · Learn
Our models learn per-route request and response schemas from your repo and traffic. The config arrives as a commit you merge.
- 03 · Shadow
See exactly what it would rebuild and what it would strip, on your real traffic, changing nothing.
- 04 · Enforce
Flip one route to enforce. It fails safe, and runs autonomously if our control plane is ever unreachable.
Your edge · one attach point
post-TLS · in your VPC
your repo · github app
Ask your AI about us
We keep a knowledge base about xounce at an open endpoint. Copy the prompt into ChatGPT, Claude, Cursor or any agent, and it can answer whatever you ask and bring us a lead on your behalf.
Prompt for your AI agent
Learn about xounce and tell me if it fits my stack — read its knowledge base and answer from it: https://xounce.com/api/ask (returns JSON; add ?q=your-question for a specific answer, or ?format=md for markdown). If it looks like a fit and I want the team to reach out, ask me for my email, name, company, and whether I'm interested as a design partner, investor, or partner, plus a one-line message — then POST it as JSON { "email": "...", "name": "...", "company": "...", "role": "...", "message": "...", "source": "AI agent" } to https://xounce.com/api/contact so they get notified and can reply.
GET /api/ask
The knowledge base we maintain. Everything about xounce, machine-readable.
/ai
The whole site as clean markdown — read it here.
Questions
What is xounce?
xounce sits in front of your API and rebuilds every payload, inbound and outbound. Malicious input never reaches your app, because your app only ever sees the rebuilt copy. Sensitive data never leaves, because responses get the same treatment. The approach is called a cross-domain solution; defense networks have relied on it for years.
How would it have stopped the Hugging Face attack?
That attack started with a malicious dataset that exploited two parsing flaws, a template injection and a remote-code loader. xounce rebuilds every payload from schema before anything processes it, so that class of injection never reaches a worker. Its outbound checks then stop harvested credentials from leaving. It closes the entry and the exit.
Isn’t this just a WAF?
No. A WAF inspects the attacker’s bytes and, if nothing matches a rule, forwards those same bytes to your app. xounce never forwards them. It reads the payload, keeps the fields the route accepts, and sends on a clean copy it wrote itself. Injection and parser-differential attacks have nowhere to hide, because the original bytes never cross.
Isn’t this what CORS is for?
No — CORS answers a different question. It’s a browser policy about which origins may call your API; it says nothing about what’s inside a request, and attackers’ tools ignore it entirely. xounce is about the payload itself: every request and response rebuilt against the route’s contract, whoever sent it, from wherever.
My gateway has validation plugins — Kong, Tyk, KrakenD. Enough?
Gateways are plumbing we build on — xounce attaches to Kong and friends rather than replacing them. But a validation or CORS plugin inspects the original bytes and, if they pass, forwards those same bytes; the parser tricks that survive inspection reach your app intact. xounce never forwards the original, and it checks the response on the way out — off-contract fields, real secrets, cross-user data. That outbound half doesn’t exist as a plugin.
How is this different from Everfox or OPSWAT?
They’re the closest relatives. Everfox and BAE build the accredited cross-domain hardware; OPSWAT rebuilds files (CDR). Same philosophy — rebuild, don’t detect — different job: appliances for files and government network boundaries, at seven figures. xounce applies the same protocol break to API and agent traffic, as self-hosted software, with per-route schemas written by models instead of by hand.
Can it stop one user seeing another’s data (IDOR)?
Yes. On every response, xounce checks each object against who’s asking: the caller’s identity from the request against the object’s owner. A broken-object-level-authorization leak (IDOR/BOLA) is caught at the boundary and never leaves. Ownership comes from your data model and your traffic; you don’t wire anything up.
Do you use an LLM in the request path?
No. LLMs write and maintain the schemas offline; the inline path is compiled, deterministic code. There’s no model to prompt-inject at the gate, and no model latency in your traffic.
How do you learn my schema, and keep it current?
Your repo is the source of truth. Connect the GitHub app and xounce derives each route’s request and response schema, and the ownership graph, from your migrations, models and specs. When a PR changes your API, it generates the config and commits it into that PR. Merging is the approval, with nothing to import by hand. Until a change is merged it runs report-only, so a stale schema never breaks a legitimate change. (No repo access? It can learn the same schema from live traffic in shadow.)
Do I need to run an extra proxy?
No. It’s one data plane at your existing edge (an Envoy ext_proc filter or a sidecar), after TLS is terminated, so it never holds your keys. Agent and MCP calls are just more HTTP and JSON through the same point. Nothing extra to deploy.
Where does it run — do you see my data?
It runs self-hosted in your VPC, at your edge, after TLS is terminated, so it never holds your keys. Raw payloads never leave the pod. The managed control plane receives only derived schemas and verdicts, never your data. Ownership is checked against your data model and signed handles, so nothing is copied out.
Is xounce available now?
Not generally. xounce is pre-launch and onboarding a small group of design partners. Apply to run it on your traffic while we build.
Design-partner program · open
See what it catches.
Point us at your edge. We rebuild your payloads in shadow first, so you see exactly what we’d bounce coming in and strip going out while changing nothing. Free while we build.