WorkOS published a testable checklist for letting agents act on user data without forwarding the user's session. The eight-item spine is: distinct agent identity, token exchange to a narrower audience-bound token, intersection of agent ceiling and user permissions, authorize every tool call, filter retrieval before model context, out-of-band approval for irreversible or external actions, dual-identity audit, and cascading revocation.
What WorkOS Published
On September 30, 2026, WorkOS published The AI agent permissions checklist for SaaS apps. It is organized by lifecycle — design, build, ship, operate, revoke — and written as rules you can fail closed against. WorkOS points to a companion best-practices guide for reasoning; this page is the list you test.
Delegated Versus Autonomous
A delegated agent acts for a specific user and must never exceed that user's access. An autonomous agent acts for an organization (a nightly cleanup job, for example) and needs its own tightly scoped role and owner. Effective permissions for a delegated agent are the intersection of the agent's ceiling and the user's current permissions — never the union.
WorkOS's five questions every agent request must answer: who is the agent; who is it acting for; what is it allowed to do in general; is this specific action allowed right now; can you prove what happened and undo access.
Tokens And Runtime Checks
- Never pass the user's session or access token to the agent. Exchange it (WorkOS cites RFC 8693 token exchange) for a new token that names both principals, is scoped to the task, and is bound to one API (RFC 8707 resource indicators).
- Access tokens live for minutes, not months. Anything without an expiry is a finding.
- Authorize every tool call, not once per session.
- Filter retrieval against the user's permissions before documents enter the model. Redacting the answer afterward is too late.
- Checks fail closed if the policy engine, approval service, or audit log is unreachable.
Risk-Tiered Tools
WorkOS sorts actions into four tiers:
- Low — search, read, summarize, draft: allowed, logged.
- Medium — undoable creates and edits: allowed, logged, rate limited.
- High — external send, delete, export: out-of-band user approval.
- Critical — payments, permission changes, bulk deletes, production deploys: approval plus step-up authentication.
Unknown tools default to high, not low. An approval covers one action with specific parameters, expires quickly, and can be used once. The approval channel is one the agent cannot forge.
Revocation
Revoking an agent kills current tokens, refresh tokens, and sessions it created for sub-agents. Deprovisioned users take their delegated agents with them — WorkOS names SCIM-driven deprovision as the directory path. Permission changes apply on the next call or refresh. There is a kill switch per agent type and per tenant, and revocation is rehearsed.
What The Checklist Does Not Prove
- This is WorkOS's operator list. Where the post names WorkOS products, those are implementation notes, not an Institute stack requirement.
- The checklist is not a rewrite of credential architectures, Airlock, or CoPhish consent.
- See also the Agent Identity and Know-Your-Agent and agent credential architectures playbooks.
Related: See our notes on CoPhish and agentic consent, Airlock, and SCIM for agentic identity.