# A reusable access-control workflow within a SaaS penetration test

**Fictional, illustrative workflow specification.** Every person, identifier and arrangement below is invented. This is educational material, not an authorised engagement, a delivered assessment or evidence of testing capability. No security tests were performed to produce this example.

## Record and purpose

- Workflow: `AUTHZ-1`, version `0.1.0`.
- State: illustrative draft; **not ready for client use**. The [example evaluation](evaluation-record-example.md) contains unresolved release blockers.
- Application build: `illustrative-permissions-17`.
- Permissions matrix: `PM-illustrative-1.0`.
- Execution configuration: `manual-v1`, a practitioner using an approved browser and request recorder, with serial requests and automatic retries disabled.

During an authorised SaaS penetration test, consultant Rowan Ellis investigates whether a standard user can retrieve another tenant's reports. A permissions change prompted the assessment. This maintained workflow supports selected report reads, role-restricted updates and evidence collection using designated accounts and synthetic reports. Rowan starts it when those checks are relevant to the agreed adversarial objectives and the prerequisites are confirmed.

Completing these checks does not establish that the engagement's objectives have been adequately investigated. Rowan uses the evidence and unexpected observations to decide what to investigate next within the authorised scope. The workflow supports parts of that investigation; it does not prescribe the whole assessment.

## Investigative context

The fictional walkthrough assumes a workflow evaluated for its intended use, with its adaptation reviewed by technical lead Mia Patel. It does not describe use of the unreleased version `0.1.0` supplied here. Rowan notices that an own-tenant report's download uses a separate authenticated export-result endpoint. The application owner, Jo Morgan, confirms that the endpoint should return results only to the owning tenant's users; it is not an intentionally shareable signed bearer URL. The engagement separately authorises investigation of individual synthetic report exports in the two test tenants, so Rowan and Mia agree a limited manual follow-up under its rules of engagement.

The authorised `blue-reader` account supplies its known synthetic export identifier. Using only `amber-reader`'s credentials, Rowan requests that export result and retains the response body showing Blue's report alongside session-identity evidence. The manual plan allows one isolated confirmation after session and capture checks; Rowan then pauses for Mia's review. The finding is limited to access to that designated export with a known identifier. Identifier discoverability remains untested. None of this adds the export endpoint to this workflow's permitted operations, and the supplied evaluation makes no claim about the manual export investigation.

## Evaluating the workflow and conducting the assessment

Mia evaluates whether the workflow performs its intended checks, handles known conditions appropriately and produces usable evidence. Rowan conducts the assessment by investigating the authorised adversarial objectives, adapting to observations and developing defensible findings and coverage statements. These are separate decisions.

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.

## Authority and scope

The fictional engagement covers `https://saas.example.invalid` and the two test tenants below. Its written rules of engagement separately authorise the individual authenticated report-export investigation described above, using known synthetic identifiers. They exclude bulk export, real data and any unagreed extension.

This workflow has a narrower set of permitted operations on the same application. It uses only tenants `test-amber` and `test-blue`, and these four accounts:

- `amber-reader` and `amber-editor`, assigned to `test-amber`.
- `blue-reader` and `blue-editor`, assigned to `test-blue`.

The workflow's only target records are synthetic fixtures `amber-report-01` and `blue-report-01`, belonging to their respective tenants. Their content has no client or personal data. The illustrative routes are `/tenants/test-amber/reports/amber-report-01` and `/tenants/test-blue/reports/blue-report-01`, using `GET` for reads and `PATCH` for selected updates. The only permitted update is changing the designated `review_note` field between `baseline` and `checked`, followed by restoration. Session identity checks use `GET /session`; `POST /session` is permitted only to establish a session for a designated account through the agreed sign-in process. Authentication requests count towards the request budget and must be redacted before evidence export. No other application routes or methods are permitted in this workflow, including the export-result endpoint.

Cross-tenant checks use only these accounts and fixtures in these two tenants. Unexpected behaviour may justify further investigation within the engagement's agreed scope, but does not extend this workflow's permitted operations. Discovering another reachable tenant, record, host or service does not authorise testing it. Record its location without requesting its contents and pause the affected workflow activity. Rowan and Mia check the written engagement authority before any separate investigation; Jo must clarify uncertain authority. An extension beyond that authority requires a revised written agreement and reviewed execution configuration before activity proceeds.

Excluded from this workflow: production and other tenants; other accounts or records; role changes; credential guessing; enumeration; report exports; account or report creation and deletion; destructive actions; load testing; and testing connected services. An unexpected route or redirect is not followed by the workflow. Bulk export and real data remain excluded from both the workflow and the illustrative engagement.

These are this workflow's operating boundaries. Separate investigative activity needs its own plan under the engagement's written scope and rules of engagement. Mia reviews changes to the workflow; Jo must authorise any extension beyond the existing written authority before activity proceeds.

