Where your data lives, and what never touches a model.
Confidentiality is not a paragraph in a contract. It is an architecture. Here is ours.
Your obligation to your customers does not transfer to a vendor. So the question is not whether we are trustworthy. It is what we structurally can and cannot touch. This page answers that in plain terms, and it is written to be handed to whoever runs security at your company.
It runs in accounts you own
This is the part that matters most and the part most vendors reverse. Your automation does not live inside a Tesray platform that you rent access to. It runs on accounts in your company's name, holding your data, billed to you. Your AI platform account and everything it stores, your operating and billing systems, your e-signature account, your forms, and any mailbox we create for a project: yours from day one.
There is usually one small connector that has to run somewhere, because forms and payment services announce events by sending a message and something has to be listening. Where that lives is a decision we make with you, and it transfers to your account at handover.
Nothing trains on your data
The AI platforms we build on are used through their business APIs and enterprise services, which do not train their models on the information you send. Your data is not used to improve anyone's product, including ours.
What never reaches a model
A model sees what a step needs and nothing else. Where a step touches protected data, that data is masked or de-identified before the model is called, and the identifying values are re-joined afterwards on your side of the line. Payment details, credentials, and anything the job does not need are never in the prompt at all.
Regulated and protected data
We work with protected data classes. The pattern is the same every time: masking or de-identification before any model call, compliant managed services where the data requires them, and the agreements that class of data calls for signed before any of it is touched. For healthcare and similarly regulated data that usually means building on a service such as AWS Bedrock inside your own cloud account, so the data never leaves your tenancy and the provider's compliance program covers the model layer.
Three ways to deploy
- Business-grade cloud APIs. The default, and right for most work. Enterprise terms, no training on your data, scoped access.
- Inside your own cloud. The system and the models run in your AWS, Azure or Google account. Nothing leaves your tenancy, and your existing security controls apply to all of it.
- On premise. Models running on your own hardware, for data that cannot leave the building. The most secure option, with real tradeoffs in model capability and maintenance. We facilitate it when it is necessary.
Each automation touches only what it needs
Access is scoped per job, not granted in bulk. An automation that drafts a document does not get read access to your whole billing history because it happened to be convenient. Before anything runs on real data we walk you through the full data map: what is read, what is written, what is sent, and where.
Credentials never live in documents or in code
API keys, tokens and passwords exist only as environment settings on the running service. They are not in the source code, not in any handover document, and not in email. Secret values are handed over once, through a channel you agree to, and rotated on handover as a matter of routine so that no old copy stays valid.
If we stop working together, you keep everything running
- The accounts are already in your name, so nothing has to be extracted from us.
- Any hosting we run transfers to your account without downtime or reconfiguration.
- The source code goes to a private repository you are given access to.
- Any automation trigger running under our login is reinstalled under yours.
- Admin tokens and mailbox passwords are rotated at handover.
- You get a written record of everything handed over, and when.
It handles process, not judgment
Everything we build automates the administrative chain around your work: capturing details, preparing routine documents from your own templates, tracking what has been signed and paid, and telling the right person what needs attention. It does not exercise judgment, and it is built so it cannot. Anything calling for judgment is routed to your team, and any document it prepares waits for a person to approve before it goes anywhere.
Common questions
Where does our data actually live?
In accounts held in your company's name that you control: your AI platform account, your operating systems, your forms and mailboxes. We are given scoped access to build and maintain. We do not hold your data on a platform of ours.
Is our information used to train AI models?
No. The AI platforms we build on are used through their business APIs and enterprise services, which do not train on the information you send. Your data is not used to improve anyone's product, including ours.
Can you work with regulated or protected data?
Yes. Protected data is masked or de-identified before anything reaches a model, and where the data requires it we build on compliant managed services such as AWS Bedrock inside your own cloud account, with the agreements that class of data calls for signed before any of it is touched.
Can it run inside our own cloud, or on our own hardware?
Yes. The default is business-grade cloud APIs. Where the data or the policy requires it, we deploy inside your own AWS, Azure or Google account so nothing leaves your tenancy. Fully on-premise deployment, with models running on your hardware, is the most secure option and one we facilitate when it is necessary.
Who at Tesray can see our data?
Access is scoped to the job and granted by you on accounts you own. Before anything runs on real data we walk you through the full data map: what is read, what is written, what is sent, and where.
How are our passwords and API keys handled?
They exist only as environment settings on the running service, never in source code, handover documents or email. Values are handed over once through a channel you agree to, and rotated at handover so no old copy stays valid.
What happens to the system if we stop working with you?
It keeps running and you keep the keys. Accounts are already in your name, any hosting transfers to your account without downtime, the source code goes to a private repository you can access, and every credential is rotated. You get a written record of the handover.
Can the system make a judgment call on its own?
No, and it is built so it cannot. It automates the administrative chain around your work. Anything calling for judgment routes to a person, and any document it prepares waits for approval before it goes anywhere.