PlatformDelivery BoardAutomation & RunbooksOutcome ReceiptsJust-in-Time ElevationCredential VaultGoverned SessionsDevices & DiscoveryPatch ManagementReporting & ExportsRoles & Multi-Tenancy
Verified AI OperationsThe Operation LoopCommanded AutonomyCompare the operating modelThe Verified Operation Spec
SolutionsFor MSPsFor Enterprise & Internal ITHealthcareLegalFinancial servicesMunicipal & Education
ProofOperation walkthroughSecurity & architectureVerified Operation SpecFive questions for your RMM's AIChangelog
CompanyAboutFounder's noteContact
PricingBuy 1–20 technician licenses onlinePlans — from $499 per monthCustom requirementsFoundation Circle
Log in

Home/Trust/Privacy

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.

Where your data sitsand the only two exits
WHERE YOUR DATA SITS, AND THE ONLY TWO WAYS IT LEAVES YOUR WORKSPACE · ISOLATED PER TENANT account, seat and billing records operation records and their evidence device and software inventory vault records — values never rendered product telemetry, identifiers masked Records for one customer are stored and queried under that customer's own boundary. An export you generate A PDF, JSON or CSV file that you create and send. It goes where you send it. We are not in the loop. Model inference The typed operation context only — no credential values, hostnames, device ids or tenant ids. ✕ NO ADVERTISING TRACKERS · NO SALE OF PERSONAL DATA · NO THIRD PARTY BUYS ACCESS TO YOUR RECORDS
The second exit is the one people ask about, so it is worth being exact: what reaches a model is a typed operation context. Credential values, session tokens, credential ids, real hostnames, device ids, IP addresses and tenant identifiers do not cross that line. The boundary, drawn in full →

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.