Book a demo Buy online
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
Book a demoBuy online

Home/Platform/Credential Vault

Privilege

Put credentials to work. Keep them outside the model.

For governed machine operations, the credential is resolved inside your tenant before the session exists. The model receives a reference and typed results; the steps that run afterwards carry no credential value. Web sign-in is a narrow exception, described below, because the secret is part of establishing that connection.

Inspect credential handlingRead the trust centre
What the model was givenOP-000217
operationservice recovery
outcome to reachprint queue accepting jobs
runbookrestart print spooler · v4
what the target isa print server at this customer
credentiala reference · no value, no id
the passwordnever delivered
hostname, device id, IPnever delivered
the session was authenticated before this prompt existed MODEL'S VIEW

The boundary

A reference crosses the wall. A value never does.

Everything on the left is what the planner holds while it decides what to do. Everything on the right happens inside your tenant, in your own execution context. The two lists at the bottom are the only traffic between them.

The blind boundaryOP-000217
THE BOUNDARY THE PLANNER · THE MODEL Everything it is given the operation type — service recovery the outcome to reach — print queue accepting jobs the certified runbook to use, by name and version what kind of machine it is — a print server a stand-in where a secret would go the structured result of each step that ran AND NEVER, IN ANY FORM ✕ any password, key or token ✕ the id of the vault entry it came from ✕ the machine's real hostname, device id or IP ✕ your tenant and subscription identifiers THE EXECUTOR · INSIDE YOUR TENANT Where the value lives 1 — RESOLVE the reference becomes a value, inside your tenant 2 — AUTHENTICATE the session to the target opens under that identity 3 — RUN the steps run inside the session, carrying no credential 4 — RETURN the checkout closes; the value was never written down THE SCRIPT THAT RUNS CARRIES NO CREDENTIAL AT ALL WHAT CROSSES {{credential.password}} a stand-in, not the value — and not a pointer into your vault. WHAT NEVER CROSSES the password itself ✕ stops here — every time, in every mode, including when it fails.
The order is the mechanism. Steps two and three cannot be swapped — the session is already authenticated before there is any work to describe, so there is no moment at which a credential could be handed to a model and then taken back. Nothing is redacted, because nothing was sent.

The sequence

The credential is spent before the script exists.

In Windows the credential attaches to the connection, not to the action. That is not a Seraph invention — it is why "the AI never sees a password" can be true rather than aspirational.

  1. The operation checks out an identity

    The checkout happens in your execution context, bound to this operation and this target. The value is redeemed inside your tenant's trust boundary and held in protected memory.

  2. The session is established under that identity

    The connection to SRV-ACCT-02 is authenticated and authorized before a single step is described. From here on, the identity is a property of the open session.

  3. Only now does the work get defined

    The runbook's steps — or, where nothing fits, a plan a person has read — run inside that already-authenticated session. They contain no username, no password, no token, because they do not need one.

    A generated step carrying a credential is a design smell here, not a substitution opportunity

  4. The checkout closes

    The session ends, the credential is returned, and the operation record shows that it was checked out and given back. The value is in no log, no trace, no screenshot, and no receipt.

One case genuinely works differently, and it is worth naming. A web sign-in requires the secret as part of the connect itself, so there is no pre-authenticated session to inherit. There, the model drives the navigation and emits named stand-ins — {{credential.username}}, {{credential.password}} — which local code on your side fills in, or the operator injects into the focused field with a keystroke. The model still never receives the value. It is a narrow exception with an origin allow-list, not the general design.

Lifecycle

Designate, check out, use, return, rotate.

A credential moves through five states and only some of those transitions belong to an operation. Knowing which is which is the difference between a password safe and something that can be audited.

The life of a vaulted credentialwhat the record keeps
DESIGNATE a human decides we own this account CHECK OUT bound to one operation and one target USE it authenticates the session, not a step RETURN the checkout closes and cannot be reused ROTATE a new password, stored, never shown EVERY OPERATION CHECKS OUT AGAIN — NOTHING STAYS HELD AFTER ROTATION THE NEXT CHECKOUT GETS THE NEW VALUE WHAT THE OPERATION RECORD CARRIES NOT AN OPERATION ✓ CHECKED OUT ✓ WHAT IT OPENED ✓ RETURNED ✓ ITS OWN RECORD Never the value. Never the vault entry's id. The record shows that a credential was used, and that it was given back.
Designation is the only transition a human has to make deliberately, and it is the one that matters most. Discovering an account does not make it managed — finding a privileged account tells you it exists, not that you have been asked to own its password.

