Skip to main content

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 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.

​
Organization roles (RBAC)

Organization roles control who can do what across the platform: create agents, manage integrations, view logs, change billing.
RoleTypical capabilities
OwnerFull administrative access, including billing and organization deletion
AdminManage agents, users, and integrations; cannot modify billing
BuilderCreate, configure, test, and deploy agents
OperatorRun and monitor agents; view logs; cannot modify configurations
ViewerRead-only access to agents and observability data
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)

For enterprise plans, 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.

​
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: specific to self-hosted deployments. Used by your SDK to authenticate to the Agent Controller in your cluster, distinct from your xpander Cloud key. See Self-Hosted Deployment for issuance and rotation.
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.
CategoryWhat’s logged
AuthenticationLogins, MFA events, SSO flows, API key creation and revocation
Agent lifecycleCreation, configuration changes, deployments, deletion, version updates
Tool invocationsWhich agent called which tool, with what parameters, and what was returned
Data accessKnowledge base queries, document uploads and deletions
Configuration changesRBAC role changes, integration credential updates, policy modifications
User managementInvitations, role changes, removals
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.
In self-hosted deployments, audit data stays in your cluster’s PostgreSQL; nothing transits xpander Cloud. This matters when audit data itself is regulated (HIPAA logs of PHI access, SOX records of financial system actions).