Architecture whitepaper (public overview)

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. This page is the public reading edition of the GembaOS enterprise architecture whitepaper (document GEMBA-WP-2026-PUB, v1.0.0, 16 September 2026), written for CISOs, CTOs, CIOs, enterprise architects and risk, compliance and audit professionals. The full edition, with the data structures, the clearance issuance algorithm, the adapter specification and the red-team report, is available on request.

Why do enterprises keep agents out of production?

GembaOS starts from one observation: what keeps agents out of ERP systems, production databases and privileged domains is not the model’s reasoning, but that the existing stack cannot answer four questions a risk committee asks.

1. Authorization: who authorized each write and each configuration change the agent made?
2. Accountability: when prompt injection or a hallucination causes a loss, who is the accountable person?
3. Data boundary: which sensitive fields did the agent read across its turns without authorization?
4. Replay: how do we prove to a regulator or to legal audit that every step of the decision chain reproduces deterministically?

API gateways, LLM guardrails and system-prompt constraints do not answer them. They carry no approval semantics, and they assume “trust the model first, intercept after the incident”. While an agent only produced text, the reader carried the risk; once it can call APIs, text-level defenses are not enough: a guardrail that is bypassed exposes every API behind it, and an agent holding a long-lived credential can write beyond its brief while planning on its own.

What are the architecture principles?

GembaOS assumes no implicit trust: instead of relying on the model’s good behavior, it compiles the company’s authority rules, maker-checker review, separation of duties and regulatory baseline into rules a machine enforces deterministically. Four principles run through the runtime.

• Strict on-behalf-of delegation: when an agent acts for an employee, its effective permission is the intersection of the agent’s role, the employee’s own authority and the boundary the current playbook declares. Financial data the employee may not see, the agent cannot read for them; a purchase order the employee may not approve, the agent cannot approve for them. This is On-Behalf-Of.
• No accountability gap: there is no unowned autonomous action. Every work item, every read and every approval request is bound to a natural person in the company’s IAM or SSO.
• Data boundary at the gateway: unauthorized fields and unnecessary context are trimmed at the capability gateway and never enter the model’s context; database reads go only through read-only views with a declared column list and parameterized procedures, never free-form SQL.
• Model-agnostic, zero drift: approval rules, business contracts and security boundaries are independent of the model. Replacing a self-hosted model with a cloud frontier model, or the reverse, leaves the governance rules unchanged; shadow replay and golden tests show the differences before the switch.

How does the four-gate engine work?

GembaOS passes every sensitive state change through four gates in order: policy decision, signature chain, single-use clearance, and the host’s reality check.

How are data, artifacts and the audit record governed?

GembaOS labels every record with a classification, a business domain and a data residency, and keeps every event of a work item in an append-only hash chain.

• Artifact classification: code changes and reports an agent drafts are managed as governed artifacts. A ChangeSet takes the highest classification of the files it touches; an artifact leaving the sandbox (a merge, a delivery, an outbound message) is a governed action that passes the same policy decision and signature.
• Meeting room and knowledge boundary: a raw meeting transcript never becomes an instruction directly; only the scribe agent drafts minutes, and only after the chair signs them off do they become a work item. A confidential document the caller may not read answers “not found”, exactly as a document that does not exist, so nothing can be probed.
• Hash-chained audit record: every event of a work item is appended and linked by a cryptographic hash chain; a modification, deletion or reordering breaks the chain, and integrity can be verified at any time. The log is an ordinary file the company may keep on WORM storage of its choice for forensic and non-repudiation requirements; GembaOS ships no WORM storage of its own. Audit replay re-runs recorded decisions against the current policy.

How do existing systems and existing agents connect?

GembaOS wraps existing systems as governed capabilities through modular adapters, so nothing is rewritten, and interoperates with existing assistants and agent frameworks through MCP in both directions.

• Outbound: a legacy system becomes a standard MCP tool that the company’s existing Claude, Copilot or Cursor can call; every call passes the four gates.
• Inbound (bring your own agent): an agent built on LangGraph, Dify or a similar framework points its tool endpoint at the GembaOS gateway and gains approvals and clearances without changing its orchestration code.

Can we start before the SOPs are written?

The GembaOS Gap Register lets a company start safely without a complete set of procedures: when an agent meets an undefined procedure or boundary, it reports the gap and does not overstep.

1. The agent hits an undefined procedure or boundary, records the gap with a proposed draft, and does not guess.
2. The register merges gaps of the same kind and routes them, on a schedule, to the desk of the responsible owner.
3. The owner reviews on the review desk with a passkey; an approved procedure enters the governed knowledge library and the gap closes.

In daily operation the agents thereby turn the company’s scattered tacit knowledge into structured, compliant assets.

How do the controls map to compliance frameworks?

GembaOS maps the control requirements of the main cybersecurity, AI and financial-regulation frameworks to the mechanisms it has built; the mapping is our own assessment and has not been reviewed by an audit firm. As of 16 September 2026 GembaOS holds no SOC 2, ISO 27001 or ISO 42001 certification. We provide the design and the test evidence; the assessment is the company’s and its auditors’.

How does the six-week pilot run?

GembaOS proves business value on a standard six-week path with the least organizational friction; this is the design partner program.

How do the terms line up across languages?

GembaOS uses one set of core terms in its console, its policies and its documents in every language; the glossary defines each term once.

What is in the full edition, and how do we get it?

The full technical whitepaper contains the detailed data structures (JSON Schema), the clearance issuance algorithm, the adapter specification and the complete report of the 20 red-team cases; it is sent against a work email address. The point of bringing agents into a company is a workforce that is efficient, disciplined and bounded: however clever the model, inside a company it follows the authority matrix and the approval process.

• Request the full technical whitepaper (choose “Technical whitepaper” on the form)
• Book a 30-minute architecture consultation
• Apply to the design partner program

Related: security and deployment, the glossary, the FAQ.