Authorization

Horizon provides a shared access layer for the servers your organization deploys and the platform resources your team manages. After authentication identifies a caller, Horizon uses the same organization membership, server roles, custom roles, and capability policies to decide what that caller can see, manage, or invoke. This moves access policy out of individual server implementations and into the platform path. Security and platform teams can make servers broadly discoverable, restrict sensitive deployments to explicit users or service accounts, and expose only the MCP capabilities each role should use. Authorization in Horizon has two related paths: The same Horizon identity can appear in both paths, but the requested action is different. Calling a Horizon-served MCP endpoint lets a client use tools, resources, and prompts exposed by that server. Managing Horizon lets a user or service account change servers, members, API keys, builds, access settings, and organization settings. Authentication is separate. Authentication answers “who is calling?” Authorization answers “what is this caller allowed to do?” For the identity and credential path, see Authentication. Horizon evaluates authorization at three levels:

​

Request decision flow

When a protected MCP request reaches Horizon, the gateway checks access before the request reaches server code.

​

Actors

An actor is an identity that can authenticate, hold access, and own API keys. Horizon supports two actor types: API keys inherit access from the actor that owns them. If a user or service account loses organization membership, server access, or a role permission, requests made with that actor’s API keys lose the same access. Revoking an API key only disables that key; it does not change the owner’s role.

​

Organization roles

Organization roles control organization-wide management permissions. An organization admin cannot be hidden from a server in that organization. Use the admin role only for people and service accounts that should have broad administrative access.

​

Server roles

Server roles control what an actor can do with an individual server after they have access to it. Built-in server roles are available in every organization and cannot be edited. Custom server roles let you define additional server roles with specific server permissions for your organization. Use the role slug in policies and API payloads. No Access is a server default setting, not a role slug.

​

Server access resolution

For a member who is not an organization admin, Horizon resolves server access in this order: The server default role is the organization-wide visibility setting for a server. Set it to Viewer, Editor, Admin, or a custom role to make the server available to all organization members at that level. Set it to No Access to restrict the server to actors with explicit grants. Explicit grants are useful for exceptions. For example, a server can default to Viewer for the organization while granting Editor to the team that deploys it. Removing an explicit grant falls back to the server default role, if one is configured.

​

Custom server roles

Custom server roles are scoped to one organization. Use them when the built-in Admin, Editor, and Viewer roles are too broad for a server management workflow. Each custom role has: Custom roles can be used anywhere server roles are used: explicit server grants, server default roles, and capability-level access policies.

​

Capability-level access

Capability-level access controls which MCP tools, resources, and prompts are available to each server role. It is configured from a server’s Settings pages after Horizon has a manifest for the server. For hosted servers, saved capability policy changes apply to the dashboard immediately, but live MCP endpoint traffic uses the updated policy after the next deployment. Server explicit grant changes and server default role changes do not require a code change or rebuild. Capability access has two layers: When no capability policy is configured, the server’s capabilities are not filtered by tool-level access. After a capability policy is configured, any tool, resource, or prompt without a matching default or override is denied. Per-capability overrides can: Horizon keeps the admin server role allowed in capability policies. Organization admins and server admins can recover access to server capabilities.

​

Applying changes

Authorization changes have different lifecycle boundaries depending on what you change. For hosted servers, if you save default capability permissions or a capability override, redeploy the server before expecting MCP clients to see the new tool, resource, or prompt availability.

​

Common outcomes

​

Operational guidance

For production servers, keep Horizon authentication enabled and use server roles to control who can manage or call it. Prefer service accounts with narrowly scoped server grants for automation. Use No Access as the default role for sensitive servers, then grant explicit access to the users and service accounts that need them. Use a Viewer default for broadly discoverable servers where most users should be able to inspect or call safe capabilities. Use capability-level access for high-impact tools, sensitive resources, and prompts that should not be available to every server user. Keep destructive or write-capable tools restricted to roles that are meant to perform those actions.

​

Related docs