noCV
AAUDIT-108 · Review and recover

Provide a scoped audit timeline with stable cursor pagination

Practice briefStoryIntermediate

Security reviewers need to inspect a repair sequence, but an unbounded audit endpoint times out and exposes unrelated organizations.

Focused work estimate
3h + prerequisites
Priority in the scenario
Medium
Engineering practice
Pagination · Audit review

Estimated field mix

  • Security40%
  • API design30%
  • Database engineering30%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional support console can reveal protected account settings and run repairs. The team needs bounded elevation, clear reasons and durable records of what happened.

Setup prerequisites

  • Create synthetic support actors and organizations.
  • Implement a local authorization boundary and append-only audit store.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Filter by authorized organization and bounded time window.
  • Order by committed sequence with a stable cursor.
  • Return safe action metadata without repair payloads.

Implementation constraints

  • Reject cursors bound to another scope.

Verification to include

  • Page a synthetic incident timeline while new events arrive.
  • Tamper with scope in a cursor and return a nondisclosing denial.

Deliverables

  • Audit timeline endpoint and scope tests

Rollout and recovery

Expose read-only timelines to a review role; revoke the route if projection checks fail.

Value of the work

For the engineer: Practice privileged workflows, denial paths and audit integrity.

For the team: Review accountable support operations without unnecessary access to customer data.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.