# Illustrative evaluation record: AUTHZ-1 **Fictional and illustrative throughout.** All expected behaviours, observations, evidence references, people and decisions below are invented to demonstrate recording and review. No actual assessment or evaluation took place. Evidence identifiers describe fictional artefacts; no evidence files are attached. ## Evaluation context and decision - Worked example: **A reusable access-control workflow within a SaaS penetration test**. The main engagement objective is to investigate whether a standard user can retrieve another tenant's reports. This narrow workflow evaluates selected report reads and role-restricted `review_note` updates as supporting activities. - Workflow: `AUTHZ-1`, version `0.1.0`; [specification](workflow-specification-example.md). - Application: `https://saas.example.invalid`, build `illustrative-permissions-17`. - Authorised tenants: `test-amber` and `test-blue`. - Matrix: `PM-illustrative-1.0`; execution configuration: `manual-v1`. - Fictional executor: Rowan Ellis; reviewer and release decision maker: Mia Patel; application owner and scope authoriser: Jo Morgan. - Agent: not used. The optional proposal-only path has not been evaluated and is excluded from this readiness decision. - Evaluation set: seven invented, independent scenarios for selected read/update rules, evidence collection and failure handling. Each starts with a restored synthetic fixture and its stated session condition. They are not a chronological run that continues after a stop. Case 7 uses a deliberately defective synthetic fixture within `test-blue`, without changing its account's role or expanding the authorised actions. This record evaluates whether the workflow performs its intended function, handles known conditions appropriately and produces usable evidence. Conducting the assessment separately requires the consultant to investigate the authorised adversarial objectives, adapt to observations and develop defensible findings and coverage statements. The matrix provides expected rules for these checks, not a complete account of abuse paths. The walkthrough in the specification assumes a workflow evaluated for its intended use, with its adaptation reviewed by Mia. Its manual follow-up of a separate authenticated export-result endpoint is permitted by the broader engagement's written authority, outside `AUTHZ-1`'s report-route operations. None of the seven cases below evaluates that export investigation or its finding. In particular, the known-identifier export finding in the fictional walkthrough is not a result obtained by version `0.1.0`. Evaluation establishes whether a workflow performs its intended function under the conditions tested. It does not establish that an engagement is complete or that the assessed environment is secure. **Illustrative decision: not ready for client use.** Case 4 exposes a stale-session classification defect. Case 6 exposes an evidence-capture gap. Mia blocks workflow release until these are corrected and the relevant cases are re-evaluated. Meeting the selected evaluation criteria would support only the limited use described in the specification, not comprehensive assessment capability. ## Case 1: permitted own-tenant action **Expected behaviour:** `amber-editor`, authenticated to `test-amber`, may read `amber-report-01` and change its `review_note` from `baseline` to `checked`. Restoration to `baseline` must succeed. **Illustrative observed behaviour:** the permitted read shows the designated synthetic report. The update and subsequent read show `checked`; restoration and a final read show `baseline`. **Illustrative evidence:** `E-01` describes an authenticated identity check, redacted request/response pairs, the report's tenant/fixture labels, timestamps and before/after/restored values. It identifies the workflow, build and configuration above. **Result category:** Tested with supporting evidence. **Security conclusion:** the selected permitted rule was observed. This establishes a working positive control for this account and fixture, not that all editor permissions are correct. **Illustrative workflow evaluation decision:** the workflow meets this case's criteria for execution and evidence capture. Accept the limited security conclusion; no workflow correction is required for this case. ## Case 2: prohibited action within a tenant **Expected behaviour:** `amber-reader` may read `amber-report-01` but must be denied an update to its `review_note`. **Illustrative observed behaviour:** an own-tenant read confirms a valid reader session. The update is denied; an authorised read shows the baseline unchanged. A further permitted read confirms that the session remained valid. **Illustrative evidence:** `E-02` describes the role/session check, update request and denial response, and the unchanged fixture state, linked to the relevant matrix rule. **Result category:** Tested with supporting evidence. **Security conclusion:** the selected reader update restriction was observed. The expected denial is a completed check, not an execution failure. **Illustrative workflow evaluation decision:** the workflow meets this case's criteria by recording the valid session, denial and unchanged state. Accept the supported denial for this selected action. ## Case 3: prohibited cross-tenant read **Expected behaviour:** `amber-reader` must not read `blue-report-01` in `test-blue`. Both tenants and this fixture are explicitly authorised for this check; no other tenant may be contacted. **Illustrative observed behaviour:** the session reads its own amber fixture successfully. A request for the designated blue fixture is denied and discloses no report content. The follow-up own-tenant read remains successful. **Illustrative evidence:** `E-03` describes the exact destination and fixture, identity/tenant checks before and after, and the redacted denied response showing no report data. **Result category:** Tested with supporting evidence. **Security conclusion:** the selected cross-tenant read restriction was observed. This says nothing about other fixtures, routes or cross-tenant updates. **Illustrative workflow evaluation decision:** the workflow meets this case's criteria by recording the authenticated attempt and absence of disclosure. Accept this limited conclusion about the declared report route. It provides no conclusion about access through an export endpoint. Do not extend the target list because another resource is reachable. ## Case 4: expired authenticated session **Expected behaviour:** if `blue-reader` has an expired session, the workflow must stop the affected check and classify it as Execution failed. A login failure cannot demonstrate that a cross-tenant authorisation rule held. **Illustrative observed behaviour:** the session check produces a login-expired response. A draft record nevertheless claims that access to `amber-report-01` was correctly denied and continues towards completion. **Illustrative evidence:** `E-04` describes the failed session check, the login-expired response and the incorrect draft classification. It contains no valid authenticated cross-tenant test. **Corrected result category:** Execution failed. **Security conclusion:** no conclusion about the cross-tenant rule. **Illustrative workflow evaluation decision:** the workflow does not meet this case's stop and classification criteria. Reject the unsupported denial and block workflow release. Mia records issue `I-01`: require a verified positive session check and stop on its failure; subsequent checks must be Not tested. Rowan must repeat this expired-session case and the corresponding valid-session denial after correction. **Unresolved.** ## Case 5: execution timeout requiring a stop **Expected behaviour:** a timeout during an `amber-editor` update requires a stop, preservation of available evidence and confirmation of fixture state. An uncertain write must not be retried automatically. **Illustrative observed behaviour:** a permitted update times out. Rowan stops, informs Mia and Jo, and records its result as unknown. Jo confirms the fixture state and restores `baseline`. Rowan does not issue more tests or repeat the update while its effect is uncertain. **Illustrative evidence:** `E-05` describes the timed-out request, last known state, stop notification and Jo's fictional restoration confirmation. There is no complete response supporting the intended test. **Result category:** Execution failed. The planned cross-tenant update following it is **Not tested**, reason: stopped after timeout. **Security conclusion:** no conclusion about the interrupted update or the unattempted cross-tenant objective. **Illustrative workflow evaluation decision:** the workflow meets this case's criteria by stopping and recording the limitation. Accept the stop and honest classification. Resume only after the cause is understood and prerequisites, capture and authority are reconfirmed. This case is independent of the other invented scenarios. ## Case 6: allegation without adequate evidence **Expected behaviour:** a claim that `blue-reader` changed `blue-report-01` needs a valid reader session, the actual update request/response and reliable before/after state. Narrative text alone cannot establish unauthorised change. **Illustrative observed behaviour:** the case record says an update was attempted and describes a possible unauthorised change. Its capture contains a request timestamp but lacks the response, authenticated role verification and baseline comparison. The apparent state cannot be attributed to this attempt. **Illustrative evidence:** `E-06` describes the incomplete attempt record and narrative. It does not substantiate a finding. **Result category:** Tested but inconclusive. **Security conclusion:** no supported finding and no supported denial. **Illustrative workflow evaluation decision:** the workflow does not meet this case's evidence and classification criteria. Reject the proposed finding. Mia records issue `I-02`: make missing capture visible, stop when evidence capture fails, and require the relevant artefacts before accepting a conclusion. Re-evaluate the incomplete-evidence case and this reader restriction with working capture. **Unresolved.** ## Case 7: a deliberately vulnerable fixture **Expected behaviour:** `blue-reader` must not update `blue-report-01`. In this independent evaluation scenario, the application owner's synthetic fixture deliberately permits the forbidden `review_note` change. The workflow should identify the rule violation, retain supporting evidence and record a candidate finding for Mia's review. The unexpected write requires a stop and restoration; it does not qualify for the specification's limited read-only confirmation. **Illustrative observed behaviour:** an identity check and permitted read establish a valid `blue-reader` session and the baseline. The selected update response indicates that `review_note` changed to `checked`. Rowan stops immediately and informs Mia and Jo without issuing another test request. As part of the agreed recovery, Jo verifies the changed fixture, restores `baseline` and confirms the restored state. The account remains a reader and no other tenant or record is accessed. **Illustrative evidence:** `E-07` describes the authenticated role check, the matrix rule, redacted update request/response, timestamps, Rowan's baseline capture and Jo's recorded after-state and restoration checks. It identifies the workflow, build and configuration. **Result category:** Tested with supporting evidence. **Security conclusion:** evidence supports an unauthorised reader update of the designated synthetic report. This is a fictional security failure in the target, not a workflow execution failure. **Illustrative workflow evaluation decision:** the workflow meets this case's detection and evidence criteria. Correctly identifying a deliberately vulnerable case is a successful evaluation of the workflow despite the target violating its access-control rule. Accept the limited finding; this does not resolve `I-01` or `I-02`. In an assessment, Rowan and Mia would separately decide what further in-scope investigation the observation justified. ## Limits, corrective work and release review The fictional record has four cases with supporting evidence, one inconclusive case and two execution failures. The stop scenario also leaves one planned objective Not tested. These categories describe the individual actions, separately from whether the workflow met each case's evaluation criteria. They are descriptions of an invented evaluation set, not real performance measurements or a coverage percentage. Mia owns `I-01` and `I-02`. Rowan prepares corrected execution and recording instructions; Mia reviews them before a new workflow version is evaluated. Workflow release needs both issues closed with retained evidence, the relevant failure-handling and expected-behaviour cases repeated, and a named decision for the proposed use. No due date or future satisfactory result is assumed. The optional agent configuration needs its own proposal, scope-boundary and unsupported-explanation cases before use. The set does not evaluate the bounded confirmation of an unexpected synthetic disclosure during a declared read check. Before relying on that behaviour, Mia needs a case demonstrating its evidence, session checks, limits and subsequent pause, including the refusal to confirm when a prerequisite fails. This set does not cover every account/action combination, cross-tenant update, route, object type or all possible errors. It does not prescribe the consultant's investigation of alternative access paths, business-logic abuse or combinations of weaknesses. Those may need separate investigation depending on scope and observations, without extending authority. New build, matrix, workflow or configuration changes can invalidate the relevance of this record. The decision remains **not ready for client use**.