Security, before there is anything to secure.

Vibe Agents is pre-launch. There is no live product, no account, and nothing here executes a trade or takes custody of anything — so most of what a security page usually describes does not exist yet. This page separates the part that does from the part that is still a plan, and never mixes the two in one sentence.

01Where we actually are

Vibe Agents is pre-launch. This website describes software we are building and lets you join a waitlist. There is no live product, no account, and nothing here executes a trade or takes custody of anything. The only thing on this site that actually runs is a prompt parser inside your browser that draws a diagram.

That makes a security page awkward to write honestly, so this one follows a single rule.

Sections 02 to 04 are intent. Sections 05 and 06 describe the site as it stands. Section 09 collects what is not true yet into one list, so you do not have to work it out from what is missing.

02Non-custodial by design — intent, not yet a property

When the product launches it is intended to be non-custodial: a cell holds its own capital under limits you set, and Vibe Agents does not take custody of your funds or hold the keys to them. You would remain responsible for the limits you configure and the agents you choose to run.

Automated execution does not remove market risk. It acts faster, which can cut both ways — markets move against a strategy, infrastructure fails, and software contains defects. Non-custodial is a limit on us, not a protection for you: it would mean we cannot move your money. It would never mean your money is safe.

Today that is an intention, not a property you can verify. It stops being merely an intention when there is code to read and an independent audit of that code to read beside it. Section 04 is where we say when both arrive.

03The cell is meant to be the spending boundary

The intended model is small enough to state in four sentences. An agent has one job. Agents that share a goal form a swarm. A swarm lives in a cell. The cell is the only thing that can hold or move capital.

Limits would belong to the cell rather than to the agents inside it, and would be set before anything ran. None of the four below exists as code — each is a line in a design:

CEILING

The most capital the cell may put to work at all.

VENUE CAPS

How much of that may sit with any single venue.

ASSET ALLOWLIST

What the cell is permitted to touch, and nothing outside it.

DRAWDOWN FLOOR

The loss at which the cell stops instead of continuing.

Every action a swarm proposes is meant to be checked against those limits by the cell, before the action happens — not by the agent that proposed it. An agent asking for something outside the bounds is refused rather than trusted to police itself. That separation is the whole of the design, and it is why the cell, not the agent, is the thing worth auditing.

04What we will publish, and when

Two documents do not exist yet and will: the detailed security model, and the reports from independent audits of the code.

The audit reports and the detailed security model will be published before public launch — not before they are true.

Independent audits will be commissioned before any code touches real capital, and the findings go out in full, including anything unresolved. Nothing is booked yet. No firm is engaged and nothing is signed. When that changes, it appears here first.

Published in full means a report you can check rather than a badge you have to trust:

• Who performed the audit, and what they were asked to look at.
• The exact commit reviewed, and the date it was reviewed.
• Every finding, with its severity and its status.
• Anything still unresolved, left visible and named as unresolved — not quietly dropped when the page is next tidied.

On which gate applies to what, the stricter reading governs. Stage 1 — a single agent running on its own — is the stage that opens to the public first, so the audit and the security model are published before Stage 1 opens, not deferred to Stage 2. Swarm coordination is a separate body of code; it gets its own audit, published before Stage 2 opens.

05This website, today

Everything in this section is a statement about the site you are reading right now, and every one of them is checkable in what we deploy.

• No accounts. There is no login, no account, no wallet connect, and no web3 library anywhere on this site. /api/waitlist is the only endpoint any page here calls.
• No cookies. The site sets none at all. The only thing kept on your device is one browser storage key, va_waitlist_v1, holding your own signup so a dialog does not ask you twice on the same device.
• The builder runs in your browser. What you type into the agent builder is matched by a regular expression and laid out on a canvas locally. Prompts are not transmitted anywhere, are not sent to a model, and are not logged — unless you choose to attach one to a waitlist signup. The demo ends at ready — connect a cell to put it to work, because there is nothing further for it to do.
• React is served from our own domain. React 18.3.1 and ReactDOM 18.3.1 are vendored in the repository and served from vibeagents.xyz, so rendering this site does not depend on a third-party CDN being reachable. A fallback to unpkg exists for the case where those local files fail to load, and that fallback pins a SHA-384 Subresource Integrity hash for each script. The locally served copies carry no integrity attribute — being same-origin, they do not need one.
• A failure degrades rather than blanks. If the scripts do not load, a watchdog reveals the plain template, so you get readable text and working links instead of a black page.
• Analytics counts, it does not profile. Vercel Web Analytics sets no cookies, does not follow you across other websites, and is inert unless it is switched on for the project. No event carries an email address: an event holds a button name, a source label, an agent count, and whether the plan was a swarm.
• Corrections are not cached in front of you. HTML is served max-age=0, must-revalidate, and year-long caching is reserved for fingerprinted files under /assets. A page we fix reaches you on your next visit.

Four security-related response headers are set on every route by our own configuration. This is the complete list of ours, not a selection from it:

Our host adds two more of its own on top, which you will see on any response: Strict-Transport-Security: max-age=63072000, telling your browser to reach this domain over HTTPS only, and Access-Control-Allow-Origin: *, which is its default for public static files and is why anything on this site can be read cross-origin — there is nothing here that is not already public.

There is no Content-Security-Policy on this site today. That is easy to claim and easy to check, so we would rather tell you it is absent than let you assume it is not.