## Responsibility

All names are fictional. Jo Morgan is the application owner who confirms authority, the expected rules, the permitted window and restoration arrangements. Mia Patel is the technical lead and workflow owner. Mia reviews workflow changes, checks the supporting evidence and decides whether this workflow is released for the defined use. Rowan Ellis executes the checks and records exceptions; Rowan can stop immediately without waiting for approval.

These responsibilities need named people, not three new posts. Here Mia reviews Rowan's records. If the same person prepares and executes a change, another competent practitioner must inspect its material evidence before release. Jo receives application incidents and approves changes to authority; Mia receives execution failures and unsupported conclusions.

## Prerequisites and expected behaviour

Before starting, Rowan confirms the signed scope, actual build, agreed permissions matrix, designated account roles, fixture baseline and evidence storage. Jo confirms a permitted window; the illustrative window is 09:00 to 11:00 Europe/London on the agreed test day. Mia confirms review time and a contact route during that window. A missing prerequisite means the affected checks are **Not tested**; it is not evidence that a boundary held.

For each account, confirm a valid session and successfully read its own fixture before a negative check. Do not infer authentication solely from an error code or a login page. Session identity and tenant must match the selected account.

Under `PM-illustrative-1.0`, readers may read their own tenant's report but may not update it. Editors may read and update their own report's `review_note`. All accounts must be denied read and update access to the other tenant's report. A denied read must disclose no report content; a denied update must leave the fixture unchanged. Login expiry, a timeout or a recorder failure cannot satisfy these expectations.

Reader accounts represent the standard-user starting position. The editor-only update is the selected privileged operation; editor accounts also provide a positive control for the intended action.

The agreed matrix is a starting point for expected behaviour. It is not a complete account of possible abuse paths. Rowan must consider whether observations call for separate investigation rather than treating the matrix checks as the engagement's coverage plan.

## Execution and operating limits

1. Record the workflow version, build, matrix, configuration, executor, window and fixture baseline. Verify each account's identity, tenant and permitted own-tenant read.
2. Run each selected own-tenant read and editor update. Capture the request, response and relevant resulting state; restore an allowed update to `baseline` and verify restoration.
3. Attempt the selected reader update and cross-tenant read or update using only the designated fixtures. Check both the response and disclosure or state change. Confirm that the session remained valid against its own fixture before interpreting a denial.
4. Assign a result category and a separate security conclusion for each selected check. Record unexpected observations for review. For disclosure of a designated synthetic report during a declared read check, use only the bounded confirmation below, then pause routine execution. Stop immediately for failed prerequisites, controls or other stop conditions; do not continue to obtain a complete-looking record.
5. Rowan hands the evidence and gaps to Mia. Mia accepts or rejects each conclusion and records workflow readiness. Rowan and Mia decide whether further in-scope investigation is needed to address the engagement's objectives, separately from remediation or workflow re-evaluation.

For this illustration: one request at a time, no more than one request per second, at most 36 application requests including session checks and restoration, and at most two hours. Choose the checks before execution so this budget is sufficient. There is no automatic retry. Stop when the budget or window ends; remaining checks are **Not tested**. A failed prerequisite is corrected and rechecked only after the cause is understood and Mia approves resumption within the existing authority.

## Credentials, permissions and optional agent assistance

Jo provides the four designated accounts through the agreed secret store. Rowan uses a separate session per account. No administrator credential is needed. The recorder may capture only the approved application traffic; unrelated browser activity is excluded. Restrict destinations and tool permissions outside any model where feasible, and confirm the restrictions before starting. Do not store passwords, session tokens or authentication headers in this record, evidence exports or prompts.

The workflow operates without an agent. If used, an agent may suggest which existing matrix checks to prioritise or propose additional cases from a sanitised matrix. It receives no credentials, browser control or network execution tools. Mia reviews each proposal against the agreed scope and adversarial objectives; Rowan performs only approved checks. Changed workflow checks need Mia's review and a revised specification. Targets or actions outside the existing written authority also need Jo's explicit scope extension. Neither a proposal nor discovered content changes that authority.

Record the provider, model identifier and exposed version, prompt version, settings and available tools, plus the approved processing service. If a model version is unavailable, record that uncertainty and a dated run identifier. Application content and generated instructions cannot change operating limits. Mia rejects any unsupported explanation; a generated narrative is not evidence of a finding.

## Approval, stopping and recovery

Mia must approve a changed check, configuration or resumption after failure. Jo must authorise any proposed scope, account, data, processing-service or operating-window change before Mia updates the workflow. A useful request identifies the exact proposed action, account, target, reason, available evidence, likely effects and recovery plan. Silence is not approval.

