Notes
What is a clearance token? Single-use execution permits for AI agents
For security architects, IT operations and internal audit teams deciding how an AI agent may be allowed to act in production systems.
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 note defines one term from the glossary, the clearance token, and shows where it sits in an approval.
What is a clearance token?
A clearance token is a single-use, time-limited authorization that GembaOS issues for one approved action and binds to the hash of that action’s arguments (argsHash). Executing the action consumes it. A call with different arguments does not match it, is not executed, and the mismatch is recorded on the work item. The token is why an agent never needs a business-system credential: the capability gateway holds the credential and releases one call for one token.
Three properties follow from that definition, and each one closes a specific failure an approval workflow alone leaves open:
| Property | What it means | The failure it closes |
|---|---|---|
| Bound to the arguments | The token is valid only for the exact arguments the approver saw on the approval request | An agent changes the amount, the account or the target after approval |
| Single use | Executing the action consumes the token | The same approved action is executed twice, by retry or by replay |
| Time-limited | An unused token expires | An approval from last quarter is presented as authority today |
Why is an approval alone not enough to stop parameter tampering?
An approval in a workflow tool is a state on a ticket; nothing binds the later API call to what was approved. GembaOS binds the two by issuing the clearance token from the approved arguments themselves, so the approval and the execution cannot drift apart. The comparison below is the whole difference:
| Approval in a workflow tool | Clearance token in GembaOS | |
|---|---|---|
| What is approved | A ticket, described in prose | The exact arguments, hashed (argsHash) |
| Who executes | Whoever holds the system credential, including the agent | The host, under the token; the credential stays in the gateway |
| The agent changes the amount after approval | The call goes through | The call does not match the token: refused and recorded |
| A second execution | Possible | Refused: the token was consumed |
| Evidence for an auditor | Ticket history | Token, argsHash, the signature chain and the hash-chained events of the work item |
Where does the token sit among the four gates?
GembaOS passes every sensitive state change through four gates in order, and the clearance token is the third. The architecture whitepaper describes each gate; the sequence matters because the token is never the first line of defense and never the last.
| Gate | What it decides | Relation to the token |
|---|---|---|
| 1. Policy decision | Pass, route to a person, or block, from the Delegation of Authority | No token without a decision to pass |
| 2. Signature chain | Agent stamps for delegated checks; a passkey signature for the steps the route reserves for a person | The token is issued from the arguments the signers saw |
| 3. Single-use clearance | One token for one action with one argsHash | This gate |
| 4. Host reality check | The host re-reads the real state before the backend call; if it changed, execution stops and the clearance is voided | A token can still be voided by reality |
What does it look like in the console?
The last line of the signature chain is the token: an identifier, the status Issued, and the words single use with an expiry. It appears only after the fourth stamp. The audit replay re-runs the recorded decision against the current policy and shows the same route.
Summary
A clearance token turns an approval into something an API call can be checked against: one action, one set of arguments, one execution, inside a time window. It is issued after the policy and the signatures, and it can still be voided by the host’s reality check. What remains afterwards is a record an auditor can replay rather than a ticket someone has to trust.
Questions this note answers
What happens if the agent retries the action after it succeeded?
The second call is refused. Executing the approved action consumed the token, so a retry with the same token does not match an issued clearance, is not executed, and the attempt is recorded on the work item.
Does a clearance token replace the human approval?
No. The token is issued after the policy decision and, when the route requires a person, after that person's passkey signature on the approval request. The token carries the result of the approval; it does not stand in for it.
Can an existing LangGraph or Dify agent use clearance tokens?
Yes. 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; the adapter and interface details are settled in a configuration conversation.
Sources
As of September 2026 GembaOS holds no certification; the control mappings on this site are self-assessed, not audited. GembaOS is in its design partner stage. Read about the design partner program.
Last updated: · GembaOS v0.2