Test Access Control

Prove who acted on what, who should control it, why access should be denied, and what unauthorized impact occurred.

Establish authority and safety

1. Identify the repository, application/API origins, roles, tenants, supplied identities, and expected collaboration model.
2. Do not send runtime requests unless the target and testing are authorized. Perform source/spec/traffic modeling when runtime authorization is absent.
3. Treat supplied accounts and existing customer objects as protected. Use them as callers for read-only checks only.
4. Require fresh disposable objects for write, delete, ownership, role, invitation, billing, credential, or lifecycle mutations. Define readback, restoration, and cleanup before sending the mutation.
5. Redact raw credentials, tokens, cookies, private object contents, and unrelated PII. Preserve actor labels, object/tenant attribution, response hashes, field classes, and short redacted snippets.

Establish identity truth

Bind each runtime session to its observed user, configured role, tenant, and transport. Keep configured claims separate from observed claims. Do not infer identity from a filename, token claim, role label, or current-user field alone.

Mark an identity trusted, coverage_only, or unusable. A stale, failed, mismatched, or browser-bound session used through the wrong transport is a coverage limitation, not an access denial.

Build the authorization model