The fail-closed auth and consent layer your AI product runs on. Licensed as an SDK.
Phase 0 sold Bouncer securing agents on AYA. This licenses the doorman. AYA Bouncer Platform is the same layer that secures AYA in production (PKCE on every OAuth handshake, keys held BYOK under a per-user KDF, consent minted as a revocable token instead of a checkbox, tenants isolated by row-level security, a per-message integrity sweep, a privacy egress boundary), packaged so your AI startup embeds it inside your product, and your audit trail starts with unambiguous identity, under your own brand. Deny is the default. Access is the exception that has to be earned every call.
Talk to us about embedding Bouncer
THE PROBLEM
AI teams are wiring agents into user accounts faster than they can prove who is acting and whether the user allowed it. OAuth is bolted on, keys sit in env files, tenants share a database and hope, and consent is a checkbox nobody can revoke. Then the enterprise security review arrives, or the incident does, and the first question is always the same: who authenticated, under what grant, and can you prove the user consented? Most AI products answer with a shrug. The numbers say this is the norm, not the exception: 80.9% of teams run agents but only 14.4% are security-approved, and 82% report shadow AI agents nobody can attribute an action to. And from August 2, 2026, the EU AI Act's record-keeping obligations make it sharper: Article 12 logging is meaningless if the log has no identity and no grant at the front of it. An audit trail must begin with unambiguous identity, or it does not begin.
HOW IT WORKS
Bouncer Platform is one fail-closed gate that runs BEFORE your capability does, not an alerting layer that tells you afterwards:
- identity first, every third-party connection goes through a PKCE-protected OAuth handshake, and the flow fail-closes at every rung (the full authorization, token exchange, validation, storage, and audit-logging workflow), - consent as a token, not a checkbox, minted per grant, revocable, checked at call time, - keys held BYOK, your users bring their own keys, held under a per-user KDF, never in an env file, - tenants isolated by construction, row-level security filters every capability by tenant, - a per-message sentinel sweep, every inbound agent message is sanitized against injection, checked for replay and ordering integrity, and authorized against the principal's actual grants, so impersonation and unauthorized tool use are denied, not detected, - a privacy egress boundary, outbound payloads get consent verified, PHI/PII scrubbed, and a receipt written before anything leaves the perimeter.
Every gate that fails denies. A verifier that errors denies. Nothing is waved through, and every sweep leaves an audit receipt, which is what gives your audit trail its beginning.
WHAT YOU GET
- the fail-closed front door as a component, embedded in your product, not a quarter of security engineering and not an OAuth library plus hope, - an audit trail with a real beginning, who authenticated, under what grant, with proof the user consented, on every action, - enforcement, not alerts, injection, replay, impersonation, and unauthorized tool use are denied before the capability runs, - a security-review answer, the artifact that clears the enterprise reviews your competitors stall in, because deny-by-default is demonstrable, not asserted.
WHO IT'S FOR
AI startups and platform teams shipping agents that touch user accounts or PHI/PII: agent platforms connecting Gmail, Drive, or Slack on a user's behalf, healthcare-adjacent AI, vertical AI SaaS heading into enterprise security review. Second, dev-tool and infrastructure vendors who want to resell a fail-closed auth/consent primitive inside their own AI stack. The buyer is the founder, CTO, or platform lead who owns the agent stack, with the Head of Security or DPO co-signing. If you want AYA to run auth for agents on AYA itself, that is the Phase-0 product (AYA Bouncer), not this SDK tier. If you only need a generic OAuth client library, this is more than you need.
PRICING (the ladder)
We price the ladder, not a single number, and every number below is a hypothesis we validate with you, not a commitment.
- Pilot license (hypothesis: $7,500 fixed), a bounded pilot: embed the fail-closed auth/consent gate in one product line, one environment, with our engineers on the integration. Proves the deny-by-default flow holds under your stack before anyone commits. - Usage metered (hypothesis: $150 per 1,000 monthly active principals), a production license metered on the users or agents actually gated through your deployment, with volume bands and a floor. - Platform, resale rights: white-label the auth/consent surface into products you sell onward, negotiated value-metered terms, annual minimum.
IP is licensed, never assigned. The enforcement surface stays ours, the audit trail is yours. Any step that takes your money is gated fail-closed and requires explicit human confirmation before it runs, nothing charges silently.
THE PROOF (dogfood)
We do not authenticate any other way. The layer being licensed is the security acolyte securing AYA itself in production today: every AYA capability is gated through Bouncer fail-closed, and the connect flow at aya.trizz.ai runs the same PKCE OAuth handshake, per-user KDF key custody, row-level-security tenant isolation, and consent-token minting this SDK would embed in your product. We hardened the exact seams a buyer will probe, in public, seam by seam: one unified OAuth contract, the PKCE keystone fixed, row-level security plus a per-user KDF on the linked accounts store, consent tokens minted by live callers. The deliverable and its supporting spans are committed, quality-gated pattern definitions whose references were verified on disk before this page was written.
HONEST NOTE
We would rather under-promise. What exists: the working Bouncer capability securing AYA in production, and the committed pattern corpus (the full OAuth workflow, the per-message sentinel sweep, the privacy egress boundary). What does NOT exist yet: the SDK. There is no client library, no stable versioned API contract, no packaging, no integration docs, and no external company has embedded anything. And one inherited gate we name rather than hide: a live third-party customer OAuth run on AYA itself is still owed behind a founder-gated deploy step, so the dogfood proof today covers the substrate securing AYA, not a completed external run. That is exactly why the call to action on this page is a design-partner conversation and not a checkout button: the first partner shapes the API contract with us, and an SDK cannot honestly ship an auth surface whose live proof its author still owes on itself. First tests, in order: close the live third-party OAuth proof on AYA, then define the SDK contract and land one design-partner embed with a receipt of the integration.
Talk to us about embedding Bouncer
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*