A vault record

A password-safe entry: the credential material and its metadata. The difference from the safes you already know is that we let the operator use it — checked out, it becomes an identity the operation authenticates with, rather than something to copy and paste into a separate console.

A managed account

An account whose lifecycle we own — which means its rotation. An account becomes managed only when a person deliberately designates it. These are two different objects, and conflating them is how organisations end up surprised about which passwords are being changed.

Why the split mattersCheckout is your statement of intent. Once a credential is checked out for a target, the operations menu uses it implicitly — you are not asked to pick the same credential again at session launch, and you are never dropped at a password prompt. Ambiguity is never resolved by guessing: when several held credentials could apply, nothing binds and the reason is stated.

Rotation

What we actually rotate, and what we do not.

Rotation is the capability that separates a vault from a filing cabinet, so it is worth being precise about its edges rather than selling the word.

  • Directory accounts you have designated as managed — the new value goes back into the vault, and the next checkout gets it.
  • Local managed accounts on enrolled machines, where the agent gives us a way to set and then verify the new password by authenticating with it.
  • The result report excludes the password. What comes back to the control plane says a rotation happened, not what it produced.
  • Rotation is a recorded operation in its own right, with its own record, rather than a background job you find out about later.
  • Discovery does not designate. Finding a privileged or service account during a scan puts it on a list. It does not put us in charge of its password.
  • We do not claim SSH key rotation. The path exists in the codebase; it is not something we will stand behind on a sales call today.
  • No agent means no credential creation. On a discovered machine with nothing enrolled there is no tunnel, so identity has to be vaulted already or held by the client.

Separately: rotating our own platform secrets and connection strings is a programme we have deliberately deferred, and it is unrelated to the product capability above. If that distinction matters to your security review — and it should — ask about both by name, and we will answer both.

Where values live

Per tenant, per customer, and never in a prompt.

Handling
storageIsolated per tenant. One customer's vault is not reachable from another's workspace, and the same wall binds an agent as binds a person.
who resolves itYour side of the boundary, in your execution context — not the planning service.
in the receiptThat a credential was checked out, what it authenticated, and that it was returned. Not the value, not the entry's id.
in logs and tracesNever. The same rule covers screenshots, events, exports and anything a model observes.
emergency accessStill checked out, still named, still recorded. Break-glass is a policy path, not a spare account in a drawer.
offlineA local encrypted cache and a queue of intent, so a machine that lost its connection is not a machine that lost its audit trail.

Just-in-Time Elevation

What the checked-out identity is allowed to do, for how many minutes, and how the rights end on the clock.

Read next →

Roles & Multi-Tenancy

How the walls between customers are drawn, and why an MSP primary may map into its own sub tenants but never the other way.

See the trust direction →

Trust centre

The same boundary in engineer's language, plus where we stand on SOC 2 and what we supply today.

Read the detail →

The questions people ask about the vault.

How is this different from redacting secrets from prompts?

Redaction assumes the secret reached the boundary and was removed. Here it never arrives: the session is authenticated first, and the steps that follow contain no credential to remove. The failure modes are not comparable — a redaction bug leaks a password, and there is no equivalent bug on this path because there is nothing on the wire to leak.

Can a technician still use a vaulted credential themselves?

Yes, and that is deliberate. A vault record is a password-safe entry we also let you use. Checking one out makes it an identity for your operations rather than a second place to launch sessions — you should never be asked to select the same credential twice.

Does the AI choose which credential to use?

No. The operation names what it is doing and the platform derives the identity and the least privilege that requires. The model is not the thing that resolves a credential, which is precisely why it cannot be talked into resolving the wrong one.

What ends up in the receipt?

That a credential was checked out for this operation, what it authenticated, and that it was returned — alongside the lease, the job, and what the target machine answered. Outcome Receipts shows the whole artifact, and the spec gives you the yes/no test to put to any vendor, us included.

Can I verify the claim rather than believe it?

Yes, and it is the second of the six tests we publish for exactly this purpose: can the model retrieve a credential value at any point? Ask it of us on a demo and ask it of everyone else you are evaluating. Five questions for your RMM's AI has the follow-up that ends the conversation.

Bring your security reviewer

Watch us try to make the model reveal a credential.

Fifteen minutes, on a live system: we run an operation, open what the model was actually sent, and let you ask for the password.

Book a demoRead the Verified Operation Spec
← PreviousJust-in-Time ElevationTemporary access scoped to the work Next →Governed SessionsRemote access that leaves a record