AIS-HA · IMPLEMENTATION PATTERNS

Use the controls you already have.

Human Anchor does not require inventing a new control plane. Map the boundary into existing identity, authorization, policy, approval, revocation, resource, logging, and recovery mechanisms.

Experimental implementation and verification profile. This material is an implementation and verification candidate derived from LUMINA-30 public boundary concepts and related research. It is not a canonical expansion of LUMINA-30, a certification scheme, a safety guarantee, or an endorsement of any product.

Common rule: identify one protected authority transition, the enforcement gate that can make it unavailable, the independent human authority, the evidence needed to test the claim, and the alternate path that would falsify it.

Pattern A

These are implementation patterns, not mandatory product architectures. Using a pattern does not by itself produce an AIS-HA PASS; bounded evidence through the Pilot and Verification Matrix is still required.

Access escalation

Example: read-only agent requests write/admin permission.

Authority does not exist before approval.
Approver is separated from the requesting agent.
Permission, resource, scope, and expiry are bound.
Reject means no grant.
Expiry and revocation are tested.
Unregistered authority is denied.

Challenge: can another identity, delegated token, inherited role, or recovery path reach the same access?

Pattern B

High-impact tool execution

Example: shell, deployment, transaction, external actuator.

Gate occurs before tool execution.
Deny is enforced, not merely logged.
Approval cannot be replayed for another call.
Tool remains inactive before admission.
Agent cannot disable the policy/enforcement point.

Challenge: can equivalent effect be reached via another tool or lower-level actuator?

Pattern C

Information egress

Example: release of sensitive data, publication, external transmission.

Gate sits before irreversible release.
Destination and data scope are bound.
Denied payload cannot leave through another channel.
Stale approval cannot authorize a later payload.

Challenge: can the same information leave by logs, browser, connector, clipboard, side channel, or affiliate service?

Pattern D

Boundary mutation

Example: change issuer, policy, connector, approver, trust root, delegation graph, or enforcement logic.

The old trusted configuration authorizes the change.
Changed authority-bearing components remain inactive until admitted.
The new configuration cannot self-activate.
Transitively dependent protected transitions stay held while transfer is non-VALID.

Challenge: can configuration change create authority before the new invariant/transfer evidence is valid?

Pattern E

Restart / restoration

Example: restart, failover, rollback, backup restore, credential recovery.

Revoked authority does not reappear.
HOLD survives restart.
Rollback restores VALID only when assumptions remain current.
Fresh review is required where validity is stale or unknown.

Challenge: does the recovery path resurrect a credential, policy, connector, or actuator that normal execution would reject?

When to return UNKNOWN

Return UNKNOWN instead of inventing confidence when a required path cannot be observed, a dependency cannot be established, evidence is stale/conflicting, scope is unclear, or the model may omit a real authority-bearing path.

Use the Verification Matrix Run the bounded Pilot Back to Hub