Skip to main content
Access control answers three questions, each enforced at a different layer:
  • Who can build and configure agents in your organization: organizational RBAC
  • What each agent can reach once running: agent-level scoping, enforced structurally
  • Whose credentials authorize a downstream call: connector authentication
Combined with SSO and audit logging, this provides identity-based, least-privilege, traceable governance. Where users sign in, and where audit data lives, depends on the edition: See Cloud, Hybrid, and Air-Gapped architecture.

​
Organization roles (RBAC)

Organization roles control who can do what across the platform: create agents, manage integrations, view logs, change billing. Granular permissions depend on your plan. Enterprise customers can define custom roles, such as a “deployer” that can promote agents to production but cannot edit them, paired with a separate “auditor” that can read all logs but cannot run anything.

​
Agent-level permissions

Each agent has its own bounded operation surface, separate from organizational RBAC. Permissions are enforced by what’s wired into the agent’s tool list, not by prompt instructions. See Security Architecture for the architectural rationale. What you scope per agent:
  • Tools and operations: each agent only has access to the connector operations explicitly enabled (e.g., a Jira agent gets list_issues and create_issue but not delete_project)
  • Data sources: knowledge bases attached per-agent (an agent can only retrieve from KBs it’s connected to)
  • Authentication identity: each agent runs as Integration User (a shared service account), End-User (per-user OAuth, so audit trails attribute actions to the right human), or Public (anonymous use)
  • Locked parameters: pin specific tool arguments (e.g., always use a specific account ID) so the model can’t override them at runtime
  • Step and token limits: cap how many tool calls or tokens a single task can consume
For high-impact actions where structural restriction isn’t enough (financial transactions, data deletions, outbound customer communications), pause the workflow on a Wait node for human approval before proceeding.

​
Single sign-on (SAML 2.0)

SSO is not one path for every edition. Cloud and Hybrid use xpander Cloud identity; Air-Gapped authenticates inside your cluster.

​
Cloud and Hybrid

For enterprise plans, sign-in is at chat.xpander.ai. xpander.ai integrates with your IdP over SAML 2.0. User provisioning, deprovisioning, password policy, and MFA enforcement live in your IdP and propagate to xpander automatically. When someone is disabled in your IdP, their xpander sessions terminate and future access is revoked, including any associated personal API keys. Supported providers include Azure AD / Microsoft Entra ID, Okta, Google Workspace, Ping Identity, JumpCloud, and any other SAML 2.0–compliant IdP. Contact us to enable SSO for your organization. On Hybrid, Workbench identity lives in xpander Cloud. After authentication, the console tells the browser which self-hosted cluster to use; chat, tasks, and results then go client-to-cluster. That sign-in traffic is browser-to-Cloud, not Agent Controller egress. See Hybrid Architecture.

​
Air-Gapped

Air-Gapped does not use xpander Cloud identity. Authentication runs in your cluster with no external dependency: bootstrap admin password, email OTP (works without SMTP; codes print via a chart script), or your own OIDC / OAuth / SAML provider configured through the in-cluster auth stack. See Signing In and Air-Gapped Architecture.

​
API keys

API keys authenticate programmatic access: application servers calling agents, CI/CD running deploys, the local SDK during development.
  • Personal API key: tied to a specific user and inherits their role. Use for development and one-off scripts. When the user changes role or leaves, the key’s permissions change or are revoked.
  • Organization API key: owned by the organization. Use for production applications and CI/CD pipelines. Admins create and rotate them, and they survive personnel changes.
  • Agent Controller API key: Hybrid. Used by your SDK to authenticate to the Agent Controller in your cluster, distinct from your xpander Cloud key. See Hybrid Edition for issuance and rotation. Air-Gapped mints inter-service and admin credentials in-cluster at install — there is no xpander Cloud key.
Treat all keys as production secrets: store them in your secrets manager, rotate on a regular schedule, and revoke immediately on any suspicion of compromise. Never check them into source control.

​
Audit logs

Every action by users, agents, or the platform itself is logged. Logs are immutable. Each entry captures timestamp, the acting user or agent, the action, the affected resource, request context, and outcome. Audit data is accessible from three places:
  • Day-to-day debugging of a specific agent: the per-agent observability views in the Workbench show threads, tasks, and tool calls in context. See Observability.
  • Programmatic access to one task’s history: the Task object exposes a full message and reasoning log via SDK and REST API.
  • Compliance reviews and security investigations: export or stream audit logs to your SIEM.
Where those records live depends on the edition. This matters when audit data itself is regulated (HIPAA logs of PHI access, SOX records of financial system actions).