Privacy
What we hold, why we hold it, and what you can ask us to do about it.
Written to be read rather than to be survived. Where a specific belongs in a contract — a retention period, a region, the current list of sub-processors — this page names the category and points at the data-processing agreement, because a number in marketing copy drifts and a number in a contract binds us.
The shape of it
Two ways data leaves your workspace. Both are yours to control.
Most of what we hold never moves. An export moves because you built one and sent it. Operation context reaches a model because the work requires reasoning — and that context is filtered before it goes.
Who this policy covers
This policy covers people who visit this website, people who contact us about the product, and people whose personal data appears inside a Seraph workspace — including the technicians who use it and the end users whose tickets it resolves.
If you are an employee of an organisation that a managed service provider supports, and your details appear in that provider's workspace, they decide what happens to that data and we act on their instructions. Start with them; we will support them in answering you.
The two kinds of data
It helps to separate them, because they are governed differently.
- Our own data. Information we hold to run a business — who our customers are, who asked for a demo, who signed a contract, who emailed us about a vulnerability.
- Customer data. Everything inside a workspace: the operations, the evidence, the devices, the people named in a ticket. We process this on the customer's instructions, and the data-processing agreement governs it.
What we collect
Account and workspace data
The details needed to create and run a workspace: organisation name, the identities of the people you authorise to use it, their roles and permissions, and billing contact details. Where sign-in is federated with an identity provider, we receive the identity claims that provider releases and never your password.
Operational data and evidence
The record of work done through the platform: what was requested, who authorised it, the privilege that was leased and when it expired, what ran, what the target machine answered, the declared rollback, and the signature and chain values that make the record verifiable. Where a ticket or a chat message initiated the work, the content of that request forms part of the record.
Device and environment data
Inventory about the machines you manage: hardware and operating system attributes, installed software, when a device was last seen, and which operations have touched it.
Product telemetry
Diagnostics about how the platform itself is performing — errors, timings, and which surfaces are being used — with identifiers masked as described below.
Contact and website data
What you type into a form on this site, what you send us by email, and the ordinary technical information a web server receives when a page is requested.
Why we process it
- To provide the service you or your organisation asked for, and to let the right people into the right workspace.
- To produce evidence. The operation record is the product. Producing, signing and retaining it is a core purpose, not a by-product.
- To keep it secure — detecting misuse, investigating incidents, and enforcing the boundaries described on the trust page.
- To support you when you contact us, and to answer questions about how something behaved.
- To bill and to keep the records a business is required to keep.
- To respond to you when you ask about the product, apply to a programme, or report a security issue.
We do not sell personal data, we do not share it with data brokers, and we do not use customer data to build advertising profiles.
Customer data and the operation record
Data inside a workspace belongs to the customer who owns that workspace. We process it on their documented instructions, and the roles, obligations and permitted purposes are set out in the data-processing agreement that accompanies the service agreement.
Two properties of the operation record are worth stating plainly, because they interact with deletion requests:
- Records are sealed and chained. They are designed so that altering one is detectable. That is the property that makes them evidence, and it means an individual record is not quietly editable — including by us.
- Deletion therefore operates on whole records or whole workspaces, on the terms in the data-processing agreement, rather than by rewriting a field inside a sealed record. If a request requires removal, we will tell you exactly what can be removed and what the effect on the surrounding evidence will be.
What never leaves the privileged boundary
Some categories are architecturally prevented from reaching a model or an ordinary log, rather than filtered out afterwards: credential values and secrets, session tokens and API keys, credential and vault record identifiers, real hostnames, device and agent identifiers, IP addresses, and tenant and subscription identifiers.
The same masking applies to logs, traces, events, exports, support bundles and screenshots. The full explanation, with the boundary drawn, is on the trust page.
Where it lives, and who can reach it
Customer data is held in cloud infrastructure, in storage bounded per tenant, so that records for one customer are stored and read under that customer's own boundary.
The regions in which your data is hosted are agreed with you and recorded in your agreement. We do not publish a region list here, because the honest answer depends on your contract and we would rather you held it in a document that binds us.
Access by our own staff is limited to people who need it to run the service or to support you, is authenticated individually, and is logged. We do not browse customer workspaces out of curiosity, and a support engineer looking at your data is something you can ask us to account for.
Sub-processors
We use a small number of third parties to deliver the service. We describe them here as categories, and name each one individually — with its role, the data it touches, and where it operates — in the data-processing agreement:
- Cloud infrastructure and storage, which hosts the platform and the evidence.
- Model inference, which performs the reasoning step, receiving the typed operation context described above.
- Email and message delivery, for notifications and for the messages the platform sends on your behalf.
- Error reporting and product telemetry, for diagnosing faults.
- Support and business tooling — the systems we use to talk to you and to bill you.
Each sub-processor is bound by terms at least as protective as those we owe you, and we give notice before adding a new one so that you have the opportunity to object on the terms in your agreement.
How long we keep it
Different categories have different lives, and the periods are set in your agreement rather than here:
- Evidence and operation records are retained for the life of the workspace, configurable per client, because their value is that they are still there when someone asks.
- Account and billing records are kept for as long as the relationship lasts and for the period afterwards that we are required to keep business records.
- Product telemetry is kept on a rolling basis and is not retained indefinitely.
- Contact and enquiry data is kept for as long as the conversation is live, and after that for a limited period in case you come back.
On termination, deletion and return of customer data happen on the terms in the data-processing agreement. Ask for it before you sign, not after.
Your rights
Depending on where you are and which law applies to you, you may have the right to ask for a copy of your personal data, to have it corrected, to have it deleted, to receive it in a portable form, to restrict or object to certain processing, and to complain to a supervisory authority.
We honour these requests. Two practical notes:
- If your data sits inside a customer's workspace, the request usually has to go to that customer, because they decide what happens to it. Tell us anyway and we will help route it.
- We will need to be reasonably confident that you are who you say you are before we act — which is itself a data-protection measure, not an obstacle.
Security
The controls that protect this data are the product itself: leased privilege that expires, execution the model cannot pull a credential out of, verification performed by the machine that changed, and a signed record of all of it. We hold no third-party certification today and we say so plainly rather than implying otherwise here.
If you believe you have found a vulnerability, please tell us through the contact page on the security route. We answer, we keep you informed, and we credit you if you want to be credited.
This website
This site does not run advertising trackers and does not sell or share visitor data. It uses only what is necessary to serve the pages and to remember the choices you make while reading them. Forms on this site are used to reply to you about what you asked for.
Children
This is a product sold to businesses and it is not directed at children. We do not knowingly collect personal data from children, and if we learn that we have, we will delete it.
Changes to this policy
We version this policy and keep the previous versions available. When a change is material — a new category of data, a new purpose, a change in how long something is kept — we will tell affected customers rather than quietly re-publishing the page and hoping.
How to reach us about data
Write to us through the contact page and say what you are asking for. Privacy questions and security reports both reach a person, not a queue. If you are already a customer, your agreement names the contacts we have committed to.
The architecture is the answer
Most privacy questions about this product are really questions about the boundary.
What a model receives, what never crosses, how evidence is signed, and what a recipient can verify without us — all of it is drawn out on the trust page.