Access Control (ACL)

XAI XAPI provides access control to define how an account can use platform resources. The purpose is not to create more configuration work, but to keep risk within acceptable boundaries when you collaborate across teams or distribute capability downstream.

What problems does access control solve?

Access control is typically used to:

• restrict request origins and reduce abuse risk after key leakage
• restrict usable capability scope so accounts do not exceed what they should access
• carry upper-level governance boundaries down into lower-level accounts
• keep clearer separation between teams, customers, projects, and environments

Core principles

You do not need to memorize field names on this page. For most users, the important principles are:

• access control defines what is allowed, not what you fix after a mistake
• lower-level accounts can narrow scope, but should not expand beyond upper-level boundaries
• access boundaries should match real business boundaries
• production environments should be stricter than testing environments

Typical control boundaries

In practice, access control usually works across three kinds of boundaries:

• origin boundaries: which networks, environments, or entry points can send requests
• capability boundaries: which models or features an account may use
• operation boundaries: which kinds of interfaces or resources an account may access

Practical guidance

• split accounts by purpose instead of letting one account handle every scenario
• keep stricter origin controls for production usage
• use a default-narrowing model for downstream teams or customers
• review logs regularly to confirm that permissions still match the business boundary