THE GOVERNANCE LAYER FOR AI AGENTS
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.
See the approval flowAn agent proposes. Your organization authorizes.
01 / CORE PILLARS
Three controls between an agent’s intent and an action in production.
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.
Clearance Token · argsHashDelegation without extra privilege.
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.
On-Behalf-Of · Signature ChainYour rules outlast a model version.
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.
Model Agnostic · Policy Replay02 / IN PRACTICE
Give agents useful work, with a clear boundary around every sensitive action.
Agents can help investigate incidents. Unrestricted production access is a different decision.
The agent investigates in a restricted sandbox and drafts a ChangeSet. Privileged actions pass through the gateway and enter the change approval process.
The human owner reviews the change. A parameter-bound clearance permits the production adapter to execute the approved action once.
See it in the consoleAn external message should never become authority to issue a refund or make a contractual promise.
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.
Finance approval authorizes a single payment-adapter call. The customer receives an official response, with the internal approval trail kept separate.
See it in the consoleAs work moves between agents and departments, context and accountability can become difficult to follow.
A persistent Work Item tracks the workflow. Specialist agents receive only the context they need, with Separation of Duties across roles.
Each transition leaves an auditable record. Required decisions route to the designated human owner.
See it in the consoleA 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.
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 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.
See it in the consoleINSIDE GEMBAOS
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.
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. The human supervisor sees the machine-verified facts, the amount and the reasons before deciding.
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.
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.
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 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.
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.
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.
The list is pasted as it came from HR. The page parses the rows and shows which capability, which actor and how many items; the host still decides.
One approval request carries every row with the account as it stands before the change. The typo 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.
Resume executes every row on its own clearance. 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.
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 ledger: 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.
Every event of the run: the signal, the reads, the scrubbing of a leaked secret, the gaps, the review, the report.
Actual console capture · isolated demo data · stub model · mock passkey
03 / SECURITY & DEPLOYMENT
Concrete controls. Deployed where your business runs.
A single binary, deployed on-premises or in a private VPC. Use self-hosted models when inference must also remain within your network.
PRIVATE DEPLOYMENTBusiness-system credentials are held by the gateway and adapters, outside the agent’s prompt context.
CREDENTIAL ISOLATIONRe-evaluate recorded policy decisions and inspect hash-chained audit events to understand why an action passed or stopped.
DETERMINISTIC POLICYReview test cases covering prompt injection, parameter tampering and privilege escalation with your technical team.
RED-TEAM VALIDATIONDeployment boundaries depend on the models and integrations you configure. Review the architecture and test evidence for your environment.
04 / DESIGN PARTNER PROGRAM
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.
Program detailsSelect a workflow, connect your directory and define delegated authority.
Integrate target systems. Run golden regression and adversarial tests.
Agents draft work. Designated human owners review every proposed action.
Enable agreed low-risk actions and review weekly audit evidence.
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.
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.
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.
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.
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
A free, 30-minute architecture conversation about your systems, your approval process and where agents could help.
We reply by email.
Thank you. Your request has reached us and we will reply by email.