Your audit trail starts with unambiguous identity, or it doesn't start.
AYA Bouncer is fail-closed auth, consent, and crypto for AI apps. Every capability is gated by who authenticated and whether the user actually allowed it, before anything runs. PKCE on every OAuth handshake, keys held under your own custody, tenants isolated by row-level security, consent minted as a token you can revoke. Deny is the default. Access is the exception that has to be earned every single call.
Wire up Bouncer Read how we secure ourselves
THE PROBLEM
Almost every AI app is wiring agents into user accounts faster than it can prove who is acting. OAuth gets bolted on at the edge and hoped over, keys sit in an env file, tenants share one database and leak into each other, and consent is a checkbox nobody can actually revoke. It works until someone asks the question that matters, who authenticated, under what grant, and can you prove the user consented to this. Most teams answer that with a shrug. And the question is coming, from a buyer's security team, from a regulator working through the EU AI Act, from an incident review at 2am. Eighty percent of teams are running agents, only about one in seven has security sign-off, and most report shadow agents nobody can even attribute an action to. The audit trail everyone is being told to keep has no beginning, because nobody made identity the first thing that happens.
HOW IT WORKS
AYA Bouncer inverts the default. Instead of bolting auth on at the edge, it makes identity and consent the front door that every capability has to pass through:
- Fail closed, always. A capability that can't confirm identity and consent returns denied, not a hopeful yes. There is no fail-open path, because a fail-open auth layer is not an auth layer. - PKCE on every handshake. OAuth flows run with proof-key-for-code-exchange, so an intercepted code is useless to whoever intercepted it. The connect flow verifies the user, then mints consent. - Keys stay yours (BYOK). Bring your own key, held under a per-user key-derivation function, with a register, validate, and revoke lifecycle. AYA never has to hold a key it could leak. - Tenants can't see each other. Row-level security isolates every tenant at the database, and capabilities are filtered by tenant before they run, so one customer's agent can't reach another's data even by accident. - Consent is a token, not a checkbox. Consent is minted as a revocable token the audit trail can point to, so 'the user allowed this' is a fact you can show, and 'the user withdrew it' actually takes effect.
WHAT YOU GET
The front door for your AI app. A user connects a third-party account, or brings their own key, and the whole flow fail-closes at every rung, PKCE handshake, identity verified, consent minted, keys custodied, tenant isolated. What comes out the other side is an audit trail that begins where it is supposed to, with who authenticated, under what grant, with proof the user said yes. Every other thing your agent does can point back to that beginning.
WHO IT'S FOR
Founders and platform teams shipping AI agents that touch real user accounts. Healthcare-adjacent AI carrying PHI, agent startups connecting Gmail or Drive or Slack on a user's behalf, anyone walking into an enterprise security review or staring down the EU AI Act Article 12 logging obligation that binds on August 2, 2026 (and logging without identity and consent at the front of it is just noise). If your agent acts as somebody, this is how it proves it.
PRICING (the ladder)
- Pilot. Drop-in fail-closed OAuth, PKCE, and consent tokens for one AI app.
- Subscription. Managed auth, consent, and key custody as you add platforms and tenants.
- Platform. The AYA Bouncer SDK, the auth and consent layer wired into your own stack.
(Prices are hypotheses we are validating, not commitments carved in stone.)
THE PROOF (the dogfood)
This one is not a demo we stood up for the pitch. AYA Bouncer is the security acolyte that secures AYA itself, in production, today. Every AYA capability is gated through Bouncer fail-closed, and the live connect flow runs the exact same PKCE handshake, per-user key custody, tenant isolation, and consent-token minting this product sells. We hardened the precise seams a buyer will probe, one unified OAuth contract, the PKCE keystone, row-level security and a per-user key-derivation function on the linked-accounts table, consent tokens minted by eight live callers. We run our own agents through Bouncer before we would ever run yours. Of everything in the early lineup, this is the one piece that already carries production weight.
HONEST NOTE
I want to be straight about what is done and what is not. The substrate is real and deployed, it secures AYA in production, and the OAuth, BYOK, consent, and RLS corpus is dogfooded on our own agents. What is not yet done is a one-click live run for a stranger, two gates are still founder-held, applying row-level security in the staging tier and capturing a live third-party OAuth proof end to end. So this is capability-ready and production-wired on us, not self-serve for you yet. That is the honest line, and I would rather you hear it from me than find it later.
Wire up Bouncer
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*