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

Workflow pack README.

This pack helps a technical lead or delivery manager decide whether a reusable workflow is ready to support selected activities in an authorised offensive security engagement. Its worked example follows a consultant investigating whether a standard user can retrieve another tenant's reports. The client provides designated accounts and synthetic reports in two explicitly authorised test tenants. A permissions change explains why the assessment was commissioned.

The workflow supports selected report reads, role-restricted updates and evidence collection. It gives the consultant a dependable starting point while leaving room to investigate observations that the predefined checks do not cover.

OffSecDevOps is a practitioner-developed framework. This pack is a practical discussion aid, not a certification or independently validated assessment method.

## Files

- [workflow-specification-example.md](workflow-specification-example.md): completed **fictional and illustrative** specification, including scope, responsibilities, operating limits and evidence handling.
- [workflow-specification-template.md](workflow-specification-template.md): blank specification to adapt.
- [evaluation-record-example.md](evaluation-record-example.md): completed **fictional and illustrative** evaluation record with seven scenarios and a not-ready decision.
- [evaluation-record-template.md](evaluation-record-template.md): blank record for cases, evidence, issues and the release decision.
- `README.md`: this guide.

The downloadable ZIP contains these same five Markdown files. Completed examples describe invented observations and evidence references, not attached evidence or actual results. No security assessment or evaluation took place to produce them.

## How the workflow helps the consultant

In the fictional engagement, consultant Rowan Ellis uses the selected checks to establish how the designated reader accounts behave and retain evidence of the tested report routes. While reviewing an own-tenant report, Rowan notices that its download uses a separate authenticated export-result endpoint. The application owner, Jo Morgan, confirms that this endpoint should return a result only to users in the owning tenant; it is not an intentionally shareable signed bearer URL.

The engagement's written scope separately permits investigation of individual report exports in the two test tenants. Rowan and technical lead Mia Patel agree a limited manual check under those rules of engagement rather than adding the endpoint to the running workflow. An authorised Blue account supplies the known identifier of its synthetic export. Rowan requests that result using only the Amber reader's credentials and confirms from the response body and retained session-identity evidence that Blue's report was disclosed. One isolated confirmation is permitted by the agreed manual plan, after session and evidence checks. Rowan then pauses for Mia's review instead of continuing to probe.

That evidence supports a finding about access to the designated Blue export using a known identifier. It does not establish whether an attacker could discover export identifiers or access every report. The investigation of the export endpoint is separate from the workflow's permitted report routes. Bulk export, real data and activity beyond the written authority remain excluded.

This narrative assumes a workflow evaluated for its intended use, with its adaptation reviewed by Mia. The supplied `AUTHZ-1` version `0.1.0` is an illustrative draft with unresolved defects and must not be treated as ready for that engagement.

## Use and adaptation

Read the example specification and evaluation together. The evaluation deliberately retains a stale-session classification issue and an evidence-capture gap. Version `0.1.0` is **not ready for client use**. Meeting the criteria for a small evaluation set would support a limited workflow decision, not demonstrate comprehensive assessment capability.

Copy the two templates for your workflow. Replace the invented application, accounts, tenants, fixtures, people and limits with entries appropriate to the engagement and its adversarial objectives. Resolve authority, the permissions matrix, expected rules, prerequisites, ownership, execution limits, recovery and evidence arrangements before starting. The matrix is a starting point, not a complete account of abuse paths. Make a named readiness decision after evaluation and resolve material blockers before client use. References to existing agreements or evidence locations can keep the records brief.

A small consultancy can assign these responsibilities to existing people. Allocate time for evidence review and maintenance. Another competent practitioner should be able to follow the specification and inspect the evaluation without relying on its author's local knowledge.

The example uses a consultant and approved browser/request recorder. It is useful without an AI agent. Its optional agent role proposes checks from sanitised inputs and has no credentials or execution access. Neither an agent suggestion nor an unexpected observation can extend authorised targets or actions; proposed scope changes require explicit authority and reviewed controls.

## Workflow evaluation and assessment

**Evaluating the workflow** checks whether it performs its intended function, handles known conditions appropriately and produces usable evidence. The evaluation record supports the technical lead's decision about relying on it for a specified use.

**Conducting the assessment** means investigating the authorised adversarial objectives, adapting to observations and developing defensible findings and coverage statements. The consultant uses workflow output alongside the wider investigation. Client-report conclusions must stay within what the evidence supports.

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.

## What this workflow does not cover

The selected report-route checks do not cover the separate export-result endpoint. The narrative shows why that distinction matters: a denied read on one route cannot establish that every route to the same data enforces the tenant boundary. The supplied evaluation does not evaluate the manual export investigation.

Alternative access paths, relevant business-logic abuse or combinations of weaknesses may need separate investigation, depending on scope and observations. These are possible next steps, not requirements for every engagement. Discovery of a reachable resource does not authorise testing it; cross-tenant checks remain within the two agreed test tenants.

## Recording results

Keep the result category separate from the security conclusion and the evaluation decision about the workflow:

- **Tested with supporting evidence:** the intended action ran and retained evidence supports the stated conclusion, whether an expected permitted action, expected denial or finding.
- **Tested but inconclusive:** an action occurred, but evidence is insufficient or ambiguous.
- **Execution failed:** an execution problem prevented the intended check.
- **Not tested:** the action was not attempted; record the reason.

An expected denial is not an execution failure. An expired session, timeout or failed prerequisite is not evidence that an authorisation boundary held. A finding needs supporting artefacts; a generated explanation alone is insufficient. Record workflow version, application build and execution configuration, plus model and tool configuration when an agent is used.

A workflow that correctly identifies and records a deliberately vulnerable fixture meets that case's evaluation criteria, even though the target violates its access-control rule. Case 7 demonstrates this distinction. It does not close the other workflow issues or establish engagement completion.

An unexpected disclosure of the designated synthetic report during a declared read check can be recorded as a candidate finding. The specification permits one isolated confirmation of that same read only with valid authority, session and evidence capture, within the existing limits. Rowan then pauses routine execution for Mia's decision. Unclear authority, real or unrecognised data, unexpected writes, expired authentication and failed evidence capture require a stop and the agreed recovery arrangements.

## Maintain the adapted pack

Version the specification, execution configuration and evaluation together. Re-evaluate relevant cases after material changes or failures. Keep limitations and unresolved issues visible, including changes for which earlier results are no longer applicable. If a previous configuration cannot be restored, evaluate the replacement before relying on it.

Keep credentials, tokens, personal data and real client identifiers out of reusable files. Engagement evidence belongs in its agreed storage with appropriate access and retention. Sanitise and review reusable test patterns separately from client records.

For the pack introduction and individual downloads, see the site's [workflow pack page](https://offsecdevops.com/workflow-pack.html).