Two third parties are involved in loading this page: Vercel, which hosts it and keeps standard request logs as any host does, and Google Fonts, which serves the two typefaces — meaning Google sees your IP address when your browser asks for them. Both are described in our privacy policy, which is the single authority on data here. “No cookies” is not the same sentence as “no third-party requests”, and we are not going to let the shorter one stand in for it.

06The waitlist, specifically

One email address is the only thing this site ever asks you for. This is exactly what happens to it.

A signup record holds six things: the address; which button you signed up from; the address of the page you were on; the agent description you typed, if you came from the builder; the time; and the two-letter country code our host attaches to the request. Your IP address is not stored with the record. Our host keeps its own standard request logs, which include IP addresses — that is a separate thing from the record, and the privacy policy describes both.

Records live in our own storage on Vercel, not with a third-party form or marketing service. The storage path is derived from a keyed hash of your address — HMAC-SHA256 of the lowercased address under a secret held only in server-side configuration. That has two consequences, and they are the honest whole of it:

• Someone who knows your address but not the secret has no way to derive the path, so the record is not something they can fish for by guessing. The store is public-read, so anyone who obtains the exact path another way — a leak, a log, a mistake of ours — can read that one record.
• Because the path is the same every time, signing up twice overwrites one record instead of creating two.

The endpoint itself is deliberately small. It accepts POST, answers a preflight OPTIONS with an empty 204, and answers every other method with a 405. It refuses a write when a browser sends an Origin whose host is not ours. It stops reading a request body at 8 KB. It length-caps every field and strips control characters before storing anything. It rejects an address that does not look like an address. It carries a honeypot field no human ever sees, so a bot that fills it gets a cheerful 200 and nothing is written. If either server-side secret is missing it fails closed rather than storing anything, and errors come back as short generic codes while the underlying exception goes to our log, not to you.

There is no rate limiting on that endpoint, no web application firewall and no bot detection beyond the honeypot. That is a description of the current state, not a claim about its sufficiency.

07Reporting something

If you find a problem in this website or in /api/waitlist, email team@vibeagents.xyz. It is the address published everywhere else on this site and it reaches us directly. There is no security@ alias, no PGP key and no security.txt — a channel we do not yet watch properly would be worse than the one we do. X and Telegram are fine for everything else, but send a vulnerability by email and do not post it publicly before we have had a chance to fix it.

A useful report says what you found, where you found it, the steps to reproduce it, and what you believe it lets someone do.

What we commit to, limited to things we can actually keep:

• We acknowledge your report as quickly as we can, and always within ten business days.
• We tell you what we are doing about it, and keep you updated until it is closed out.
• We credit you by name or handle if you want that, and say nothing if you do not.

We are not promising a remediation deadline. A fixed number of days for a fix is the kind of commitment that is easy to write and hard to honour, and we would rather keep the two above.

Safe harbour

Our terms of use, section 08, tell you not to attempt to break, overload, or gain unauthorised access to the site or its infrastructure. This is a narrow, deliberate exception to that clause, and nothing wider than what is written here.

If you research this site in good faith and stay inside these rules, we will not bring legal action against you over it, and we will not ask anyone else to:

• Do not access, alter, or keep anyone else’s data. If you find a route to someone else’s record, stop at the proof and tell us.
• Do not degrade the service — no load testing, no denial-of-service testing, no automated scanning that harms availability for other people.
• No social engineering and no phishing, of us or of anyone else, and no physical testing of anything.
• Test only what we operate: vibeagents.xyz and its own endpoint. The third-party services we rely on are not ours to authorise testing against.
• Give us reasonable time to fix an issue before you publish it, and agree the timing with us rather than guessing at it.

Step outside those rules and this exception does not apply — section 08 of the terms does.

08Impersonation and phishing

A pre-launch project with no live app and a waitlist of people expecting one is exactly the thing that gets impersonated. So, plainly:

• Our only official channels are the domain vibeagents.xyz, x.com/vibeagentsxyz, t.me/vibe_agents, and team@vibeagents.xyz. Treat anything else as fraudulent.
• There is no Vibe Agents token, presale, airdrop, or investment round.
• We will never DM you first asking for funds, keys, or a wallet signature.
• We do not ask for private keys, seed phrases, or wallet signatures — and we never will. Anyone doing so in our name is not us.
• This site asks you for one thing: an email address, on a waitlist. Anything presented as Vibe Agents that asks for more than that is not this.

If you see something claiming to be us, tell us at team@vibeagents.xyz. It is the fastest way to get it taken down, and it warns the next person.

09What is not true yet

Read this section as the price of the rest. Each line is something this page does not claim, written out so you never have to infer it from an absence.

• No completed audit, and no audit report to read. Nothing has been audited. No firm is engaged and nothing is booked.
• No bug-bounty programme, no rewards, no payouts, no researcher hall of fame.
• No live system. No running cells, no funds under management, no uptime figures, no incident history — and no boast about never having been breached, because there is nothing yet to breach.
• No deployed contracts, no on-chain mechanism of any kind, no token.
• No production key management and no signing infrastructure. There is no production.
• No custody arrangement — no multisig, no cold storage, no qualified custodian, no insurance cover.
• No certifications. No SOC 2, no ISO 27001, no penetration-test certificate, no security whitepaper.
• No security team, no on-call rota, no round-the-clock monitoring.
• No guarantee about anyone’s capital. The limits in section 03 are a design for software not yet built, and a design has never been a guarantee.
• The roadmap is a plan, not a promise. Timing and scope can change, and features can be added, delayed, or dropped.

Describing what our code does is not a warranty. The site is provided “as is” and “as available”, and section 09 of the terms of use still governs that.