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/Proof/Security and trust

Trust center

Control before the action. Evidence after it.

This page is written for the person whose job is to find the gap. It is engineer-to-engineer, it uses the real vocabulary, and where we do not have something yet it says so in the first sentence rather than the last. If a line here cannot be demonstrated on a live system in under a minute, tell us and we will remove it.

Posture, in one screen
model boundaryThe model receives a typed operation context. Credential values, tokens, ids, hostnames and IPs never cross.
privilegeLeased per operation, scoped to one target, revoked on the clock.
isolationRecords and storage are bounded per tenant. Mapping runs one way only.
evidenceSigned, chained, and verifiable by the recipient without our cooperation.
certificationNone held today. Read the section — it is the first thing we would want to know.
disclosureCoordinated, credited, and we answer.

Model-blind execution

For governed machine work, the model does not receive a credential. Not masked — resolved outside its context.

Most "AI security" is a filter on the way out: the model gets the secret and something downstream tries to scrub it from the transcript. That is a redaction problem, and redaction fails eventually. We removed the problem instead. The planner is never on the same side of the wall as the value, so there is nothing to leak, summarise, or reconstruct.

The model boundarywhat crosses, what stops
LEFT OF THE WALL · THE MODEL RIGHT OF THE WALL · THE PRIVILEGED PLANE EVERYTHING THE MODEL RECEIVES OPERATION restart a stopped service TARGET "front-desk print server" RUNBOOK svc-spooler-restart v4 OUTCOME spooler running, queue clear RESULTS typed fields, nothing free-form The target is a label. Nothing on this side resolves to a machine, an account or a tenant. NEVER CROSSES, IN EITHER DIRECTION ✕ credential values and secrets ✕ session tokens and API keys ✕ credential ids and vault record ids ✕ real hostnames and DNS names ✕ device ids and agent ids ✕ IP addresses and network topology ✕ tenant and subscription ids Masked in logs, traces, exports and screenshots too. WHAT CROSSES: A REFERENCE {{credential.svc_admin}} resolved · session authenticated The executor resolves the reference to a value and authenticates the connection before any step runs. WHAT DOES NOT CROSS: THE VALUE THIS WALL IS CODE. IT IS NOT AN INSTRUCTION IN THE PROMPT. Nothing returns a secret to the planner — not redacted, not masked, not summarised.
The generated step contains a reference, never a value. The reference is resolved on the privileged side and the connection is authenticated before the first generated instruction exists — so a compromised or confused model cannot mint access it was never handed.
  • A reference, not a secret. A plan carries {{credential.<name>}} tokens. Substitution happens on the executor, after the model is done.
  • Authenticate first, generate second. The privileged session exists before the model's step does. The step inherits a connection; it does not create one.
  • Typed results on the way back. What returns to the planner is a structured result with named fields, not a raw console transcript that could carry anything a machine happened to print.
  • Identifiers are aliased. Hostnames, device ids, IPs, tenant and subscription ids are resolved on the privileged side. The model works against labels.
  • Masked everywhere else too. The same rule applies to logs, traces, events, exports and screenshots — because an exfiltration path through a support bundle is still an exfiltration path.
The one exception, named There is exactly one surface where a human-readable account name reaches the model: an interactive browser sign-in, where the account chooser is on screen and the user picks an account. That discloses a user principal name and nothing else — the password is injected after the model's step is generated, and the model never sees it. We would rather name this than let you find it.

Model-blind execution is about credentials, not about omniscience. The model still reasons over operation context, results and runbook text, and that context is a real surface — it is why results come back typed and why we keep identifiers out of it. See Credential Vault for the checkout mechanics.

Leased privilege

Rights that expire on a clock, not when the task finishes.

There is no standing service account with domain admin sitting behind this product, and there is no shared break-glass credential that a technician passes around. Privilege is minted for one operation against one target, and it is taken back on expiry whether the work is done or not.

  1. Request

    The operation declares what it needs to reach the outcome. It asks for a capability against a target, not for an account.

    Recorded: the justification, the operation id, the requesting identity

  2. Policy check

    Tenant policy decides whether this class of work, on this class of target, may proceed and whether a human has to say so first.

    Recorded: the policy that applied and the decision it produced

  3. Grant, scoped twice

    The lease is bound to this operation and to this target. It is not a role you now hold; it is a key cut for one door and one errand.

    Recorded: both scopes and the expiry timestamp

  4. Work

    The connection is authenticated with the leased identity immediately before the step executes. When a technician takes work back from the agent, a fresh lease is minted under their own name — the AI's lease is never inherited.

    Recorded: every identity that acted, in the same operation

  5. Auto-revoke

    Expiry fires on the clock. A lease that outlives its work is a standing privilege with extra steps, so we revoke on time rather than on completion.

    Recorded: when the rights ended, and whether anything tried to use them after

