Skip to main content

​
Why this exists

Every teammate connecting an agent to your Shanone account could, by default, reach every one of the 269+ integrations Shanone implements. For most teams that’s too broad — engineers don’t need billing tools, and not everyone should be able to force-push to production repos through an agent. Shanone’s Permission Vendor lets a Root user (or a delegated administrator) control access at two levels of granularity:

Service-level

Enable or disable all tools belonging to one integration at once (e.g. turn off “stripe” entirely for a role)

Tool-level

Enable or disable one specific tool, overriding the service-level setting (e.g. allow github_create_issue but block github_delete_repo)
A tool-level override always wins over a service-level override, which always wins over the role default.

​
Roles

“SA2” refers to Shanone’s secondary-administrator role tier — an account can delegate specific policy actions (like managing other users’ tool permissions) to an SA2 user without granting full Root access. See SA2 Users for how SA2 users are created, how they sign in, and how policies work.

​
The Permission Vendor tools

Delegated SA2 users can manage permissions for regular members but never for Root users, regardless of what policy actions they’ve been granted.

​
Common workflows

​
Onboard a new hire with a scoped permission set

1

Look up service names

Call shanone_list_services to get the exact service_name values you’ll need (e.g. slack, github, notion).
2

Build a batch of operations

Construct a JSON array like [{"type": "service", "name": "slack", "enabled": true}, {"type": "service", "name": "stripe", "enabled": false}].
3

Apply it in one call

Call shanone_batch_set_user_permissions with the new hire’s target_user_id and the operations array (max 500 per call).
4

Verify

Call shanone_get_permission_summary for the same target_user_id to confirm the counts match what you intended.

​
Lock down one dangerous tool without disabling the whole service

This keeps every other GitHub tool available to that user while blocking just the one action.

​
Audit what someone can actually run

Returns their role, default access, and enabled/disabled counts for both services and tools — including the explicit list of disabled services. For the raw override list instead of a summary, use shanone_list_user_tool_permissions.

​
Master data warnings

If you set a permission for a tool_name or service_name that Shanone doesn’t recognize yet (usually a typo, or a tool added after your last sync), the call still succeeds and stores the override — but the response includes a warning like not found in tool permission master data. Double-check the exact name with shanone_list_services or shanone_search_tools before assuming the override is broken.

​
Next steps

SA2 Users

How Root and SA2 accounts differ, and how to create and manage SA2 users

Tools Reference

Full parameters and example requests for every Permission Vendor tool

Troubleshooting

Fix “Permission Denied” and related errors