Permissions and policies.
Why a call was denied
Each instance on a connection either has a policy attached or allows tools by kind (read, create, edit, delete). With a policy, only the tools on its allow list can run; everything else is denied, including tools a later spec adds. Without one, the connection allows whole kinds. On top of either, the caller's role limits by kind: admin can do everything, member cannot delete, viewer can only read. Public connections are always read only. Each instance's policySummary in the context says what is allowed; zeqqat_policy returns the full allow list; zeqqat_search marks each tool with allowedOn, the instances it can run on. A denied call was not sent. Tell the user; a workspace admin can change it in Connections. Policies are edited in Policies by the account's owner: the one owner of a personal account, or an owner of an organization.
What a policy is
A policy is an explicit list of tools (operationIds) an agent may run. It is owned by an account and written for one integration, so its name reads @username/integration.policy.name, for example @gaita/dokploy.policy.read_plus_deploy. It is attached to an instance inside a connection, one policy per instance. It works on any instance whose integration has the same spec, whoever imported it. Policies can be public: anyone can copy one into their own account. A copy is theirs and never changes when the original does; they get an update note instead. A policy records the spec release it was written for; when the spec changes, the dashboard warns the owner to review it.