Governance
Control exactly what your agent can do and who can use each tool: capability enablement and approval, per-user availability, and the actions your widget registers on the page.
Governance is where you decide what the agent is allowed to do. Three surfaces work together: capability governance for your API capabilities, tool availability for who can use each tool, and abilities for the actions your embedded widget registers on your own page.
Capability governance
Capability governance (/governance) lists every capability the CLI discovered. Each row carries a side-effect badge and two independent toggles.
- Enabled — whether the capability is advertised to and callable by the agent. Off means invisible.
- Require approval — forces a confirmation step before the capability runs. Enabling approval never enables a disabled capability; the two toggles are independent.
- Side-effect badge — read, write, or destructive, so you can see at a glance which capabilities change data.
Tool availability
Tool availability (/tool-availability) decides which tools the chat and MCP surfaces offer each end user. Every tool is available by default and your own API enforces permissions; add a rule to target a tool to specific users. Rules match on identity, not on time — there is no scheduling here.
- Require sign-in — offer the tool only to authenticated users.
- Required scopes — gate the tool on OAuth scopes, matching all or any.
- Attribute matchers — target an identity claim or a host-context attribute with an operator and a value.
- Advanced rules — for logic the simple form cannot express, edit the rule as JSON with and/or/not expressions.
Abilities
Abilities (/abilities) governs the actions your embedded widget registers on your page with syncanix.registerAction — client-side actions like refreshing a list. They are distinct from catalog capabilities, which are your API endpoints.
- Kill switch — a master toggle that stops the agent performing any registered action, regardless of the per-ability switches.
- Per-ability Active toggle — an inactive ability is never advertised to the agent and cannot be called.
- Confirmation — an ability can require the end user to confirm before it runs. You can also declare an ability ahead of the widget registering it.