The agents ran all week. What does the manager open on Monday?

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.

Most of what has been written about governing agents is about the moment of the act: may this agent make this change, and who signs. That is the right place to start, and it is what the four gates are for. It is not where a manager lives. A manager arrives after the agents have run for a week and asks a different set of questions: what do we have, who answers for it, what is waiting on me, what changed, what is wired to what, and how old is that password. This note walks the six pages GembaOS gives for those questions, with the pictures from one run of the local demo.

Two rules hold on every one of them. Each page is derived: from the playbooks, the tenant’s rules, the capability packs and the records the runtime keeps anyway. There is no second list to maintain and nothing to type in. And no number is rounded up: a count the page cannot support is shown as what it is, and each one opens the records behind it.

An employee hands work over and gets a receipt

The employee page starts with one box: write what you need done. An assistant proposes which of the businesses this employee may start it is, and GembaOS checks the proposal against what they may start and what they actually wrote; if it cannot tell, it shows the candidates and asks, it does not guess. Nothing starts until the employee hands it over. What comes back is a receipt: which business took it, the ticket, who is handling it, what happens next. The same request handed over twice returns the same receipt.

Here the support specialist asked for a policy lookup, and by the time the picture was taken the lookup had already run and reported: the receipt says Done. A request that needs a person would say who is waiting.

The overview

The overview is what a manager reads first: coverage and responsibility from the agent registry, exceptions waiting (open gaps and flagged runs), approvals waiting on a person, what ran without a signature and whether anyone sampled it, and which rule changes wait for a review. The window is seven, thirty or ninety days.

The three without an owner and the five flagged are real: two partner agents with no token set and three workers with no link material. The tile says so and lists them; it does not fold them into a green number.

The agent registry

One row per agent the company answers for: the playbook pipelines GembaOS runs, partner agents that call through the gateway, workers the company runs on its own hosts, and anything the company registered by hand. Each row names an owner and where that name comes from, and a coverage level that is derived and never rounded up: registered (written down, nothing more), observed (calls are seen, nothing is blocked), partly governed (calls are answered, the loop cannot close) or enforced (the declared operations run only through the gateway, under clearance). An operator can name an owner on a row; that is the one thing a person adds here, and it goes on the record.

A rule release, checked before it is published

A change to a playbook or to a role’s instructions travels as one release. The picture is a draft that raises the limit of the band the rule signs on its own. The check has run: the version must move; the difference is read off the declarations and written in plain words (looser: the band that signs itself now covers more); and the decisions this playbook recorded are judged again under the new rule, from the recorded facts, with nothing re-sent, refunded or mailed. Here four earlier decisions would all land where they did. The next step is a second person’s approval; the author cannot approve their own release.

When a release is published, running work continues on the rule it started under, requests still waiting on a changed route go back to be decided again, signed requests stand, and a rollback is a new release with a mandatory reason that undoes no effect already produced.

The risk register

Every playbook, read off its own configuration: the data it touches, what it may do (read, write, execute, or an execute that cannot be undone), who can start it and whether its data leaves to a SaaS model or an outside system, and how much a person reviews. The tier follows by a fixed table and names the controls it expects, and the row says which are met. Nobody types a score in and no model proposes one; a release that moves a dimension marks the row as changed since somebody last looked.

Below the register, the red team is a register too. Each case names the route it attacks (injection, overreach, skipping the approval, facts that moved after the stamp, a tool contract change, acting after a handover, a standby model leaving the tenant), the playbook and the person who answers for it, how to reproduce it and, once run, the events on which the host refused it. A breach takes a fix under a name; the next defended run retests it. A pass rate is not a result.

The connections

Every outside system the tenant is wired to, read off the packs, workers, model providers and services the runtime booted with. Each row shows what the link is made of, as variable names with set or not set, never a value; whether a stand-in fixture answers instead of the real system; what GembaOS may do through it and under whose stamp; how it has been doing, from the calls on the record; and how old each secret is. Below it, the identity revocations: every leaver and what was revoked the moment they were offboarded.

What this does not do

• It does not score anything. The tier is a table over what the playbook declares; the coverage ladder is derived from the packs and the gateway. If the configuration says less than a manager hoped, the page says less.
• It does not rotate a secret. It records the day a secret’s fingerprint changed and flags one that is older than the company’s rotation policy. The rotation is the company’s act.
• It does not publish a rule on one person’s word. The author of a release cannot approve it.
• It is not in the public demo. The pictures come from a local demo, where each person signs in as themselves: run gemba demo, open the console, and the six pages are on the left rail.

---

For architects

• Derived, never listed: the registry, the risk register and the connection register are built at read time from the configuration and the runtime’s records; the only writes are a claimed owner, a review, and the fingerprint of a secret.
• A release is a bundle of playbooks and instructions: models, the authority table, roles and the system contracts are pinned by hash and never travel with it. The check stages a copy, runs the boot-time checks on it, diffs the declarations, and re-judges the recorded decisions as a pure function of their recorded inputs.
• The connection register’s credential store holds twelve hex characters of a hash per variable, with first-seen and last-changed dates. A rotation is an admin audit log event naming the variable, never the value.
• The red-team runs are persisted under the data directory; the console folds them per case into never run, defended, breached, fix recorded and retested.