# 60 Zero-standing-access delivery pattern

> v0.0.2 · role: Meta · [policy: #19 · #29, #32](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

The engagement model behind the rest of this catalog: the consultancy holds no standing admin or data access to a client tenant. Access is granted per task, time-boxed, logged and revoked automatically, so a compromise of the consultancy is not a compromise of the client. It has no Admin Console screen of its own — it is enforced by JIT elevation ([40 Scripted JIT admin elevation](jit-admin-elevation.md)) and access recertification ([41 Periodic access recertification](access-recertification.md)).

Documentation: [Security best practices for administrator accounts](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts)

## Caveats

- It only holds if every access path is covered — one long-lived service account, or one shared password in a vault, reinstates exactly the standing access the model claims not to have.
- It costs latency — work that needs an elevation cannot start instantly, and that friction is what tempts people to keep a standing grant 'just for now'.

_Process control — carried out offline; no Admin Console walkthrough._

## Ongoing maintenance

- **[automatable: AI agent]** Weekly: review the grants log — every temporary grant must map to a request and an expiry.

## How to verify

1. Enumerate standing privileged grants — the result should be the documented floor (break-glass plus nothing).

   ```
   gam print admins
   ```