Authenticated and multi-role testing

Many serious weaknesses only appear after sign-in: one role reading another role’s records, or a whole record returned where only part is permitted. Pentriarch signs in as each role you define and compares what each role actually receives.

A confirmed difference becomes a cross-role finding with a replayable proof. The proof records role names, response status and hashes; it never stores a session or password.

Role credentials, including any one-time-password seed, are encrypted at rest and decrypted only to sign in during an assessment. Use dedicated test accounts with the minimum permissions each role needs. Never use a real employee’s account.

Login endpoints must sit on the authorised target host unless an identity-provider host is explicitly allowed. A login request that would leave the scope is refused before it is sent.

Each role reports one state before testing. A role that is not ready is listed as not tested, with the reason, and never counted as passing.

You can supply a role and resource matrix as Markdown, CSV, TSV or JSON. It is treated as untrusted input: Pentriarch turns it into a proposed access model with source references and ambiguity flags. Nothing is tested from it until you accept it.

A document can never widen the authorised scope. Paths on other hosts, traversal attempts and instructions embedded in the document are rejected or flagged.

A retest signs both roles in again from the vault and repeats the comparison. If either role cannot sign in, the result is inconclusive, never fixed. Availability depends on your deployment having multi-role testing enabled; confirm before planning an engagement.