Answers a reviewer usually asks next
shared accountsNone. Every acting identity is attributable to a person, a machine identity, or a designated vault record.
break-glassExists, is deliberate, is time-boxed, and produces the same record as anything else — including the fact that it was break-glass.
elevation sourceDirectory-backed where the target is domain-joined; a designated local managed account where it is not.
rotationA vault record is a stored credential a human may also use. Managed means we own its rotation, and a record only becomes managed after a deliberate designation — we never silently take ownership of a password you stored.
after expiryThe operation cannot continue. It stops, records where it stopped, and asks for a person.

Full detail on the lease mechanics is on Just-in-Time Elevation, including the exposure comparison against a standing admin account.

Evidence integrity

A record the recipient can check without asking us.

Evidence you can only verify by logging into the vendor's dashboard is not evidence — it is a claim with a login screen in front of it. The export carries what a third party needs to check it on their own machine.

Signing and independent verificationthe chain
HOW A RECORD IS SEALED Recorded facts Authorization, lease, job, the target's answer, the undo. Canonical form Fixed field order, then hashed. No free prose. Chained Carries the fingerprint of the record before it. Signed By a key the model and the agent never hold. AND HOW ANYONE ELSE CHECKS IT — WITHOUT ASKING US EXPORT · PDF, JSON, CSV — THE SIGNATURE AND THE CHAIN TRAVEL WITH THE FILE The signature Check it against the published key. No call to us. Works offline. The chain Recompute each fingerprint and compare it to the record that follows. The confirmation row It can only carry what the target answered. The model cannot write it.
The signing key lives in a key vault on the privileged side. Neither the model nor the endpoint agent can reach it, which is why a compromised agent can lie about a machine but cannot produce a record that verifies.
What the chain does, precisely
what it detectsAlteration. Change a sealed record and every record that claims to follow it stops agreeing with it.
what it is overThe set you hold. A verifier recomputes fingerprints across the exported records and compares each to its stated predecessor.
who can signThe platform. Not the model, not the endpoint agent, not an operator.
failed operationsSealed too. "No response captured" is a recorded outcome, not a gap.
mid-flight changesA plan that changes is itself a recorded event that rejoins the same operation, rather than a second operation with a tidier story.

We will claim exactly this and no more: the chain makes alteration evident across the records you hold. It is not a distributed ledger, there is no third-party notary, and we would rather say that than let the word "immutable" do work it has not earned. See the receipt itself →

Isolation and access

Walls between customers. One rail for every connection.

Per-tenant isolation

Records, evidence and inventory are bounded per tenant, and every read is scoped to the boundary the caller is operating in. Mapping between tenants runs one way only: an MSP primary may reach into its own sub tenants, and any tenant may reach within itself. Sub tenant to primary, and sub tenant to sub tenant, are never permitted — and that rule binds AI actors exactly as it binds people.

Roles & multi-tenancy →

The gateway is the only rail

Every connection to a managed endpoint — human or AI, remote desktop or command execution — rides one authenticated multiplexed connection out to the gateway. There is no inbound listener to expose on your side and no second private path for the AI. The gateway re-authors remote input rather than forwarding what a client sent, so a client cannot assert bindings the target has not agreed to.

Governed sessions →
Endpoint and transport facts
directionOutbound from the endpoint to the gateway. Nothing needs to be published inbound for us to work.
remoting modesTwo, and they are different things. RDP means native RDP. Seraph Remote is our own capture path. We do not blur them and neither should a comparison.
unmanaged targetsNo agent means no tunnel and no credential creation. Identity has to be vaulted or held by you, and work is brokered from a managed neighbour. That is a constraint, not a smaller feature set.
concurrencyTwo remote-desktop sessions cannot hold the same target at once. Conflicting session types are resolved before a connection opens, not stacked on top of each other.
agent trustThe agent reports; it does not adjudicate. Verification answers are checked on the privileged side, and the agent cannot sign a record.

On session capture we are deliberately narrow. We describe governed launch, authorization, binding to an operation, and what the operation record carries. We do not claim complete multi-surface session recording and playback, and you should treat any vendor who does as owing you a live demonstration. What is and is not covered →

