Next.js Private Workspace Cache Review

A private workspace page must return data for the authorized account even when the application uses shared caches. Review that behaviour with two controlled accounts and explicit expected results, rather than inferring privacy from a lock icon or a framework choice.

MCPGram, listed in the Next.js catalogue on October 3, 2026, describes connected apps, a tool catalogue and workspace controls. That makes workspace boundaries a relevant evaluation topic. Its listing does not expose cache configuration, and this guide reports no penetration test or known vulnerability in the product.

Establish an authorized test surface

Use only accounts and workspaces you own or have explicit permission to test. Create harmless, unmistakable labels for workspace A and workspace B. Do not use production secrets, access tokens or real customer documents as markers.

Write down which information should be public, account-specific or workspace-specific. A public connector name might be shared intentionally; an installed connection and its permissions belong to a different boundary. The test should distinguish these cases before treating any repeated text as a leak.

Examine transitions that reuse interface state

Sign into account A, view its workspace, then sign out and enter account B through the normal interface. Observe the first rendered state, the settled state and navigation back to an earlier page. A stale label briefly displayed from browser state is a different defect from a server returning another account's data, but both deserve accurate documentation.

Repeat with separate browser profiles to distinguish shared server behaviour from one browser's retained state. Keep the sequence and response evidence, avoiding screenshots that expose credentials. Do not probe unrelated account identifiers or attempt to bypass authorization.

Ask where runtime identity enters the request

Next.js documentation distinguishes cached content from runtime-dependent work. For a private screen, the implementation needs a deliberate relationship between user identity, authorization and any retained result.

Ask the team to explain that relationship at a level suitable for review. Which facts identify the workspace? Where is membership checked? Can a cached representation outlive a revoked membership? These questions are more useful than demanding that every response be uncached.

The interface may cache public catalogue data while resolving private connection state separately. A review should preserve that distinction rather than treating all caching as unsafe or all database filtering as sufficient evidence.

Include membership changes

Within the controlled setup, remove a test member and confirm the documented result across an open tab, a fresh request and a previously visited route. Record whether the application asks the user to refresh, immediately removes access or returns a clear authorization response.

Also test switching between two workspaces the same account legitimately belongs to. Correct account authentication alone does not prove that the selected workspace controls each result. The displayed workspace name, available actions and returned records should agree.

Turn observations into a release decision

Record the tested build, account roles, transitions and actual outcomes. Mark unsupported scenarios as unknown rather than claiming a security certification. Any unexpected cross-account data requires the product's normal private reporting process.

For public pages, the complementary concern is timely propagation. The Next.js content freshness review provides an editorial update exercise without weakening the private boundary examined here.