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. 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.

What can agents see? How data access and knowledge boundaries are controlled

Reads pass through the capability gateway under the same strict enforcement as writes. Instead of optimistic filtering—feeding full database records or entire document stores to the model and relying on system prompts to keep secrets—GembaOS enforces hard boundaries before data ever reaches the model context.

• Field-level pruning: Unauthorized fields (such as payment details, national ID numbers, compensation, or internal risk scores) are physically stripped at the gateway. The prompt receives only the whitelisted fields declared in the agent’s role schema.
• Cross-customer isolation: Database access is restricted to parameterized stored procedures and declared read-only views; arbitrary SQL queries are rejected. Queries strictly bind to the customer or tenant identifier of the active work item, preventing agents from scanning or enumerating other customers’ records.
• Probing-resistant document search: When searching company documents, agents can only retrieve verified and approved versions; unapproved drafts and restricted folders remain invisible. Inquiries for documents outside an agent’s permissions return “Document Not Found”—identical to when a file genuinely does not exist—preventing models from probing for confidential information through iterative guessing.
• On-behalf-of access ceilings: When an agent acts on behalf of an employee, its effective data permission is the intersection of the agent’s role boundary and the logged-in employee’s personal clearances. If an employee cannot view a financial record, their agent cannot retrieve it on their behalf.
• Logged read refusals: Any unauthorized read attempt is intercepted at the gateway and recorded as an auditable event. Anomalous or repeated read failures trigger a risk flag on the work item and alert administrators.

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 runtime 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 is flagged on the work item as suspicious input, 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 governance kernel, not left to the model’s judgment.
• Attachments and pictures are data too: a picture reaches a model only when the playbook allows it, and the model’s output about it 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 hardware key can be required 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 demo captures on this site use a demonstration passkey; a production deployment uses your employees’ own. A stand-in, an escalation target or a manager who takes a request over signs with their own passkey too, and the signature chain says on whose behalf.

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.

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. The architecture whitepaper carries the mapping by framework (NIST AI RMF, NIST SP 800-207, OWASP Top 10 for LLM, SOC 2 criteria, HKMA, PDPO, FISC).

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: service unit, TLS, reverse proxy, backup of the data directory.

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