Skip to main content
Roles decide what an authenticated actor can do after Horizon knows who is calling. An actor can be a user or a service account. API keys inherit access from the actor that owns them, so rotating a key changes the credential, not the actor’s role. Horizon uses roles in three places:

Organization

Controls organization-wide management, including members, invitations, billing, SSO, service accounts, connectors, and server role definitions.

Server

Controls access to a specific server, including who can view it, update it, deploy it, manage access, or administer server settings.

Capabilities

Controls which MCP tools, resources, and prompts are visible to each server role after the actor has server access.
Custom server roles are available on . Tool-level access is available on .

Decision flow

When Horizon evaluates access, it works from the broadest boundary to the specific action.
1

Check organization membership

The actor must belong to the organization. Actors outside the organization cannot use or manage its resources.
2

Apply the organization role

Organization admins can manage organization settings and are treated as the admin server role on every server in the organization. Organization members continue to server-specific access checks.
3

Resolve server access

For non-admin members, Horizon uses an explicit server grant first. If no explicit grant exists, Horizon uses the server’s default role. If neither exists, the actor has no access to that server.
4

Filter capabilities

If capability access is configured, Horizon filters MCP tools, resources, and prompts by the actor’s effective server role.
Server access resolves by precedence. Horizon checks each rule in order and stops at the first one that applies:
OrderIfResulting access
1The actor is an organization adminadmin on every server
2An explicit server grant existsThe granted role
3The server has a default roleThe default role
4None of the aboveNo access
For the full request path, see Authorization.

Organization roles

Organization roles answer: “What can this actor manage across the organization?”
RoleContract
AdminCan manage organization settings and has full access to every server in the organization. Horizon evaluates organization admins as the admin server role for server and capability access.
MemberCan read basic organization information and can access servers only through explicit server grants or server default roles.
Use the Admin role for people and service accounts that should manage broad organization concerns such as membership, billing, SSO, service accounts, connectors, and custom server roles. Admins cannot be hidden from individual servers in that organization. Organization role changes affect the next authenticated Horizon dashboard, REST API, or MCP request that resolves the actor’s current access.

Server roles

Server roles answer: “What can this actor do with this server?” Horizon includes three built-in server roles. Built-in roles are available in every organization and cannot be edited.
RoleSlugServer managementMCP endpoint access
AdminadminFull server access, including access management, configuration, builds, capability policies, and deletion.Can call the server and all capabilities. The admin role stays allowed in capability policies so administrators can recover access.
EditoreditorCan view and update server configuration, create builds, and edit capability policies. Editors cannot grant or revoke server access and cannot delete the server.Can call the server. Capability policies can allow or deny specific tools, resources, and prompts for this role.
ViewerviewerCan view the server, its access list, and its capability policy. Viewers cannot modify the server.Can call the server. Capability policies can allow or deny specific tools, resources, and prompts for this role.
No Access is a server default setting, not a role. Use it when the rest of the organization should have no server access unless they receive an explicit grant.

Custom server roles

Custom server roles are organization-scoped server roles. Use them when the built-in Admin, Editor, and Viewer roles are too broad for a server management workflow. Each custom role has:
FieldContract
NameStable role slug used in API responses and capability policies. It must be lowercase alphanumeric with optional hyphens or underscores. Built-in slugs such as admin, editor, and viewer are reserved. The name cannot be changed after creation.
LabelHuman-readable name shown in Horizon. The label can be updated.
PermissionsServer management permissions for the role. Updating permissions changes what holders of the role can do in Horizon.
Custom roles can be used as a server default role, assigned through explicit server grants, and referenced by capability access policies. Server role permissions control Horizon management actions. They do not decide which individual MCP tools, resources, or prompts a caller can use; capability access handles that narrower decision.
Before deleting a custom role, remove it from server defaults and explicit access grants. Also review capability policies that mention the role slug, so stale policy entries do not remain after the role is gone.

Default role

A server’s default role is the access level given to the rest of the organization when an actor does not have an explicit grant for that server. Set the default role from a server’s Settings > Authorization > Roles page.
Only organization admins and actors with explicit server grants can access the server.
Every current and future organization member gets that server role unless they have an explicit grant with a different role.
For sensitive servers, start with No Access and grant access only to the users or service accounts that need it. For broadly shared servers, use a default role that matches the access most organization members should have. Default role changes are saved in Horizon and then applied to live server access metadata. No code change is required.

Explicit server grants

Explicit grants are actor-specific access entries on a server. Use them for exceptions to the default role, such as a service account that can deploy a server while the rest of the organization can only view it. Manage explicit grants from a server’s Settings > Authorization > Members page. An explicit grant takes precedence over the server default role. If you remove an explicit grant, the actor may still keep access through the server default role or through organization admin access.

Capability access

Capability access answers: “Which MCP tools, resources, and prompts can this server role use?” It is evaluated after Horizon has resolved the actor’s effective server role. Capability policies can set default access for all capabilities, then override individual tools, resources, and prompts. When no capability policy is configured, Horizon does not filter the server’s capabilities by role. After a policy is configured, a capability without a matching default or override is denied. Resource templates use the resource access settings.
For hosted servers, saved capability policy changes are visible in Horizon immediately, but MCP endpoint traffic uses the updated policy after the next deployment. Server default role and explicit grant changes do not require a redeploy.

Where to manage roles

TaskHorizon location
Change a user’s organization roleOrganization settings > Members
Create or edit custom server rolesOrganization settings > Roles
Set a server default roleServer settings > Authorization > Roles
Add or update explicit server grantsServer settings > Authorization > Members
Set tool, resource, and prompt accessServer settings > Authorization > Permissions

Authorization

Learn the full request decision model for Horizon management and MCP endpoint traffic.

Members

Invite, remove, and review people in your organization.

API keys

Create bearer credentials that inherit access from their owning actor.