Workspace isolation

Everything is workspace-scoped

Sites, agent keys, actions, approvals, uploads and support threads all belong to exactly one workspace. Every request is resolved against the caller's workspace before anything is read or written, and the database enforces the same boundary independently of the application code.

An identifier from another workspace behaves as if it does not exist — a 404, not a permission error. That distinction matters: a permission error would confirm the id is real. The same rule applies to upload links, post actions and site handles alike.

Keys are scoped inside the workspace

• An agent key can be scoped to specific sites. Out-of-scope sites are invisible to it, including in list_sites.
• A key can carry its own monthly publish cap.
• Revocation is immediate.
• OAuth-connected MCP clients act as your account, within the same workspace boundary.

The blast radius

Pressbotics is a publishing rail, and its capabilities are deliberately narrow. It does not:

• Managing WordPress users
• Changing site settings
• Installing, activating or configuring plugins
• Changing or editing themes
• Running WordPress core updates

So the worst a compromised agent can do to your site is publish something you can revert — one click in Activity unpublishes it and keeps the content as a WordPress draft, or restores an earlier version, and you still have your own editor and your own revision history. It cannot create an administrator, install a plugin or change a theme, because those tools do not exist in the surface at all.

Reducing it further

• Keep untested agents on review-everything.
• Give each automation its own key, scoped to one site.
• Check Activity periodically — every action records which agent, which site and what happened.