> ## Documentation Index > Fetch the complete documentation index at: https://docs.xpander.ai/llms.txt > Use this file to discover all available pages before exploring further. # Access control > How people, agents and API clients are identified, scoped and recorded on xpander, and where that record lives per deployment. Access control on xpander answers three questions: * **Who may configure agents in your organization**: roles and groups. * **What each agent may reach once it runs**: the skills it was given, and the approvals on them. * **Whose identity a call carries**: the organization's, or the asking person's where systems allow. Every call an agent makes passes through xpander and is recorded under the person who asked. The settings behind each control are on [Govern every agent](/run/govern); this page is the reference. ## Where identity and records live | Deployment | Sign-in | Records | | - | - | - | | **Cloud** | Xpander Chat, with email code, Google, GitHub, or your OIDC identity provider (enterprise plans) | xpander's cloud | | **Hybrid** | Xpander Chat, same as cloud | Tasks, skill calls, data access and agent changes stay in your cluster's PostgreSQL; identity is cloud | | **Air-gapped** | Inside your perimeter: bootstrap password, email code, or your OIDC identity provider | Your cluster; nothing is sent to xpander | ## Organization roles | Role | What it allows | | - | - | | Super admin | Everything, including organization settings, billing and members | | Admin | Members, groups, skills and their connections, providers and models, budgets, approvals, audit logs | | Team member | Use and assemble agents within what admins approved; connect personal accounts to skills where allowed | Members are managed under **Settings > Team**. **Settings > User groups** gives groups shared defaults and can follow the identity provider's groups through OIDC group sync. ## Agent scope An agent reaches only the skills it was given. An admin approves skills for the organization; a person adds them to an agent. Within a skill, individual actions can be marked as needing approval, and for agents on Claude Code, Codex or OpenCode, gated commands hold matching shell commands. Knowledge bases are attached per agent. Budgets cap what a single agent may spend. A skill's connection is organization-wide or personal. With a personal connection the agent acts with that person's own permissions in the outside system, where systems allow, so the system's own access control still applies and its logs name the person. ## Skill visibility Beyond who may see a skill in the registry, each skill carries a visibility level that decides which agents may hold it: | Visibility | Which agents may hold the skill | | - | - | | `org` | Any agent in the organization | | `restricted` | The agents on the skill's allowlist, set when the skill is published from a repository with `xpander.yaml` | | `agent` | One owner agent | **Who may change a scope.** The skill's creator and admins (Super admin or Admin) change a skill's visibility and edit its allowlist. Anyone else sees the organization's catalog plus the skills scoped to agents they manage, and cannot widen a scope. Attaching a skill to an agent outside its allowlist is refused. **How the runtime enforces it.** Enforcement is structural, like [agent scope](#agent-scope): an agent's workspace holds only the skills it may hold. The runtime filter builds the workspace from the skills the agent's scope allows and leaves the rest out, so a scope change applies on the agent's next run without editing the agent. The filter's switch has these positions: | Mode | Behavior | | - | - | | `off` | Every attached skill loads; scope is not checked at runtime | | `report` | Every attached skill loads; each skill the agent may not hold is recorded as a violation in the logs | | `enforce` | Skills the agent may not hold stay out of the workspace | The default is `report` for the current release, so teams can review the recorded violations before enforcement changes what an agent loads; `enforce` follows. **Self-hosted.** The switch is the `XPANDER_SKILL_VISIBILITY_MODE` environment variable, with the values `off`, `report` and `enforce`. The air-gapped chart renders it from `global.skills.visibilityMode`, so set the mode in your values file rather than on the Deployment. Scope and allowlist changes, publishes and archives are recorded in the audit log as `UPDATE_SKILL_ACCESS`, `PUBLISH_SKILL` and `ARCHIVE_SKILL`; see [The record](#the-record). Skills published from a repository take their scope from `xpander.yaml`; see [Publish Skills](/api-reference/v1/skills/publish). How the scope looks to the person adding a skill is on [Skills](/use/skills#skill-visibility). ## Single sign-on Sign-in with your identity provider uses OIDC. On cloud and hybrid, an admin configures it under **Settings > OIDC (SSO)**. On air-gapped installs the same configuration runs inside the perimeter; setup, identity provider client settings and troubleshooting are on [SSO with your identity provider](/self-hosted/sso). Provisioning, deprovisioning and multi-factor policy stay in your identity provider. Group claims can map to xpander groups. ## API keys **Settings > API keys** issues organization keys for applications and pipelines; a key can be limited to specific agents. Each person also has a personal key that carries their own identity. On hybrid installs the SDK authenticates to the Agent Controller in your cluster with a key minted there; air-gapped installs mint all credentials in-cluster at install time. Keep keys in your secrets manager and rotate them. ## The record **Per task.** Every task's thread holds the messages, each skill call with parameters and result, and each model call with its cost, under the person who asked. Available in Xpander Chat (Task Manager) and over the API (`GET /v1/tasks/{id}/thread`, `GET /v1/tasks/{id}/llm_usage`). **Organization audit log.** **Settings > Audit logs**, filterable by event type and exportable as CSV or JSON. Event categories: | Category | Events | | - | - | | Agent | Created, updated, deployed, deleted, version discarded, live surface created or regenerated, skill created or added, shared, share revoked | | Skills | Created, connected, connection updated or removed; visibility or allowlist changed (`UPDATE_SKILL_ACCESS`), published from a repository (`PUBLISH_SKILL`), archived (`ARCHIVE_SKILL`) | | Vault | Secret created, updated, deleted, read, used, captured, restored to plaintext; workspace secrets updated; model provider keys changed | | User | Login, logout, invitation | | User groups | Created, updated, deleted, member moved, OIDC group sync | | Conversation | Shared, share revoked, deleted, renamed, file shared, workspace command invoked | | Organization settings | Changes to organization-level settings | ## Related * [Govern every agent](/run/govern): the settings behind each control. * [Approvals](/use/approvals): what a person sees when a run waits. * [Security architecture](/resources/security-compliance/security-architecture) per deployment. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.