Production changes without a standing key

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 scenario is the IT operations case: an agent that may read and reason about production, but may only change it through the change approval process.

How do we let an agent work on production without giving it a production key?

GembaOS gives the agent no production credential at all. The agent investigates in a restricted sandbox and drafts a ChangeSet; every privileged action passes the capability gateway, where the policy decides whether it needs change approval, and the adapter executes the approved change once under a clearance token bound to its exact arguments.

	Before	With GembaOS
Access	An agent with SSH or an admin API key, or no agent at all	No key in the agent; the gateway holds the credential
Investigation	A person tails logs at 3 a.m.	The agent reads logs in a sandbox, keeps facts and inference apart, and reports
Change	Applied by whoever is on call, recorded afterwards if at all	Drafted as a ChangeSet, approved by the change owner, executed once, recorded before and after
Injection in a log line	Nothing stops a planted instruction from being followed	The line is data; a typed concern routes the run to a person

What happens, step by step?

Step	Who	What is recorded
1. Trigger	A monitoring alert or a ticket opens a work item	The signal and its source
2. Investigate	The agent, read-only, in a sandbox that GembaOS probes rather than trusts	Every read, every scrubbed secret
3. Report	The reviewed report goes to the owner; what the agent lacked goes to the Gap Register	Report, gaps, the knowledge draft waiting for a person
4. Draft	A ChangeSet with the exact change and its preconditions	The approval request
5. Approve	The change owner signs with a passkey; the Delegation of Authority says who that is	The signature chain
6. Execute	The production adapter, once, under the clearance; preconditions re-read first	The execution and its result

Where is the control point?

The control point is the signature on the ChangeSet. Until it exists nothing touches production; after it exists only that change, with those arguments, can run, and only once. If the system has moved since the owner looked (the preconditions no longer match the facts on the request), GembaOS returns the request instead of executing it. An unattended run that needs no change ends at step 3: nothing changed state, and the audit trail says so.

What does it look like in the console?

GembaOS work item timeline showing the read-only triage run and its report

GembaOS gap ledger listing what the triage agent lacked

GembaOS work item event log listing every recorded event of the triage run

What do we need to start?

A monitoring source that can post a signal (webhook) and a ticket or chat channel for the report.
A sandbox the agent may read from: log access, read-only shell or API.
The change approval rule as it stands today: who signs which class of change.
One production adapter for the first change class, with the credential held at the gateway.