Authorization and grants

Phase 4 is the hinge. Everything before it decides what is allowed by policy; everything after it consumes authority that a human created. The sequence is fixed:

AI requests authority
        ↓
BitShout verifies current reality
        ↓
Human explicitly chooses
        ↓
BitShout creates narrow authority
        ↓
Every future use is revalidated

A request is inert

An AI application can generate requests all day. A request is recorded state; it does not change any policy behaviour by itself, cannot be self-approved, and cannot be escalated by being repeated. Only BitShout’s trusted service can turn a request into a grant, and it does that only in response to an explicit human choice made on a surface the requesting process cannot reach, script, or dismiss.

Where grants sit in the decision path

Contained operation
        ↓
Phase 1 containment/session identity
        ↓
Phase 2 or Phase 3 base policy
        ├── allow ─────────────────→ allow
        ├── non-overridable deny ──→ deny
        └── grantable deny
                ↓
        Phase 4 grant matcher

Two things follow from this shape. First, grants are evaluated after base policy, so a grant widens a specific denial rather than replacing the policy engine. Second, some denials are non-overridable: a staleIdentity result or an unknown operation cannot be granted around, because the thing you would be approving is not well-defined.

Scope

A grant is bound to a verified registered subject, a policy domain, one operation, one resource or endpoint scope, and a lifetime. In practice that reads like this:

subject   com.anthropic.claude
session   7C4A
domain    filesystem
op        read
resource  inode dev(1,17):8814402
expires   +00:30
uses      1

The available lifetimes are deny, allow once, allow for session, allow for a duration, and a persistent narrow rule. High-risk requests require an additional confirmation step. Broad “allow everything” grants exist only as a deliberate, labelled advanced decision — never as a default and never as a shortcut past a specific question.

Revalidation

Matching a grant is not a one-time event. Every subsequent use revalidates the subject, the session, the resource or endpoint identity, the policy version and the grant generation. Stale evidence at any of those points fails closed rather than riding on the earlier match.

This is what makes “allow once” mean once. The grant records its use, and the second attempt finds a consumed grant rather than an open door.

What never blocks

Endpoint Security and Network Extension authorization callbacks must not wait for a human. A pending approval does not stall your machine; the callback resolves on policy, and the grant — if you create one — governs what happens next. A security design that freezes the Mac while a sheet is open is a design people turn off.

Dependencies

Phase 4 does not duplicate the earlier models with generic permission strings. Phase 1 stays authoritative for subjects, sessions and lineage; Phase 2 for filesystem operations and resource identity; Phase 3 for direction, protocol, endpoint identity and address classification. Phase 4 consumes them.