← Back to aisley Security & Trust

The defenses are architectural, not prompt-based.

Anyone can wrap a chat API. Aisley is the layer that makes an agent safe to put in front of your customers — checked on every reply, before it renders, by code that holds even when the prompt fails. A prompt is advice. These are walls.

No training on your data Origin-scoped keys Data at rest: US · Firestore AI disclosure: non-removable Fail-closed action model

Last updated 31 July 2026 · Autonomi Studios

The serving layer

Six walls between the model and your brand

Every reply passes all six before it reaches a visitor. A reply that violates a wall is replaced whole, not partially cleaned — because a half-rewritten sales sentence can change meaning.

WALL 01Price wall
A reply may only quote prices on your confirmed list — unioned with your live product roster — in your currency, to the cent. Anything else is replaced whole. The wrong-price chatbot judgment can't happen here.
WALL 02Claim wall
Returns, refunds, warranties, shipping promises, "I'll ship today" — if you didn't authorize the claim, the concierge can't make it. The price wall's peer, with no number required.
WALL 03Closed action allowlist
The agent can only invoke capabilities you declared. Unknown actions and phantom arguments are dropped; an action whose data failed to load fails closed, never fires on a hope.
WALL 04Origin-scoped keys
Your key runs on your verified domain and nowhere else. A copied key on someone else's site is inert. A live key with no proven origin does nothing.
WALL 05Budget governor
Hard caps per visitor, per tenant, and per account — enforced before the model is called. Over cap, the concierge degrades gracefully. It never runs an unbounded bill.
WALL 06AI disclosure
Visitors always know they're talking to an AI. Platform default, non-removable — EU AI Act Article 50 compliant out of the box.

01 The public key is safe to publish

Your site key sits in your page source. On its own, that would be a stolen-key waiting to happen. Three facts make it safe:

  • It is anonymous, rate-limited scope only. The public key can converse — it cannot configure. Configuration and knowledge writes use a separate secret key (sk_live_…) that never reaches the browser.
  • Two-tier origin scope. A pk_test_ key runs only on the origins you declared (a sandbox claim). A pk_live_ key runs only on origins whose ownership was proven — via embed-reflection, DNS, or a meta tag. A live key with no verified origin is inert. This separates may this key speak for this brand from is it set up, so open self-serve can never mint a live key pointed at a domain the signer doesn't own.
  • An Origin-independent rate limit. The origin check trusts the request's Origin header; a forged-but-valid Origin still passes it. So a per-key and per-IP request ceiling that does not depend on Origin being honest is the backstop behind it.
A key lifted from your page and pasted onto another site does nothing. That is enforced by the platform, not left to your vigilance.

02 Fabricated prices and policies — the Air Canada defense

In Moffatt v. Air Canada (2024), a tribunal held the airline liable for a refund policy its chatbot invented, and explicitly rejected "the bot is a separate entity" as a defense. When an agent speaks for your brand, a hallucinated price or policy is your legal exposure. Two walls close that surface:

The price wall

Every reply is scanned for currency-tagged amounts. If any is not on the union of your confirmed prices and your live product roster — or is tagged in the wrong currency — the whole reply is replaced with your safe line. It is cents-exact ($95.99 no longer slips past a $96 allowance) and roster-unioned, so it tracks your live feed, not a frozen array.

The claim wall

Moffatt was about an invented policy, not only a price. A fabricated "free returns," a "lifetime warranty," or a first-person commitment ("I'll ship that today") is the same exposure with no number in it — and the price wall never sees it. The claim wall detects policy- and commitment-shaped assertions and, unless the claim is substantiated by your human-confirmed allowed-claims list, replaces the reply whole. An empty claim list is safe: the agent routes policy questions to a human instead of inventing an answer.

03 Prompt injection — the blast radius is zero by construction

