Skip to content

Prove-and-fix security · code, IaC & APIs

We prove it.
Then we fix it.

xounce cuts your backlog to the vulnerabilities that actually need your attention — proven, and fixed for you — and rebuilds every API payload so attacks and leaks bounce off.

01 · Code & IaC

Kill the exploitable vulnerabilities

Prove what’s real across code, dependencies, secrets and infrastructure — then auto-fix it. See the pipeline →
02 · API endpoints

Bounce the attacks and the leaks

Rebuild every request and response at your edge, so malicious payloads in and sensitive data out never get through. See cross-domain →
Become a design partner Book a call

Pre-launch · already proved on our sibling companies cenefits.com and offmon.com ·

xounce attempt · finding XNC-2214 confirmed 
$ xounce attempt --finding XNC-2214
  → AI probed the path · built an exploit from call-graph (14 steps)
  → replayed against an ephemeral target
  ✓ EXPLOIT CONFIRMED — SQLi via POST /api/v2/transfer
  → PoC saved · replayable · attached to fix PR #482
Every finding ships with a replayable proof-of-concept — not a severity score.

The proof gate

If we can’t exploit it, you never see it.

Every other tool dumps the raw pile on you and calls it coverage. xounce runs each finding down a funnel and refuses to report anything it can’t prove. The collapse is the product.

01 / Detected
50,412

SAST, SCA, secrets, IaC, DAST — the raw pile every other tool dumps on you.

02 / Reachable
1,873

48,539 never called — the vulnerable function is actually used in your code, not just the package installed.

03 / Exposed
214

1,659 not internet-reachable — the vulnerable path is exposed to the public internet: real attack surface.

04 / Confirmed
9 PoC

AI probes each one and lands a working exploit. No proof-of-concept → no report. Each survivor ships with a replayable PoC.

Illustrative — this is what the gate is designed to do, not a measured result on your repo. Your numbers will differ. We publish real run logs as we onboard design partners.

One pipeline

Scan everything. Report only what’s real. Fix what you can.

Six surfaces, one gate. Proof and fixes first — everything else is retained for audit, off your screen.

01

Proof-gated scanning

Scans everything — SAST, SCA, secrets, IaC, DAST — then reports only what it can reach, expose, and exploit. The other 50,000 findings are kept for audit, not for anxiety.

02

Auto-fix pull requests

When a confirmed vuln has a clean fix, xounce opens a labeled PR — bumps the package, regenerates the lockfile — with the CVE details and the exploit proof in the body. One PR per language.

03

Reviews every human PR

Changed files only. A real review: approves when clean, requests changes with findings, and leaves one-click committable suggestions for insecure config, hardcoded secrets, and vulnerable deps.

04

A dashboard in GitHub Issues

Renovate-style, per repo. Confirmed-exploitable fixes open their own PR. Everything else is a checkbox you tick when you want the PR. It never spams.

05

A findings console that stays clean

Confirmed exploitable and exposed — that’s the whole main view. Everything the gate dropped is retained for audit, one click away, never on the front page.

06

Runtime & tenancy

Optional runtime threat detection (Falco) alongside. Per-tenant subdomains, self-serve onboarding, and a GitHub App that labels everything it authors.

xounce[bot] opened a pull request

fix(deps): bump lodash 4.17.19 → 4.17.21 — CVE-2021-23337, exploit confirmed

xounce:securitydeps:npm exploit-confirmed
▸ Exploit proof — command injection via template, 14-step trace, reproduced on ephemeral target 
--- a/package.json
+++ b/package.json
- "lodash": "4.17.19"
+ "lodash": "4.17.21"
✓ xounce / exploit-replay — proof no longer reproduces Merge

You merge. We never do.

A monochrome reconstruction — the CI check re-runs the exploit against the fix and confirms it no longer reproduces.

Where this goes

The obvious fixes ship themselves. The judgment calls come to you.

Autonomy from instruction — not from you. xounce opens pull requests on its own. It never merges them.

Today
  • — Dependency-fix PRs open themselves for confirmed-exploitable findings.
  • — Every human PR gets a real security review.
  • — The Issues dashboard queues on-demand fixes you trigger by ticking a box.
Building toward
  • — A pipeline that watches your repos continuously.
  • — Proves what’s dangerous, fixes what’s mechanical.
  • — Surfaces only the judgment calls — with the proof attached.

Nothing reaches production until a human clicks merge. A bot never touches the button.

We build it the same way

xounce is actively being built by a small team and AI agents — agents do the heavy lifting, humans review and merge. We ship the way we tell you to: autonomy from instruction, never from us.

