Server-owned rules.Not a polite prompt.
Chatbots are asked to behave. ClientSupport is built so it can't misbehave: the model only proposes, and the server decides.
A prompt is a suggestion. A server rule is a wall.
Most AI support tools put the rules in the prompt and hope. One clever message later, the bot is promising a refund, leaking a policy or acting on the wrong account.
- Rules written in the prompt, where a customer can talk around them
- The model picks which account to act on
- One model writes and grades its own answer
- No record of what was tried and denied
- Refund language slips through as “we'll make it right”
Everything between a model and your customer.
Each layer runs in the server loop, the same way, whichever model wrote the draft.
Identity gate
No account tool runs until the customer is verified by a signed app token or an email code. Verification expires after 30 minutes and never moves between conversations.
Role checks
Billing portal and upgrade links are server-restricted to owners and billing admins. Members see docs, diagnostics and resets, never billing links.
Server-owned tools
The model can only request a tool. The server validates verification, role, rate limits and arguments, and supplies the workspace id itself.
Template-only billing
Conversations that touch money are answered from approved templates, not free text, so a clever paraphrase can't create a promise.
Input judge
A separate judge reads the customer's message for oblique money asks and injection attempts before the model responds.
Dual cross-family reply judges
Two reply judges from different model families review every draft. Either one can block it, and a blocked draft becomes a safe handoff.
Audit log and kill switch
Every attempt, including denials, is logged before it runs. One switch turns off all account tools, and any single tool can be disabled by name.
What it does on its own
- Verifies identity before any account is read
- Reads live status and runs read-only diagnostics
- Sends password resets only to the account's own email
- Creates billing portal or upgrade links for owners and billing admins only
- Logs every attempt, including denials, before it runs
- Hands edge cases to you with the full story attached
What it will never do
- Issue, promise or hint at refunds or credits
- Change, cancel or discount a plan by itself
- Reset two-factor authentication
- Trust a workspace or email the model invented
- Change data in your app beyond resets and billing links
- Send a reply either judge rejects
scripted support and attack conversations run on every build.
Before any customer goes live, the production judges must pass a live catch-rate gate: each reply judge at least 90%, both together at least 99%, and the input judge at least 95% on oblique money asks.
- Account lookups before verification
- Account ids supplied by the model
- Reset emails steered to another address
- Poisoned docs and prompt injection
- Refund, credit and plan-change requests
- Prompt and canary leaks
- Email-code brute force and lockout
- A model outage mid-conversation
Isolated, minimized, accountable.
Per-product isolation
Every table carries the product id, enforced with row-level security.
No card data
Billing happens on Stripe-hosted pages. The chat never sees card numbers.
90-day transcripts
Conversation transcripts expire after 90 days. The audit log is kept.
Masked logs
Emails are masked in system logs, and app secrets never reach the model.
Autonomy you can actually trust.
Apply for early access and we'll show you the guardrails live, including the attacks they stop. Month-to-month, no annual lock-in.