Prompt injection (OWASP LLM01) is the number-one LLM risk, and it is not "solved" by any prompt. Aisley assumes injection lands and makes it harmless:

  • Closed action allowlist. The agent can only invoke a capability you declared. Injection can steer the model's words; it cannot conjure an action off the list. Everything else is dropped.
  • Real-value validation, fail-closed. Even a declared action is dropped if its arguments name something you don't actually offer — and if the underlying list didn't load at all (say, your product feed was down), the action is dropped rather than forwarded on a hope. Forwarding a hallucinated handle is the exact "she said she'd open it and nothing showed" failure; it can't happen.
  • Server-side target resolution. The browser never interpolates model output into a selector or URL — it receives finished literals.
  • Nothing secret in the prompt. The system prompt is written to be adversary-readable, because it lives in a browser-reachable session. There is no secret to leak.

An input tripwire flags obvious injection payloads for logging and rate-limiting — defense in depth, never the primary defense.

04 Cost as an attack surface — the budget governor

A public key on the right origin can still be hammered, and open self-serve invites a sybil attack. Spend is capped before any model call, at three levels:

  • Per-visitor daily message cap and per-tenant monthly dollar cap, each with a degrade band.
  • Per-account and per-platform aggregate ceilings that sit above the tenant document. This matters because the tenant document is drafted from a customer's own site — so its own budget figure is attacker-influenceable and can't be the real backstop. The account ceiling lives where the customer can't set it, closing the "one email = unlimited platform keys" cost bomb.
  • A precondition: spending on a shared platform key at all requires a card on file or a verified origin — no skin in the game, no spend of our money.

Over any ceiling the agent degrades or captures an email — it never goes silent, and the strictest verdict always wins.

05 Voice token handling

The realtime voice token is authority to open a live audio session, so it is minted armored — single-use, short expiry — and the endpoint is the strictest gate: a per-tenant enable flag, a global kill switch, an origin check, and a per-IP daily cap. Voice tool-calls run through the same server-side action gate as text — the closed allowlist, fail-closed validation, and server target resolution — so a spoken action can't reach the page unvalidated.

06 Silent failure is a defect — action telemetry

An agent that drives the page has a failure mode a chatbot doesn't: it can say it acted while nothing moved — a selector drifted after your next deploy. Left silent, that is "one-and-permanently-invisibly-broken." So the widget never assumes success. It confirms an effect landed; on a miss it emits action_missed telemetry (feeding a selector-health heartbeat and a "your concierge stopped driving X" alert) and shows the visitor an in-panel fallback so they are never stranded.

The concierge never fakes an outcome. Actions like add-to-cart have no generic effect — they call your code or they do nothing, reported. It never pretends to have acted.

07 Your data: isolated, resident, and never trained on

  • Memory isolation. Visitor memory is keyed (tenantId, visitorId) — never the visitor id alone — so tenants sharing the platform can never read each other's visitors. There is no cross-tenant read path.
  • We do not train on your data. Your conversations and your configuration, knowledge, and content are never used to train, fine-tune, or improve any model — ours or a provider's. Requests go to our AI model provider under commercial API terms that grant no training rights over what we send.
  • Data residency. Persistent data lives in Google Firestore (Google Cloud) in a US region; request handling runs on Vercel. Full detail — including what we don't retain (raw transcripts) — is in the Privacy Policy.

08 What we honestly don't claim

A trust page that only lists strengths is marketing. Here is what we are careful not to claim:

  • Voice prices and policies are prompt-constrained, not wall-enforced. The server never sees the model's spoken audio words, so the price and claim walls can't run on them; the voice system prompt carries the same rules. Voice actions are fully walled; spoken quoting is not yet at parity with the text channel. We state this so the limitation is never mistaken for something it isn't. (Output-transcription-through-the-walls is the marked fix.)
  • We do not hold SOC 2 or ISO 27001 today. We will not claim a certification we don't have. What we offer instead is this: an architecture where the security-relevant behavior is enforced in code with tests, described here honestly, and demonstrable in the sandbox before you sign anything.

09 Responsible disclosure

If you find a security issue, tell us and we will work it fast. Email autonomistudiosllc@gmail.com with steps to reproduce and, if you can, the affected key or origin. Please give us a reasonable window to remediate before any public disclosure, and don't run tests that degrade the service for other tenants (the budget and rate ceilings exist partly to protect them). We welcome the report and will credit you if you'd like. [Registered address available on request.]