- 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.
Where identity and records live
Organization roles
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:
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: 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:
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. Skills published from a repository take their scope from xpander.yaml; see Publish Skills. How the scope looks to the person adding a skill is on Skills.
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. 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:
Related
- Govern every agent: the settings behind each control.
- Approvals: what a person sees when a run waits.
- Security architecture per deployment.