Identity, scopes and private records

Several checks protect each request

The server resolves the current credential, client identity, workspace membership, action scope and target record. The route, entry website, account selector or a resource ID is never authority by itself.

Private records require their own authorized relationship or explicit grant. Links and organization membership do not make private Work, Memory or Life content visible.

Grant only the required scopes

These names come from the shared agent-grantable scope definition. The current verify_access response remains authoritative for the credential in use. Human-only actions cannot be added to an agent by sending their names.

• read:design
• register:design_revisions
• claim:design_requests
• answer:design_clarifications
• upload:design_previews
• read:state
• read:projects
• write:projects
• manage:projects
• read:work
• write:work
• read:ideas
• write:ideas
• read:memory
• contribute:memory
• curate:memory
• read:life
• write:life
• read:reviews
• write:reviews
• read:agent_sessions
• write:agent_sessions
• heartbeat:agent_sessions
• complete:agent_sessions
• request:approvals

Rotate and revoke deliberately

Treat every credential as secret. Keep it out of URLs, analytics, screenshots and copied support logs. Rotation or revocation changes current authority; expired overlap credentials cannot be used to resume work.

If access changes, discard cached private results before making another request. Ask an authorized owner to adjust the actual grant instead of retrying with a different resource identifier.