FR

ACTION TYPE · GRANT ACCESS

Access that is granted in seconds and reviewed in a quarter.

Role assignments, group memberships, API keys, temporary elevation. Helpdesk agents and provisioning scripts already grant access; the review that is meant to catch a bad grant usually comes long after it was used.

Who runs it today: IT helpdesk agents, provisioning scripts, identity workflows, CI service accounts.

The rules that usually govern it

  • A requester cannot grant a role above their own
  • Elevated access is time-boxed
  • Sensitive roles need an approver who is not the requester
  • Some conditions must hold at request time, such as MFA or a network range

Typical rule shapes, not a claim about any one organisation. A pilot starts from yours.

Where rules like these break

  1. Grants chain.

    A role that may grant roles can hand out one that may grant more. Each step is within policy; the end state is not.

  2. Temporary adds up.

    Time-boxed grants renewed back to back are standing access, while each renewal passes on its own.

What the gate does

  1. 01

    Evaluates each request against the policy before it executes. What it blocks or refuses never reaches the system.

  2. 02

    Refuses when a window or population the rule depends on is missing or does not reconcile, instead of guessing.

  3. 03

    Seals every decision, PROCEED, BLOCK or REFUSE, so it can be re-checked without us.

What you can check today

ON REQUEST

Sealed decision benches on access policies published verbatim by AWS and Microsoft, decided by our reading of their documented semantics. On 57 AWS example IAM policies, 185 guarantees: 160 hold under both Z3 and cvc5, 5 under cvc5 only, 16 fail, 3 fail under cvc5 only without a witness, 1 is unknown. 11 real findings, each confirmed in AWS’s IAM policy simulator: in 8, the page’s prose and its policy disagree; 3 come from our reading. The live AWS and Azure services were not exercised. Shown in a call, not published.