GembaOS
GembaOS case recordings and control walkthroughs
These recordings explore one mechanism at a time. For how the same team works across a day, start with the working-day guide.
One company, one continuing day
GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC.
INSIDE GEMBAOS
From request to a traceable decision.
One captured flow per scenario, from the real console. Pick a flow and follow it through the screens: the pending desk, the human signature, the execution, the audit replay.
A refund request, start to finish.
Follow one refund request through the whole approval flow: the pending desk, the human signature, the executed refund and the audit replay.
Three agent stamps are in place. Before deciding, the human supervisor sees the machine-verified facts and, in plain words, what approval sets in motion: the effect, the amount and its ceiling, how long the clearance lasts, and what is re-checked before it runs.
One click on the same form opens the exchange the request came from: what the customer wrote, what the front desk sent back, the ticket number. It is rebuilt from the work item’s own record, not fetched from a chat tool.
The supervisor signs with a passkey. The request is archived with four signatures and a one-time clearance is issued.
The archived request in full: every field the approvers saw, the four signatures with their reasons, and the single-use clearance the execution will consume.
The refund is executed under that clearance and the customer receives the official answer. Every step is on the sealed timeline.
The event log of the run, excerpted: the first events and the last. Agent turns, policy decisions, capability calls, signatures, the clearance and the execution are all recorded in order, and every line carries its hash.
Every decision is replayed against the current policy. The route, the rule chain and who signed at which step are all on record.
Close the case in your CRM. Keep the decision here.
An escalated case is closed from GembaOS: the supervisor signs outside the CRM, the host reads the case again and closes it once, and the decision goes back to the case as a comment. The CRM in this capture is Salesforce.
The closure of an escalated case stops at the CS supervisor. The form shows the case as it stands, trimmed to the fields the specialist may see, and the reason for closing it.
The supervisor signs with a passkey. The request is archived and a single-use clearance is issued for exactly this case and this reason.
The host reads the case again, compares it with what the approver saw, then closes it under the clearance. The mirror writes the decision back to the case timeline as a comment.
The event log, excerpted: the first events and the last. The pre-read, the request, the signature, the precondition check, the closure and the comment on the case are all recorded in order, each line with its hash.
The decision is replayed against the current policy: the route (escalated, so a person), the rule chain and who signed.
Four accounts. One signature. Nobody typed a list.
The directory sync offboards them inside the system and opens one aggregated request to stop their accounts; the IT administrator signs once; every account is stopped on its own clearance. The ID HR misspelt fails on its own row and stops nothing else.
The sync pulled the export: four removed, four offboarded, and the batch it opened, with the sync on the record as the initiator on the IT engineer's behalf.
One approval request carries every row with the account as it stands before the change. The misspelt ID shows as a row whose record could not be read.
The IT administrator signs once. Four clearances are issued, one per account, each bound to its own arguments.
The signature resumes the batch on its own. Three accounts are stopped; the unknown one fails alone and is reported, and the batch goes on.
One row replayed against the current policy: the route to the IT administrator, the rule chain, the signature.
Say it in your own words. Confirm before it starts.
An employee explains what they need on the internal request page, in as many messages as it takes, and leaves the business to the entry's assistant. The assistant proposes which of the businesses this person may start fits, and the task in their words. The system checks the proposal, and nothing starts until the employee hands it over. In this recording the assistant is the demo stand-in, not a language model.
The first message asks for a triage and a runbook lookup. Both businesses fit, so the assistant proposes both, shows the employee's words each one rests on, and asks which is meant. No work item exists yet.
"The triage first" settles it. One proposal is left, and its task keeps what was said before. The employee can edit the task, then hands it over.
The receipt names the business, the ticket, the handler and the next step. The agent's reviewed report comes back in the same thread.
The operator console, its menu grouped by use. The conversation opens with what was said before the hand-over, so the handler reads the whole request.
The record: the entry conversation attached under the employee's name, the external ticket linked, three gaps recorded, the report reviewed and the official answer issued, then done. The agent only read logs; nothing changed state.
An alert at night. Read-only hands.
A monitoring alert starts a triage run with nobody at the desk. The agent may only read logs; its reviewed report goes to the owner. What it lacked, it filed as gaps and as a knowledge draft that waits for a person.
The run read the logs, kept facts and inference apart, ignored the instruction planted in a log line, and its reviewed report reached the owner. No approval, no clearance: nothing changed state.
What the agent lacked is on the register: a runbook, a hand-over rule, an on-duty contact. Each with who should own it.
The runbook it proposed is a draft in the review queue. It becomes knowledge only after a person approves it; until then no agent can cite it.
The event log, excerpted: the first events and the last. The signal, the reads, the redaction of a leaked secret, the gaps, the review and the report are all recorded in order.
The model reads the claim. People decide it.
An investigator model reads what came in and briefs the case; GembaOS holds every value it read to the claim record. A small, confirmed claim with nothing flagged is signed by the playbook’s rule; a receipt that differs from the record, or a large claim, goes to people, who read the brief instead of every page.
At intake the investigator sorts the photo. An accident claim needs a medical record and a receipt, so GembaOS asks the applicant for both itself; nobody on the desk has touched the case yet.
The documents came in and the investigator read them again: the amount and the date on them each match the claim record. The amount is above the fast lane, so the adjuster proceeds.
The adjuster’s form opens on the brief: the documents against the record, the files one click away, then what approval sets in motion.
The claims manager opens the request after the adjuster signed: since they last looked, one signature added with the finding covered, then the one decision left and the brief.
A small claim the brief stops: the clinic receipt totals $180.00, the claim $120. The line is marked “Differs”, the fast lane stays shut, and the adjuster signs. The reserve is still the amount on record.
A small storm claim: the invoice matches the record, the applicant confirmed, nothing is flagged. The playbook’s rule signs within the tenant’s authority matrix; the reserve is booked under a clearance and read back.
Captured from the console: sample records, simulated signatures
Beyond static captures: explore a live tenant.
Launch an isolated tenant of your own, complete with realistic audit logs, approval requests, and signature chains. You can even test its defenses: modify an order after signing off, and watch the runtime host re-verify the record and reject execution before any funds move. Your tenant is strictly isolated and automatically destroyed when you leave.
The model in the demo follows a preset script and does not self-censor. Every policy refusal and block you observe is enforced deterministically by GembaOS, not by the model behaving well.
Last updated: · GembaOS v0.2