Let agents do the work. Let your policies decide what they can do. Sensitive actions require clearance, and every decision traces back to an accountable human.
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.
Your infrastructureYour approval policiesYour choice of modelGEMBAOS / V0.2
01 / CORE PILLARS
Intelligence is flexible.
Authority is defined.
Three controls between an agent’s intent and an action in production.
01
One action. One clearance.
Keep credentials out of context.
Agents do not hold long-lived business-system keys. An approved request receives a single-use clearance token bound to its exact parameters. Change the parameters, and the clearance no longer applies.
Agents act on behalf of a named employee, within that employee’s authority. High-risk actions follow your approval chain. Decision records preserve who approved what, and why.
Use self-hosted or cloud models. Policy checks stay outside the model, while shadow replay and golden regression tests help verify behavior before a model change reaches production.
Give agents useful work, with a clear boundary around every sensitive action.
A production change,
without an open-ended key.
The challenge
Agents can help investigate incidents. Unrestricted production access is a different decision.
With GembaOS
The agent investigates in a restricted sandbox and drafts a ChangeSet. Privileged actions pass through the gateway and enter the change approval process.
The control pointCONTROL / 01
01
RequestDraft ChangeSet
↓
02
ReviewChange / CAB review
↓
03
AuthorizeIssue clearance
✓
04
ExecuteProduction adapter
↓
The human owner reviews the change. A parameter-bound clearance permits the production adapter to execute the approved action once.
An external message should never become authority to issue a refund or make a contractual promise.
With GembaOS
Customer sessions are isolated. The gateway checks the amount against your Delegation of Authority: within-limit cases can pass automatically; higher amounts need an Approval Request.
The control pointCONTROL / 02
01
RequestRefund request
↓
02
ReviewAmount / policy check
↓
03
AuthorizeFinance sign-off
✓
04
ExecutePayment adapter
↓
Finance approval authorizes a single payment-adapter call. The customer receives an official response, with the internal approval trail kept separate.
A CRM-resident agent can update a case. The moment the action leaves the CRM (a refund, a credit note, an account change) nobody is accountable, and the record of who decided lives with the vendor.
With GembaOS
The CRM stays the system of record for accounts and cases. GembaOS reads them under field-level rules, composes the cross-system action, and holds the approval record: routine closures pass on the agent’s stamp, escalated or legal-hold cases stop at a person.
The control pointCONTROL / 04
01
RequestCase event
↓
02
ReviewRead under FLS
↓
03
AuthorizeHuman sign-off
✓
04
ExecuteComment on the case
↓
The decision is signed with a passkey outside the vendor, executed once under a single-use clearance, and written back to the case timeline as a comment. Any agent, including the CRM’s own, can call this the same way.
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.
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 archived request in full: every field the approvers saw, the four signatures with their reasons, and the single-use clearance the execution will consume.
Every event of the run, in order: agent turns, policy decisions, capability calls, signatures, the clearance and the execution. Each line carries its hash; nothing is summarized away.
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 on this page is the Salesforce wire shape of the same pack.
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 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.
Every event of the run in order: the pre-read, the request, the signature, the precondition check, the closure, the comment on the case. Each line carries 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.
Four clearances.
HR hands IT the month-end leavers. The batch page turns the list into one aggregated request; the IT administrator signs once; every account is stopped on its own clearance. A typo in the list fails on its own row and stops nothing else.
One row replayed against the current policy: the route to the IT administrator, the rule chain, the signature.
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.
Shape the governance runtime with our architects. The program is designed for five enterprise partners per quarter, with focused adapter support and a path from shadow mode to controlled execution.
Consultation is free. Pilot scope and fees are agreed individually; eligible partners can agree a 24-month production price lock.
01Can we start before our SOPs are fully documented?
Yes. The Gap Register records missing procedures or ambiguous boundaries. Agents can draft proposed instructions; a responsible human reviews and approves them before they become operational policy.
02Do we need to rebuild our LangGraph or Dify agents?
Gateway Mode supports bringing your own agents. Route supported tool calls or MCP connections through GembaOS. We assess your tool interfaces and adapter requirements during the architecture consultation.
03Will approvals slow down everyday operations?
Low-risk reads and operations within configured limits can pass automatically. Only actions that require approval under your policy go to a human, such as above-limit refunds or privileged production changes.
04Can our data and models stay on our own network?
GembaOS can run on-premises or in a private VPC with self-hosted models. Cloud models and external integrations create their own data paths; configure these deliberately, including gateway-level field scrubbing where appropriate.
05How much time does our team need for the six-week pilot?
Our architects work alongside your team. Plan for an IT or DevOps liaison during setup and named business approvers during shadow mode. The exact effort depends on your integrations and is agreed when scoping the pilot.
LET’S START WITH YOUR WORKFLOW
Bring your constraints.
We’ll map the control points.
A free, 30-minute architecture conversation about your systems, your approval process and where agents could help.
GembaOS
We reply by email.
✓
Request sent
Thank you. Your request has reached us and we will reply by email.