Permits AVAILABLE
A signed document saying what a party may ever ask for.
What it is
- A permit states that an issuer allows a subject to perform certain actions on certain resources, under conditions, until a moment — and signs that statement.
Why it exists
- Documents can be held, inspected, delegated and revoked. A row in somebody's database can be none of those things by a party that does not have access to it.
How it works
- Issue with the CLI, offline.
- Present it on every authorization; the Gateway verifies signature, window, conditions and revocation.
- Delegate onward — and a delegated permit can only narrow.
- Revoke by commitment, idempotently. Revoking an ancestor revokes what descends from it.
Who uses it
- Organizations bounding what their agents may ask for
- Platforms delegating to sub-tenants
Security boundary
- A permit is not authority. Policy still decides, and an approval may still be required.
- Registering a permit in the Console records it and grants nothing. Removing the registration revokes nothing.
- A constraint this build cannot enforce is refused rather than ignored.
Example flow
Delegation that narrows
- Acme issues to the orchestrator: purchase, all of procurement, 50,000 ₺.
- The orchestrator delegates to a worker: purchase, office supplies only, 5,000 ₺.
- The worker asks for 20,000 ₺ of furniture. Refused — the delegation narrowed and cannot widen back.
Current status
| Capability | Status | Where |
|---|---|---|
| See the permit registry An inventory. Issuing happens in the CLI and registering needs PERMIT_ISSUER. | READ ONLY | /projects/:id/permits |
| Issue a permit Not from the Console, on purpose: there is no issuer-key custody workflow, and a button there would be inventing an authority rather than exposing one. | AVAILABLE | The CLI: `bengar permit issue` |
| Register an issued permit | AVAILABLE | /projects/:id/permits |
Related API
GET /v1/console/projects/:id/permitsPOST /v1/console/projects/:id/permits