If a declared read check unexpectedly discloses the designated synthetic report, Rowan records a candidate finding. The rules of engagement permit one isolated repeat of the same `GET`, using the same account, fixture and destination, only when authority, session validity and evidence capture remain confirmed. Session checks and that confirmation count towards the 36-request budget and must remain within the agreed rate and window. Rowan then pauses routine workflow execution and hands the evidence to Mia, who decides whether the observation supports a finding or needs further authorised investigation. This is a limited confirmation of a target weakness, not permission for open probing or extra target access.

Rowan stops immediately on ambiguous authority, real or unrecognised data, a request reaching an unexpected destination, failed authentication, timeout, unexpected state change, missing evidence capture, or failure of the workflow's destination or execution restrictions. A reader update that changes the fixture unexpectedly also requires a stop and restoration; the read-only confirmation allowance does not permit repeating writes. Preserve what is available, record the last action and affected checks, and notify Mia; notify Jo promptly if application state or data may have been affected. These conditions prohibit further testing until the cause and recovery requirements are addressed.

Jo can revoke account access and restore the fixture baseline. Rowan restores only the pre-agreed `review_note` change while the session and authority remain valid. Otherwise Jo performs restoration and confirms the state. Mia records the cause and decides what must be corrected and re-evaluated. Resume only after Jo confirms any affected environment is safe and Mia confirms prerequisites, authority and evidence capture.

## Evidence, classification and reporting

For each selected check record account and tenant labels, fixture, expected rule, actual action, timestamp, request and response references, authentication check and relevant before/after state. Record omissions explicitly. Store redacted evidence in the engagement's access-controlled location for Rowan, Mia and the agreed application recipients. Agree retention before use; the fictional arrangement is deletion 30 days after report acceptance unless Jo agrees an extension. Redaction must preserve enough context to review the conclusion. Do not copy client records into reusable workflows or agent prompts.

Use these result categories, separate from the security conclusion:

- **Tested with supporting evidence:** the intended authenticated action ran and retained evidence supports the stated conclusion. This can support an expected permitted action, an expected denial or a finding.
- **Tested but inconclusive:** the action ran, but missing or ambiguous evidence prevents a defensible conclusion.
- **Execution failed:** a session, prerequisite during execution, timeout or control failure prevented the intended check. No boundary conclusion follows.
- **Not tested:** the action was not attempted, including checks left after a stop or a missing initial prerequisite. State why.

An expected access denial with valid authentication and supporting evidence is a completed check, not an execution failure. An expired login is an execution failure, not evidence that the attempted attack was denied. Describe the security conclusion as the expected rule observed, a supported finding, or no conclusion. A finding needs inspectable evidence of unauthorised disclosure or change and the relevant expected rule. An explanation alone is insufficient.

The workflow record lists the selected checks and their categories, supported conclusions, gaps and limitations, versions and reviewer decision. Rowan uses this alongside the wider investigation when preparing the client report. Conclusions and coverage statements must stay within what the evidence supports. Execution completion does not establish engagement coverage, and selected checks cannot be extrapolated to the whole application.

## Remediation, maintenance and limitations

Mia sends supported issues to Jo with the affected rule, evidence references, build, reproduction context and stated impact. Jo owns remediation or risk acceptance. A fix triggers targeted retesting only within renewed or continuing authority: confirm the new build, repeat the case demonstrating the weakness and the relevant permitted action, and retain evidence. Inconclusive checks or execution failures need their causes addressed before repetition; they do not become findings by default.

Mia versions the specification, matrix references, configuration and evaluation record together. Re-evaluate before client use after permissions, routes, fixtures, authentication, tools, evidence handling or execution configuration change, and after any material failure. Agent model, prompt, tool or settings changes need the relevant proposal and scope cases re-evaluated. Keep the earlier version and its records where possible. If it cannot be restored, suspend reliance on its evaluation until the replacement demonstrates the agreed workflow behaviour.

## What this workflow does not cover

This workflow covers selected rules and fixtures only. It does not investigate every role, object type, route or concurrency condition. Depending on the agreed scope and observations, Rowan may need to investigate alternative access paths, relevant business-logic abuse or combinations of weaknesses that allow access beyond a single matrix rule. Those activities require a separate plan and applicable authority; these examples are not mandatory for every engagement.

In the walkthrough, the export-result endpoint is such a separate access path. It is investigated manually under existing engagement authority, not by extending this workflow during execution. The export finding establishes known-identifier access to a designated synthetic result; it does not establish how identifiers could be discovered or support a claim about every report.

Manual selection can omit useful checks. A small evaluation set supports a limited decision about the workflow's intended use, not comprehensive assessment capability. The illustrative stale-session classification and evidence-capture issues remain unresolved, so version `0.1.0` is not ready for client use.