It reads your systems.
Every write is one you granted.

Numbers come from your data, not from the model. Figures are resolved by code against the source; the model narrates them. Every output retains:

• Source attribution — file, system or URL, with timestamp.
• Transformation history — what code ran, with what inputs.
• Calculation chain — every number resolves to source.
• Author and approval log.
• Immutable version lock — the sent version is reproducible.

StoriBot uses frontier AI models served through OpenRouter (a Stripe company). You choose which model runs each task, trading price against performance, and we’ll help you make those calls. You can also elect a secure_llm set — models served under terms that prohibit data collection and enforce zero retention, with no fallback outside that set.

• Hosted on AWS Sydney (ap-southeast-2). Storage, processing and the audit trail stay in region.
• Inference is the exception — the prompt goes to the model you chose, which may be served outside Australia. With secure_llm on it is neither collected nor retained there; see Training and retention below.

Turn on secure_llm and every request is sent with data_collection: denied, zero_data_retention: true and fallbacks: denied — so only models under those terms can serve it. If none is available the request fails rather than quietly falling back to one that collects.

The frontier providers in that set also contractually exclude training on API data.

Leave it off and you reach the wider catalogue, including cheaper open-source models that carry no such terms. It is your call, per instance.

StoriBot draws on three kinds of source, each held under the same controls: uploaded files (PDF, Word, Excel, Markdown), live data from your connected systems, and grounded web search — where external facts are cited, so they trace to source like everything else.

Two ways to connect. Either you generate a scoped API token at the provider and we hold it in AWS KMS, or — where the provider supports it — you approve StoriBot at the provider itself over OAuth. On that second route we never hold a secret you typed, and you can withdraw consent at the provider without going through us. We are moving connections to that model wherever it is available.

Grants are per operation, not per system. You choose what a connection may read and whether it may write. The split is not a property of the system — the same connection can read performance data back and publish a post, and you decide which of those it does.

Reads are the default. Every write is one you granted — nothing in a connected system changes as a side effect of drafting. Two switches govern this, and they answer two different questions:

• What the model does with your data. With secure_llm on, inference is restricted to models under zero-retention terms, and a request fails rather than falling back to one that collects.
• What the system can do to your systems. One instance-level switch disables every write and irreversible operation. What a granted write can do is bounded by the operation itself, not by what StoriBot sent — that can extend to changing or removing what is already in the system. Flipping the switch costs you whatever those writes were doing; reading, drafting and review all keep working.

• It does not write to a connected system as a side effect of drafting — only when you send, and only to a connection you granted write rights to.
• It does not read anything outside the sources you connect or upload. There is no crawl of your wider environment.
• It does not decide what to say. Every draft passes a review gate before it can be sent.
• It does not train on your data. With secure_llm on, neither do the providers behind it.

• Per-user authentication (Cognito / SSO).
• Access set per share link — public, access-code or authenticated, with its own subset of pages.
• Audit log of every access event.

Every instance today is logically isolated on shared Australian infrastructure, with credentials scoped per instance and no cross-customer access.

A fully dedicated deployment — separate infrastructure, customer-managed encryption keys, network isolation — is not something we run today. We are open to building it, and for a customer whose risk position requires it that is a conversation worth having early, because it shapes timelines rather than being a setting we can switch on.

• 24-hour incident notification.
• Post-incident report within 5 business days.
• Customer-nominated security contact.