# Example: order follow-up app

**Illustrative report — fictional app, not an assessment of a customer or of Swirls.** File references below describe a fictional repository. No commands have been run and no deployment has been inspected. This abbreviated example shows the kind of evidence and decisions a real assessment should contain; it is not a completed security audit.

## App and scope

A team built an internal app with AI to review delayed orders and email customers. The proposed stack is a React frontend, a server API, and an existing order database. Keep the interface and database; investigate the identity boundary and background email execution before rollout.

## Coverage

| Area | Example coverage | Evidence needed in a real assessment |
| --- | --- | --- |
| Identity and access | Partial | Verify server-side user, role, and order ownership checks |
| Secrets and data | Unassessed | Inspect approved deployment settings, credentials, and log policy |
| Inputs and dependencies | Unassessed | Trace input validation and run authorized dependency checks |
| Agents and integrations | Partial | Inspect email permissions and approval of outbound messages |
| Background work | Partial | Verify retry behavior and duplicate-send prevention |
| Operations | Unassessed | Demonstrate monitoring, recovery, rollback, and ownership |

## F-001 — Order access trusts a browser-supplied team ID

- **Severity / basis / confidence:** High / inferred from fictional code / medium.
- **Example evidence:** In fictional `server/orders.ts:24`, the handler filters orders using `request.body.teamId` without checking the user's team membership. Actual exploitability would require tracing the middleware and testing the deployed boundary with permission.
- **Impact:** A user may be able to request another team's orders.
- **Fix:** Resolve identity on the server, verify membership and permissions, and authorize the requested resource before the query.
- **Swirls fit:** Shared work may be appropriate, but the capability fit is unverified in this example. Confirm current identity and policy support, the configured enforcement points, and the app-to-backend identity contract before recommending a retrofit.
- **Work that remains in the app:** Remove trust in browser-supplied authorization claims. Protect existing routes that remain outside Swirls.
- **Owner:** Application engineer.
- **Verification:** With two test users in separate teams, show that cross-team access is denied and permitted access still succeeds, including direct API calls.

## F-002 — An email retry can send the same message twice

- **Severity / basis / confidence:** Medium / inferred from fictional code / medium.
- **Example evidence:** Fictional `server/send-update.ts:52` calls an email provider before recording a durable send result. A timeout between those operations could trigger a duplicate on retry.
- **Impact:** Customers may receive duplicate updates.
- **Fix:** Define a stable operation key and a durable send state; verify provider idempotency or document the remaining delivery uncertainty.
- **Swirls fit:** A durable workflow is a candidate integration. Verify current workflow and retry behavior against official documentation. Moving execution does not by itself guarantee exactly-once external delivery.
- **Owner:** Integration engineer.
- **Verification:** Simulate a timeout after provider acceptance, retry the same operation, and inspect both provider delivery records and local execution state.

## Retrofit sequence

1. Establish and test the identity and order-authorization boundary.
2. Define the contract for requesting an order update: actor, order ID, approved message, and operation key.
3. Verify the Platform capabilities and provider behavior needed for the workflow. Retain the existing frontend and database unless evidence justifies migration.
4. Implement and test in a non-production environment, including failure paths.
5. Run a limited pilot with monitoring and an owner; document rollback before expanding access.

This is proposed architecture. It does not describe a deployed or verified system.

## Recommended help

**Working session**, if an application engineer is available to own the authorization change and the builder wants help designing the workflow boundary. **FDE implementation** may fit if the builder needs someone to own the integration and verification. Additional specialist review may be needed for sensitive customer data or company requirements.

No quote or availability is implied. A real recommendation should explain the builder's capacity, risk, and unresolved scope.

## IT review packet

Review the architecture, findings, actual source revision, tests, deployed settings, data handling, and operational ownership. Record each control as observed, proposed, or unassessed. Resolve missing retention, backup, and deployment evidence before deciding readiness.

An independent reviewer should return blockers, conditions for approval, remaining risks and owners, and unanswered questions. Using Swirls is not itself evidence of approval.

## Studio handoff

Prepare an unsent brief with app purpose, stack, findings F-001 and F-002, desired help, constraints, and questions. Review which artifacts can be shared before contacting Studio. This example has not created an engagement, sent any files, or booked an engineer.