Built to protect the information behind the answer.

Security philosophy

Security is a product feature here, not a page we wrote after the fact. The design starts from a simple idea: a manufacturer hands us their product knowledge on the understanding that it stays theirs, and everything follows from protecting that.

We describe what the system does, and what it does not do. We do not claim data can never leak or that anything is impossible to attack. We tell you the controls, so you can judge them.

Data ownership

You keep ownership of everything you upload. We receive a limited right to process that content only to run the service you configure.

Your content is not used to train a shared model. It answers your assistants, and nothing else.

How the model is used

An assistant answers from the documents you have published, and is told to treat that material as evidence rather than instruction. It is built to refuse when the approved information does not support an answer, instead of filling the gap with a guess.

The retrieved text and the question are kept separate from the system rules, so instructions hidden inside an uploaded document or a visitor message are handled as data, not commands.

Storage and tenant isolation

Original documents live in private storage. Public visitors never receive a permanent link to a file; administrative downloads use short-lived signed links after an authorization check.

Every account is separated at the database level. Access rules run on the server on every request, and automated tests check that one account cannot read another. A tenant identifier from a browser is never treated as permission.

Website embedding

The visible script on your site is an identifier, not a key. It carries no documents, no model credentials, and no privileged logic.

Each assistant runs only on the website addresses you approve. Sessions are short-lived and signed. A copied script may show a launcher, but it cannot open a working session on a site you have not allowed.

Access control

Administrative accounts use verified email and server-side sessions, with roles that decide who can publish, who can manage members, and who can delete. Destructive actions ask for confirmation and re-check permission on the server.

Platform operators are held to a stricter bar than customers, and operator access is recorded.

Monitoring and audit

Privileged actions are written to an audit log: publication, domain changes, document and membership changes, exports, retention changes, and account deletion. Each entry records who did what, to what, and when.

The service is monitored for unusual use, and spending on model usage is capped per account so a spike cannot run away.

Export and deletion

You can export your originals and your structured data whenever you want. You can delete a document or the whole account on request.

Deletion covers the primary data, the derived chunks and embeddings, and the stored files. Copies held in backups age out on a documented retention window rather than lingering indefinitely.

Enterprise deployment

The managed service suits most customers. For organizations with stricter requirements, a customer-hosted deployment is on the roadmap, so the whole system can run inside your own environment.

Responsible disclosure

If you find a security issue, we want to hear about it. Email troy@orangefinagency.com with the details and we will follow up. Our contact is also published at /.well-known/security.txt.