For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Learn how AccessPolicy controls access at every layer — from registry operations and chat invocation to agent-to-agent calls at runtime.

Solo Enterprise for agentregistry uses a multi-layer approach to secure access to the registry and its AI artifacts, and to control the actions that registry users and deployed agents can perform.

Access control layers

Access is enforced at three layers, each building on the previous one.

Layer 1: Authentication

Solo Enterprise for agentregistry relies on an external OIDC-compliant identity provider (IdP), such as Keycloak, Okta, or Auth0, to authenticate users with the registry. Every request to the registry must carry a valid JWT that is issued and signed by the IdP. The registry validates the token against the IdP’s JWKS public keys on every request. A missing or invalid token is rejected with 401 Unauthorized before any policy is evaluated.

The OIDC configuration uses four separate clients, each serving a different part of the system.

For example OIDC setups, see Set up an OIDC provider.

Layer 2: User authorization

After a token is successfully validated, the registry extracts the role claim from the JWT to determine a user’s permissions. The claim that you want to use for the role can be configured by one of the following Helm values or environment variables:

After the role information is extracted from the claim, Solo Enterprise for agentregistry validates the type of user that tries to log into the registry. Solo Enterprise for agentregistry differentiates between the following user types:

The following example shows an AccessPolicy that grants a developers role read access to all agents and runtimes, and allows those users to invoke the myagent agent through the chat UI.

apiVersion: ar.dev/v1alpha1
kind: AccessPolicy
metadata:
  name: developers
spec:
  description: "Access policy for the developers group"
  principals:
    - kind: Role
      name: developers       # must match the OIDC group claim value
  rules:
    - actions:
        - "registry:read"    # controls catalog access
      resources:
        - kind: agent
          name: "*"
        - kind: runtime
          name: "*"
    - actions:
        - "runtime:*"        # controls chat invocation
      resources:
        - kind: agent
          name: myagent      # restrict chat to a specific agent

Layer 3: Agent runtime authorization

You can use the same AccessPolicy resource to control the actions that deployed agents can perform at runtime, such as invoking other agents or calling MCP tools. To scope a policy to an agent, you must set the spec.principals[].kind field to Deployment instead of Role and point it to agent deployment.

Depending on the runtime that you deployed the agent to, different prerequisites are required to enforce AccessPolicies during runtime.

The following AccessPolicy allows the myagent agent deployment to invoke the k8s-agent agent during runtime and to call the get_object tool of the runtime-mcp MCP server. Invoking other agents or calling other MCP server tools is denied.

apiVersion: ar.dev/v1alpha1
kind: AccessPolicy
metadata:
  name: k8s-agent-policy
spec:
  description: "Runtime access policy for k8s-agent"
  principals:
    - kind: Deployment
      name: myagent  
  rules:
    - actions:
        - "runtime:invoke" 
      resources:
        - kind: agent
          name: k8s-agent
        - kind: server
          name: runtime-mcp
          subresources:
            - tool/get_object

For an example for how to set up runtime authorization, see Agent runtime authorization.

How the layers work together

    sequenceDiagram
    participant User as User
    participant Agent as Agent
    participant IdP as IdP (Keycloak / Okta)
    participant AR as agentregistry
    participant GW as Gateway
    participant Target as MCP server / Agent

    Note over User,AR: Layer 1 — Authentication
    User->>IdP: Login (device flow, password credentials (CI/CD), or PKCE)
    IdP-->>User: Signed JWT (Groups: ["developers"], aud: ar-backend)
    User->>AR: API request (Bearer token)
    AR->>IdP: Fetch JWKS (public keys)
    IdP-->>AR: Public keys
    AR->>AR: Validate token signature, verify aud = ar-backend

    Note over AR: Layer 2 — User authorization (kind: Role)
    AR->>AR: Read Groups claim → match AccessPolicy principal
    AR->>AR: Evaluate registry:* / runtime:* rules
    AR-->>User: Response (catalog or chat)

    Note over Agent,Target: Layer 3 — Agent runtime authorization (kind: Agent)
    Agent->>GW: MCP tool call or agent invoke
    GW->>GW: Match calling agent → AccessPolicy principal
    GW->>GW: Evaluate runtime:invoke rule
    alt Allowed
        GW->>Target: Forward request
    else Denied
        GW-->>Agent: 403 Forbidden
    end
  

Next steps