Recorded demonstrations

See privileged access the way an auditor sees it

Every session below starts with an approved change request and ends with evidence tied back to it. No shared passwords. No standing credentials. No screenshots — these are unedited recordings of the product doing the work.

Thirteen demos · databases, cloud platforms, servers and clusters · 3–5 minutes each (Remote Desktop 2:41)

Cloud platforms

Amazon Web Services 3:52

What the change request authorises

Create a VPC and a subnet.

What the operator also does

Opens SSH to the entire internet.

Cloud platforms

One approved change, a Jupyter notebook doing the work through the product, and a Change Request Security Review of the result. Standard requests — no cloud SDK, no product library. In each, the unauthorised action succeeds — the access genuinely permits it. Nothing is blocked. It is recorded, and the Security Review names it.

Databases

The same ticket serves a human at a GUI and an unattended script, and both are recorded. Each connects with a standard driver, runs the approved change, then runs one statement the change request never mentioned — and closes on the Security Review that flags it.

Servers and clusters

Native clients throughout: OpenSSH, Windows PowerShell, kubectl and mstsc. Remote Desktop differs by design — an RDP session is captured as a session replay rather than as statements, so it ends at the recording rather than a Security Review. There is nothing to compare statements against, and the demo says so rather than implying a check it does not perform.

The one idea

Most privileged access tools stop at “who was allowed in”. These demos are about what happened next.

Point 5 is the one worth watching for. In several demos the operator deliberately does something the change request never authorised. You can see the product say so.

  1. An approved change authorises the work — not a person, and not a credential.
  2. A ticket is issued against it. Short-lived, and it is the only secret on the operator’s machine. No password is ever revealed.
  3. The operator uses ordinary tools — DBeaver, a Python notebook, mstsc, kubectl. Nothing is modified, wrapped, or aware the product exists.
  4. Every privileged action is captured on the way through.
  5. A Change Request Security Review compares what ran against what was approved — and names anything that was not.

What “no credential” means here

The operator’s machine never holds a working credential for the target system.

Databases

The ticket is typed where a password goes. The database reports back a different account entirely — the one the product holds and the operator never sees.

Cloud

The ticket goes where an access key or bearer token goes. The provider answers to an identity that did not exist an hour ago: a service principal, a service account or an assumed role created for that single checkout and deleted at check-in.

AWS specifically

The ticket is both the access key ID and the secret. There is nothing to leak, because nothing on the machine is a credential anywhere else.

Close the laptop and there is nothing left to revoke.

What you are actually looking at

Real systems

Real cloud accounts, real databases, a real Windows domain. The resources created on camera exist; they are cleaned up afterwards.

Verified transport

Where traffic passes through the product, TLS is verified against the product’s own certificate authority. Earlier builds of these demos disabled certificate checking and that was removed deliberately — the Kubernetes recording is the one still awaiting a re-record, and you can see the flag left in its kubeconfig on screen.

Unedited sequences

Silence is trimmed so a 7-minute recording becomes 3–4 minutes, but nothing is sped up, reordered, or re-enacted, and no narration line was cut.

Identifiers obscured

Cloud account and subscription numbers are masked in a few frames. That is the only alteration made to any recording.

Every video ships with a subtitle track carrying the full narration, for accessibility and for viewers who would rather read than listen.

Frequently asked, honestly

Does it block the unauthorised action?

No, and that is deliberate in these demos. The operator holds genuine, time-boxed access, and inside that access the action is permitted. The product’s job here is to make it undeniable: attributed to a named person, tied to a change request, and flagged in the Security Review. Prevention is a policy question; these demos are about evidence.

Is the review deciding whether the change request and the execution matched?

Yes — that is what it attests. The first cut is built around security guidelines, and on top of that it examines the actions actually performed and scores how closely they match what was authorised. It speaks only to the execution — the change request itself was settled by your change process before the ticket existed. That scoring is in alpha today. It behaves well on the cases in these recordings, and it will keep improving as we train the models further. With design partners we can tune it to your own change vocabulary and control expectations — that is one of the more useful things to work on together.

What if the operator does nothing wrong?

Then the Security Review says so — approved work, performed, nothing outstanding. Several demos show approved statements passing untouched in the same session as the flagged one.

Are these recorded in one take?

The cloud and database demos are single continuous sessions. The server and cluster demos join a browser recording with a native-client recording, because a headless browser cannot drive mstsc or a terminal. Neither is re-enacted.

Want this run against your environment?

We are in validation testing and onboarding a small number of enterprise design partners.

Become a design partner →