# A pagination cursor is not a forever pass

List endpoints often authorize once on page one, then trust the cursor for every next page. That is how a revoked membership keeps paging through results you meant to cut off.

## The bug pattern

A common flow:

1. `GET /items?limit=50` runs a real authorize + filter for the caller.
2. The response returns `next_cursor` encoding offset, last id, or a signed blob of the original filter.
3. `GET /items?cursor=...` skips the policy check and just resumes the scan.

Between page one and page three, the caller can lose access: role revoked, tenant membership ended, object ownership transferred, or a parent resource soft-deleted. The cursor still works because nothing re-evaluated actor + action + resource set.

## Why "the cursor is signed" is not enough

Signing the cursor stops *tampering*. It does not freeze a permission decision in amber.

- A signed `subject_id` + `filter` from ten minutes ago is still yesterday's grant.
- Opaque cursors that only store `last_seen_id` silently inherit whatever the DB returns next — including rows the caller should no longer see.
- Export / infinite-scroll clients hold cursors for a long time; revocation windows matter more there than on a single HTML page.

Integrity of the cursor ≠ freshness of authorization.

## What to enforce

On every page request, including cursor continuations:

- **Re-derive the allowed set.** Run the same authz filter (or PDP query) you used for page one, then apply the cursor *inside* that set.
- **Bind identity tightly.** If the cursor carries a subject or tenant, it must match the current session; mismatch → 401/403, not a helpful resume.
- **Fail closed on stale grants.** Prefer short cursor TTL plus re-check over "resume forever for UX."
- **Watch secondary paths.** GraphQL connections, search "load more," and async exporters that replay cursors need the same rule — not only the primary REST list handler.

## Tiny checklist

1. Does `?cursor=` hit the same authorize/filter path as the first page?
2. Can a revoked user still walk pages with an old cursor?
3. Does changing object ownership mid-scroll remove rows from later pages?
4. Are export jobs using the same rule, or a privileged "scan everything" shortcut?

Pagination is a read strategy. Authorization has to stay live on every page, not only the first.