Security & deployment

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 states what GembaOS does as of September 2026 (v0.2). It claims no certification GembaOS does not hold: as of this date GembaOS has no SOC 2, ISO 27001 or comparable attestation. We provide the design and the test evidence; the assessment is yours.

Where does GembaOS run, and what leaves our network?

GembaOS runs as a single Linux binary with its own data directory on infrastructure you control, on-premises or in a private VPC, and nothing leaves that network unless you configure a path for it.

The egress ceiling is a declaration on each tenant and each playbook of which class of model provider (self-hosted, private cloud, public SaaS) may receive which data classification. A playbook cannot send data above its ceiling, whatever role the agent holds. This is how a self-hosted model and a SaaS model are mixed by data sensitivity rather than by team.

How do agents act without holding credentials?

GembaOS keeps business-system credentials at the capability gateway, outside every prompt. An agent sees capability names and argument schemas; every call passes through the gateway in the same sequence.

Reads pass through the gateway as well, under field-level rules: an agent sees only the fields its role may see, and a refused read is itself a recorded fact.

How is an approved action protected from tampering?

GembaOS binds every clearance token to the hash of the approved arguments (argsHash), issues it once, and expires it. A call with different arguments does not match the token and is refused; executing the approved call consumes the token, so a second attempt is refused too. Before execution the host re-reads the preconditions named by the playbook and compares them with the facts on the approval request; when the world has changed since the signature, the request goes back to the requester rather than through. An order that changes after a stamp is a new request.

How does GembaOS treat prompt injection?

GembaOS treats external content as data and never as authority. An instruction embedded in an email, a chat message, a log line, a document or a picture cannot grant a capability, because the decision to allow an action is taken by the policy outside the model.

• Content that looks like an injection attempt raises a typed concern on the work item. The host turns it into a risk flag, and a flagged action is routed to a person regardless of what the agent proposed.
• Escalation rules written in the playbook are enforced by the host, not left to the model’s judgment.
• Images are re-encoded on ingest; pixels reach a model only at the edge stage, only when the playbook and the model configuration both allow it, and the model’s output remains data.
• The recorded red-team cases (prompt injection, parameter tampering, privilege escalation, credential exfiltration) replay as tests on every change. We walk through them with your security team.

How do people sign, and how are they identified?

GembaOS binds a human stamp to a passkey (WebAuthn) held by the person who signs. A tenant’s stamp policy can require a hardware-key grade for high-risk routes. Employees sign in through your identity provider over OIDC, and the directory is imported from your own export, never invented. The mock passkey visible in the demo captures on this site is refused on a public posture.

What does the audit trail contain, and can it be verified?

GembaOS records every event of a work item in order and hash-chained: agent turns, policy decisions, capability calls, signatures, the clearance and the execution. Policy replay re-runs the recorded decision against the current policy and yields the same route and rule chain; the audit replay view shows it. The official answer a customer receives is kept apart from the internal approval record. In a multi-tenant deployment each tenant has its own runtime and its own storage, and every read is scoped to the session that asks.

Which controls map to the frameworks our auditors use?

GembaOS maps its mechanisms to the controls your auditors already name; it does not replace their assessment.

What do we review with your security team?

1. An architecture walkthrough of your deployment: network position, TLS or proxy, identity provider, adapters.
2. The threat model and the red-team cases, replayed live against the runtime.
3. The golden tests for your workflow after the first two weeks of the pilot.
4. The data-flow table above, filled in for each of your integrations and models.
5. The deployment checklist: systemd unit, TLS, HSTS, behind-proxy headers, backup of the data directory.

Related: the design partner program, the FAQ and the glossary.