Gate pass
An approved pass names the carrier, the assets, the destination, and the window. The policy engine can read that as an attribute at a named exit, for that window only.
The workflow that plants actually run.
Equipment leaving a site is a real approval chain with real signatures, and it is usually held together by email.
A pass names a carrier, the specific assets picked from the register, a destination, a reason, and a window. It moves through a configurable approval chain, typically the asset owner and then a senior approver, and level two does not open until level one has signed.
Because the assets are register entries rather than typed descriptions, the pass and the asset history are the same record. The lifecycle timeline of a device shows the approved movement, who authorised it, and when it was expected back.
At the gate, the pass is an input to the access decision rather than a replacement for it. The policy engine sees an attribute saying this carrier has an approved movement at this exit inside this window, and the rules decide what that permits.
- Carrier
- A directory principal, not a name in a box
- Assets
- Selected from the register
- Destination
- A location in the tree, or an external address
- Window
- Explicit start and end
- Exit
- A named portal, not the site perimeter
- Approvals
- Configurable chain, sequential
- Decision role
- An attribute in the policy context
- On revocation
- Open passes for that carrier are rejected
From request to the barrier.
Raise against real assets
The requester picks assets from the register. Serial numbers and custodians come with them, so the pass cannot describe equipment that does not exist.
First approval
The asset owner confirms the movement is legitimate and the return date is realistic. Their identity is recorded against the decision.
Second approval
A senior approver signs. The chain is sequential by design, so the second signature always means somebody closer to the equipment already agreed.
The exit reads it as an attribute
At the named portal, inside the window, the decision context carries an approved-movement flag. The rules decide what that changes, and the floor still applies.
The asset history records it
The movement is written to each asset's event timeline, so the register reflects where equipment actually is.
An approved exit does not drop that portal to card-only and it does not authorise a legacy cleartext reader. It scopes an exception to a named portal and a window, with the corroboration floor intact. A silent hole in the floor is not a convenience feature.
The safeguards.
Assets are picked
Selected from the register, never typed as free text.
Sequential chain
Level two cannot approve before level one.
Named portal
The pass is valid at one exit, not everywhere.
Window enforced
Outside its window the pass simply does not apply.
Revocation wins
Revoking the carrier rejects every open pass with a recorded reason.
Audited
The approval chain and the movement are both immutable events.
Related
Bring the door onto the same epoch as the laptop.
We will walk you through a live portal, a compiled policy pack, and a revocation that closes the turnstile and locks the screen while you watch.