Permissions.
A plugin can touch site data only through grants you give it. Grants are default-deny: a plugin with none can read and write nothing. There is no wildcard that grants everything; you enumerate what a plugin needs.
Grants
A grant is a allowed_permissions list. Each call the plugin makes through fs.collection is checked against these.
| Form | Grants |
|---|---|
blogs:read | Read access to that resource. |
products:write | Create and update that resource. |
leads:* | All actions on a resource. |
posts:type-30:read | Read access to a custom post type, by its number. |
There is deliberately no *:*. Default-deny is the point: an operator grants exactly what a plugin needs, no more.
Actions
| Action | Covers |
|---|---|
read | Reading (a GET). |
write | Creating and updating (POST, PUT, PATCH). |
delete | Deleting. |
manage | Sensitive or administrative operations. Never granted implicitly; a route that needs it asks for it directly. |
Resources
Content types use their plural alias: blogs, products, pages, events, services, collections, categories, and the rest of the twenty. The system types (site configuration and domain records) have no alias and cannot be granted, even by number.
Other resources are independent route trees: comments, leads, files, users, customers, sites, redirects, templates, notifications, orders, subscriptions, analytics, cart, commerce, storage and bits.
The role cap
Grants say which resources; the role cap says how much authority the plugin carries when it acts. A plugin acts as the user who created it, but never above its effective_role. It cannot inherit a platform staff bypass, and its role is always scoped to the plugin's own site, so a plugin can never reach across tenants.
Data access is checked twice. First the plugin's own grants must allow the