Data handling

What we hold, where it sits, and what we do with it.

Customer data
what we holdWorkspace and seat records, operation records and their evidence, device and software inventory, vault records, and product telemetry.
where it sitsIn your workspace's own storage, under your tenant boundary. Regions are agreed with you and recorded in your agreement, not published here where they could drift.
evidence retentionHeld for the life of the workspace, configurable per client. Periods and deletion commitments are set in the data-processing agreement.
secrets in artifactsCredential values, tokens and identifiers are masked in logs, traces, events, exports and screenshots. This is enforced in code, not by reviewer discipline.
what a model receivesThe typed operation context only. Nothing that identifies a machine, an account, a tenant or a subscription.
sub-processorsNamed individually, with role and location, in the data-processing agreement, with notice before we add one.

Retention numbers, regions and the current sub-processor list belong in a contract, not in marketing copy that can drift. Ask for the DPA and hold us to it. The plain-English summary is on our privacy page.

Assurance

The controls an audit would sample are the product itself.

Privilege that is leased and expires. Execution the model cannot read a credential from. Verification performed by the machine that changed. A signed record of every one of those facts. Every operation produces the evidence an auditor would otherwise have to go looking for — so assurance here is a query against real operations rather than a sampling exercise once a year.

  • The control and the evidence are the same object. There is no separate audit-logging system to fall out of sync with what actually happened.
  • No standing privilege to attest to. "Who has admin?" has a different shape here, and the answer is a list of expired leases with names attached.
  • Evidence per operation, on demand. Any reference number resolves to a sealed record — who authorized it, what ran, what the target machine confirmed, and the declared undo — exportable for your own reviewers or your client's.
  • Questionnaires answered in full. Send your own security questionnaire, a CAIQ or a SIG. We complete them, and we mark an unknown as an unknown rather than as a "compensating control".
Where we are on SOC 2 SOC 2 Type II is on our roadmap and the report is not in hand yet. We will publish it when there is a report to publish, rather than a letter saying an engagement has started. What is available in the meantime is the thing a report exists to give you confidence about: the evidence itself, per operation, generated by the system as it works and exportable to you directly. If a completed report is a hard gate in your procurement process, raise it on the first call and we will tell you plainly where we are.

What you can verify for yourself, right now

This is the part that should matter more than a badge. All six of these can be done inside a demo, on a machine you control, without taking our word for anything.

  1. Watch what the model is actually handed

    Ask to see the context a planner receives for a live operation. Check it for a credential value, a real hostname, a device id or a tenant id. If one is there, the central claim on this page is false and you will have found it in four minutes.

  2. Ask for a lease and then wait

    Have an operation elevate, then watch the rights disappear on expiry rather than on the work finishing. Then try to use them.

  3. Break the confirmation

    Have the operation succeed, then make the target fail the check anyway. The record should carry the machine's answer, not the AI's opinion of its own work.

  4. Take an export away and verify it offline

    Leave with a signed export. Check the signature and recompute the chain on your own machine, with no call back to us.

  5. Try to edit a record

    Alter a sealed operation and re-run verification. Every later record should stop agreeing with it.

  6. Put the six tests to us cold

    The Verified Operation Spec is vendor-neutral and we published it knowing it would be used on us. Ask all six on the call and watch which ones get a straight answer.

A certificate tells you an auditor sampled a set of controls on a date that has already passed. A demonstration tells you what the system does on your machine today. We would rather you had the second one, and we would rather say that than imply we have the first.

Coordinated disclosure

Found something? Tell us, and we will credit you.

What we commit to

  • We acknowledge the report and tell you a human has it.
  • We triage it and tell you what we think it is, including when we think it is not a defect.
  • We keep you informed until it is closed, and we say when it shipped.
  • We credit you by name if you want to be credited, and stay quiet if you do not.
  • We do not threaten researchers who act in good faith.

What we ask

  • Do not test against another customer's workspace or endpoints. Ask us for one to work in.
  • Do not exfiltrate, retain, or publish customer data — a proof of access is enough.
  • Do not run availability tests against production.
  • Give us a reasonable window before disclosing, and tell us if you need it to be short.

Send it through the contact page on the security and architecture route. It reaches an engineer, not a queue.

Bring the hard questions

Every claim on this page is meant to be attacked on a live system.

Book the review, bring your questionnaire and the finding from your last penetration test, and we will work through them on the call rather than after it.