Standing authorisations
A standing authorisation is a named grant that lets Overseer act without asking each time, within a scope you set. This page explains what a grant covers, how to preview it, how actions are attributed and what revoking does.
What a standing authorisation is
Detection finds what a computer needs. Something then has to authorise acting on it. For unattended work, that authorisation must have been given by a named person, earlier and on purpose.
A standing authorisation is that grant. A named person says, in effect, "for this client, this item and this action, go ahead without asking me again".
Overseer acts on its own only where a live grant covers the work. Every action it dispatches records which grant allowed it.
Why a grant and not an approval queue
Approving each action one at a time does not scale beyond a few computers. A fleet where nothing runs unattended is a fleet where very little runs at all.
A standing authorisation changes what you approve. You approve the class of work in advance, not each instance of it. In return, the record shows which grant authorised which action, so the question "who said this could happen" always has an answer.
What a grant covers
A grant is scoped by three things.
| Scope | What it fixes |
|---|---|
| Client | Whose computers the grant applies to |
| Item | The software or task it applies to |
| Action | What Overseer may do with that item |
Work that falls outside any one of the three is not covered, and Overseer does not act on it by itself.
A few limits are built in:
- A grant is not a schedule. It permits work. It does not cause it.
- A grant does not cover uninstalls.
- A grant does not expire. It lives until someone revokes it.
Preview before you trust it
A grant can be previewed. The preview shows what Overseer would do if it acted on its own this minute. For anything it would refuse, the preview says why.
The preview shows exactly what would run. It is the real process running with actions disabled, not a separate estimate, so the preview and the real thing cannot drift apart.
Read the preview before you rely on a grant.
Attribution
Every action dispatched under a grant records which grant allowed it. The audit log keeps that link.
This means unattended work is never anonymous. The log distinguishes Overseer acting under a named grant from a technician pressing a button, and the grant leads back to the person who made it.
Revoking a grant
Revocation is immediate. Grants are read afresh each time Overseer looks for work to do. They are not fixed at the moment the work was found.
A revoked grant stops authorising from that moment. That includes work that was already detected and is waiting.
Who can grant and revoke
Granting and revoking both require the capability to act on computers. It is the same capability that covers deployments, schedules, restart policy and maintenance windows, so the people who can make a grant are the people already trusted to deploy.