Onboarding

Two things to protect. Onboard each in an afternoon.

Code & IaC · the GitHub App

Install the app

Two steps. You grant access to the repos you choose — nothing else, least-privilege, read-only until you opt a repo in to PR authorship.

  1. 1 — Install xounce[bot] and pick the repos to grant.
  2. 2 — xounce runs the gate and posts the first confirmed findings.
API endpoints · cross-domain via MCP

Point your coding agent at us

The cross-domain layer is configurable per route, so our MCP server lets Claude Code, Cursor, or Codex read the playbook and help you wire it into your edge — customising the schemas to your API, showing every change, and stopping for your approval.

# paste into your agent
Wire xounce's cross-domain layer into my
edge. Read the playbook at xounce.com/agent,
customise the schemas to my routes, and show
me every change before you make it.

Either way, repo and infrastructure access is always something you grant explicitly in GitHub or your cloud — never auto-granted on your behalf.

Cross-domain · a track of its own

Your API never touches attacker bytes.

Rebuild, don’t detect.

A WAF reads a payload and waves it through. That’s where whole attack classes live — the parser your firewall uses and the parser your backend uses disagree about the same bytes, and the attacker crafts the gap. xounce closes it by refusing to forward anything the attacker sent.

For every request, xounce parses the payload into typed fields, validates it against a schema, discards the original bytes, and rebuilds a clean, canonical payload before your backend ever sees it. A protocol break.

The parser-differential bug class isn’t detected — it’s made unexpressible. Injection, mass-assignment / overposting, duplicate-key smuggling, oversized and malformed bodies: gone, because none of it survives the rebuild.

LLMs synthesize the schemas offline; compiled, deterministic code enforces them inline. No model sits in the request path — so there’s nothing in the hot path to prompt-inject or slow down.

Inbound · attacker-craftedbounced 
POST /api/v2/transfer
{
  "amount": 100.00,
  "amount": 9999999,   ← dup key
  "is_admin": true,    ← overpost
  "note": "'; DROP--"  ← injection
}
Forwarded · rebuiltcanonical 
POST /api/v2/transfer
{
  "amount": 100.00
}
// dup collapsed · unknown dropped
// value preserved exactly

Both directions

Nothing malicious in. Nothing sensitive out.

The rebuild runs both ways. On the way in it bounces attacker-crafted payloads. On the way out it’s data-loss prevention: the response is validated against what that route is allowed to return, and anything it isn’t — secrets, tokens, PII, over-exposed fields — never leaves your boundary.

Inbound → the request

Bounce the attack

Injection, mass-assignment, parser-differential smuggling, malformed and oversized bodies, and prompt-injection payloads aimed at your AI features — rebuilt away before the backend parses a byte.

Outbound → the response

Bounce the leak (DLP)

Over-exposed objects, stack traces, internal tokens, API keys and PII that a bug or a broken-object-level-authorization flaw would spill — validated against the route’s response schema and stripped on the way out.

Response · from backendleaks 
{
  "id": 8842,
  "email": "[email protected]",
  "ssn": "409-52-...",
  "pw_hash": "$2b$...",
  "stripe_sk": "sk_live_..."
}
Response · sent to clientclean 
{
  "id": 8842,
  "email": "[email protected]"
}
// off-schema fields never
// left the boundary

How it integrates

Drops in at your edge. Runs in your VPC.

Like the GitHub App does for your code, a lightweight data plane does for your traffic — one attach point, zero code changes, and you move one route at a time.

  1. 01 · Attach

    An Envoy ext_proc filter or a sidecar proxy at your ingress — post-TLS, so xounce never holds your keys. Nothing in your app changes.

  2. 02 · Learn

    It watches real traffic and synthesizes per-route request and response schemas offline. You approve them as diffs, GitOps-style.

  3. 03 · Shadow

    See exactly what it would rebuild and what it would strip — on your real traffic, changing nothing.

  4. 04 · Enforce

    Flip one route to enforce. It fails safe by design, and runs autonomously if our control plane is ever unreachable.

Attaches to what you already run
  • Envoy
  • Envoy Gateway
  • Istio
  • Kubernetes
  • NGINX Ingress
  • AWS ALB
  • Kong
  • Cloudflare
  • MCP / agent traffic
Where it fits

Best for teams that ingest untrusted JSON all day — fintech and BaaS, healthcare, webhook-heavy B2B SaaS, public APIs, and AI/agent apps whose tool calls are attacker- influenceable. Anywhere a malformed request or an over-sharing response is a breach.

