Home/Solutions/For enterprise IT
For internal IT and shared-service desks
Move the work forward. Keep control at every step.
Seraph is not a second approval authority and not a new system of record. A request arrives through the desk you already run, your approver approves it in your process, and then one box in that pipeline runs differently: admin rights leased for minutes, execution the model is blind to, and a verification answered by the machine that was changed. What comes out is the record that closes your change.
Where it lands
One box in your pipeline. Everything either side of it stays yours.
The fastest way to fail an internal audit is to end up running two change processes — the documented one, and the one a tool made you adopt. So we do not ask for a second one. Intake, classification, approvers, the change advisory board, the maintenance window and the change record all stay exactly where they are.
What stays exactly where it is
- Your service desk. Requests arrive from Teams, Slack, or a help desk — ask us about your specific tooling on a demo.
- Your change classification and your standard-change catalogue.
- Your approvers and your board. Their decision is what authorizes the work.
- Your maintenance windows and freeze periods.
- Your change record. Ours attaches to it; it does not replace it.
What we deliberately do not do
- We do not become your system of record for change.
- We do not approve on your behalf. A policy can only narrow a human's authorization.
- We do not hold standing admin on your estate in order to work.
- We will not ship a mode where nobody's name is on the work.
- We claim no hard native integration with a named change or service-management product. Name yours on a demo and we will answer straight.
Separation of duties
The thing that did the work is not the thing that says it worked.
This is the question a reviewer is actually testing. In most automation one party executes and that same party attests — the tool runs the job, and the tool writes the line that says the job succeeded. Seraph moves the attestation onto the machine that was changed, which means no party in the operation holds two duties.
Walls inside one workspace
Shared-service desks, separate business units, one console.
A central IT function usually serves units that do not share data, budgets, or auditors — and sometimes do not share a legal entity. The isolation model is the same one a service provider uses for its clients: each unit is a sub tenant, with its own records, storage, policies and branding.
Records do not cross
Operations, receipts, credentials and reporting are scoped per tenant, and dedicated storage is available where a unit requires it. A unit's evidence export contains that unit's operations and nothing else.
Roles & multi-tenancy →Trust runs one way
The parent workspace can map into its own sub tenants, and any tenant can operate within itself. Sub tenant to parent, and sub tenant to sibling, are never permitted. The same rule binds AI agents, not only people — an agent cannot reach what its tenancy cannot reach.
How the boundary is enforced →One operator, several contexts
Scope is identity multiplied by business unit, and a platform engineer may legitimately hold more than one live context at once. Switching between them is something they do many times a day, so how fast it is and how many clicks it takes are product qualities, not settings-page details.
Scope and roles →The programme, not the feature
Standing admin is the finding. Leases are the remediation.
Nobody buys leased privilege in the abstract. They buy it after being shown the list of accounts that hold permanent admin rights on their estate — including the ones created during somebody else's temporary elevation, which is the category nobody has a report for.
-
Count what actually exists — in two places
Privileged roles and the accounts that carry them in your directory, and separately, membership of the local Administrators group on every managed endpoint. Those are different lists and they disagree.
-
Give every finding a disposition
Three outcomes, all recorded: lock it down, hand us its rotation as a managed account, or deliberately leave it open with a named owner and a written reason.
-
Replace the rest with leases
Rights minted per operation, scoped to one target, with the justification recorded and the revoke landing on the clock rather than on the work finishing. Break-glass accounts remain, declared and few.
-
Prove nothing was left behind
We hold both halves of the correlation: the ledger knows exactly who was elevated, when, and on which machine, and the endpoint can enumerate its local administrators. A membership change that appears inside an elevation window is the finding you actually wanted.
Honest about maturity: leased privilege, model-blind execution, target verification and the signed record are what the product does today. The privileged-access census is work we do with you during onboarding — it is a real artifact, produced by people using the platform, not a button. Turning it into a standing control that runs on a schedule, fires an auto-disable or an auto-takeover, and honours a whitelist is on the roadmap and written in future tense, which is where it belongs until it ships.
For the person who answers the auditor
Evidence that does not require your word for it.
Internal audit rarely disputes that you did the work. What they push on is whether you can evidence it without asking the same team that did it to write the summary.
| The control being tested | What usually gets offered | What the operation record carries |
|---|---|---|
| Privileged access is granted only when needed and removed afterwards | A quarterly access review, and trust in the interval | A lease per operation with its scope and expiry — revoked on the clock, not on completion |
| Changes are authorized before they are made | An approval in one system and a change in another, joined by hand | The authorization and the work are the same record, under one id |
| Changes are verified after implementation | The tool that ran it reports success | The changed machine answers an independent check, and that answer is the row |
| A back-out exists and was considered beforehand | A sentence in the change request | The reversal declared before execution, and executable from the record |
| Audit records cannot be altered after the fact | Logs an administrator can edit | Each record carries the fingerprint of the one before it |
| Automated tooling operates within defined limits | A policy document describing the intent | The privilege each operation actually held, and what the model was given |
This table describes what the record carries. It is not a claim that we satisfy a framework on your behalf — no product does that for you, whatever its footer says. Our SOC 2 position and what we supply in the meantime are set out on the trust center.
What internal IT leads ask us first.
Do we have to move our service desk?
No. Requests reach an operation from Teams, Slack, or a help desk, and the change record you already keep stays the record. We are not going to claim a hard native integration with a named service-management product on a marketing page — bring yours to a demo and you will get a straight answer about what exists today.
Who approves — your policy engine, or our people?
Your people. Policy is the floor; the human is the ceiling. A policy can narrow what a person authorized — smaller scope, shorter lease, a tighter target set — and it can never create an authorization nobody gave. Standing authorization for a certified runbook class is a decision a named person makes and it is recorded as such, so the record still names a human.
What happens if a step fails, or the AI cannot finish?
It stops safely and hands the operation to a person, and it still signs. A failed operation is a real recorded outcome: what was attempted, what privilege it held, where it stopped, what the machine reported, and whether the declared back-out ran. When your engineer takes over, a fresh lease is minted under their own identity and the work continues in the same operation and lands in the same record — it does not fork into a second change. How takeover is recorded →
What does the model actually receive?
The operation type, the target, the runbook, and the outcome to reach. It does not receive credential values, tokens, or credential identifiers — a credential reference is resolved to a value by code, on the far side of that boundary, and the connection is authenticated before any generated step exists. The trust center draws the boundary exactly, including what is masked in logs and evidence.
Where are you on SOC 2?
SOC 2 Type II is on the roadmap and the report is not in hand yet — we would rather you have that from us on the first call than find it in a questionnaire. What is in hand is the evidence such a report samples: every operation produces a signed record you can export and check yourself, without our cooperation. Both the position and the verification steps are on the trust center.
How is it priced for an enterprise?
Per operator, with tenancy for your business units. There is no published number and there is no self-serve sign-up — the shape depends on how many units you need isolated and how your desks are organised, so it is a conversation. The pricing page says the same thing, and says it in one line rather than three paragraphs.
Bring the control you are least able to evidence
We will run an operation and open the record it produces.
Fifteen minutes, live, on a real system. Bring your last internal-audit finding about privileged access — we will answer it on the call rather than after it.