Why xounce

The enemy is the backlog nobody reads.

Scanners detect.You get a backlog of 50,000 maybes.
Provers prove.You get a report, and still have to fix it.
Fixers fix.You get PRs for findings nobody proved mattered.
xounce closes the loop.Prove it’s real. Then open the PR that fixes it.

Where we are

Pre-launch, and saying so.

xounce is being built with a small group of design partners. You won’t find customer logos, compliance badges, or a wall of testimonials here — we’d rather show you a run log and a replayable proof. When we have a SOC 2, we’ll put it here. Not before.

The exploit gate is honest about its own limits: a vulnerability the engine can’t yet trigger is kept and labeled, never silently deleted. We publish what the engine gets wrong.

You’ll hate xounce if

  • you want every CVE on the front page — the proven ones are the front page; the rest are one click away, on purpose.
  • you want a compliance checkbox count more than proven exposure.
  • you want software that merges to main without you. It never will.
  • you need five years of enterprise references today.

AI-friendly · ask your agent

Don’t take our word for it. Ask your AI.

We treat AI agents as first-class here — reading us, asking us, and reaching us are all built in. xounce publishes its own knowledge base at an open endpoint: copy the prompt below into ChatGPT, Claude, Cursor — any agent — and it’ll answer whatever you ask, and can 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, always current.

POST /api/contact

Your agent — or you — can send us a question or a pilot request. It reaches us directly.

FAQ

The questions a security lead asks first

What is xounce?
xounce is a continuous validated vulnerability pipeline: it scans your code, dependencies, secrets, infrastructure and running app, then only reports the vulnerabilities it can actually exploit — each with a replayable proof-of-concept — and opens the pull request that fixes them. It’s end-to-end automated, from your code to the merged fix, and built for teams drowning in scanner findings nobody has time to triage.
What does “proof” actually mean — do you just ask an LLM if it looks exploitable?
No. A finding is only “confirmed” when xounce’s engine actively probes it with AI — it builds a working exploit from the call-graph context and reproduces the vulnerability against a running target in a sandbox, producing a proof-of-concept you can replay yourself. We run capable, fast open-weight models, distilled and adapted for the task, so probing stays quick and cheap. The AI does the probing; the proof itself is the deterministic replay, never a model’s opinion.
If “no exploit means no report,” won’t you hide real vulnerabilities?
A vulnerability the engine can’t yet trigger is retained and labeled — kept out of the main view, never deleted. Your full inventory is one click away for compliance. We treat “reachable” and “exploitable” as confidence tiers, not a silent delete, and we publish the gate’s false-negative behavior rather than hiding it.
What can the GitHub App read and write? What’s the blast radius if you’re breached?
Least-privilege, published scopes. Default posture is read-only and report-only; PR authorship is opt-in per repo. The App only touches repos you select, and labels everything it authors. We ship a written blast-radius page — exactly what an attacker could reach if xounce were compromised — before you install.
You attack a running target — does that mean you fire exploits at my production?
No. Exploit attempts run against an ephemeral target xounce stands up from your repo, isolated with controlled egress — never your production or shared infrastructure, unless you explicitly point it somewhere. The design-partner pilot is read-only with no exploit traffic to any environment you don’t nominate.
Auto-fix PRs — won’t they break my build?
A fix PR carries two checks: the exploit no longer reproduces, and your tests still pass. Confirmed findings without a clean fix (no patched version, breaking major, first-party bug) are surfaced honestly with no PR, rather than a fix that pretends to work. You review and merge every one — xounce never merges.
What happens when xounce is down?
Nothing in your critical path. xounce runs asynchronously against your repos and posts results — it doesn’t gate your merges or sit inline in production traffic. (The cross-domain rebuild proxy is the one inline component; it runs in your own VPC and fails safe by design.)
Is xounce available now?
Not generally. xounce is pre-launch and onboarding a small group of design partners — read-only, on one repo, at no cost while we build. Apply to run the gate on your code.
Why is it called xounce?
xounce comes from “bounce.” The whole platform does one thing: it bounces what shouldn’t get through back out — malicious code (the exploit gate refuses to report anything it can’t prove), malicious requests (the cross-domain track rebuilds every API payload), and technical debt (the auto-fix PRs). The X mark is the deflection.

Design-partner program · open

Run the pipeline on your repos.

You give us a repo and 30 minutes a week. You get every confirmed finding, its replayable proof, and the fix PRs — free, while we build. We get your feedback on what the gate got right and wrong.

Become a design partner Book a call