Teams, Roles, and Audit Logs

When a single key is no longer enough

In a large organization, not all users have the same needs or rights. A developer needs to call the API, a finance manager needs to view billing, and an administrator needs to manage everything. As long as three people share a single key, the issue remains theoretical and everyone gets by. But once thirty people across five projects call the same API, the lack of structure results in incidents that are hard to attribute and bills that no one can explain. xAI’s Enterprise offer structures this access through a system of teams and roles.

What a team covers

A team in xAI represents a group of users sharing common resources: API keys, provisioned capacity pools, billing, and spend limits. Each team has its own keys with specific ACLs, independent spend limits, separate usage metrics, and traceable billing. In practice, a team that exhausts its monthly budget doesn’t block the others, and finance leadership can answer the question “how much does the chatbot project cost us?” without manually reconstructing the figures in a spreadsheet.

Three structures come up regularly, and the right choice depends on how your organization makes budget decisions. Splitting by department—equipe-engineering, equipe-data, equipe-support—works when each service owns its budget and accounts for its consumption. Splitting by project—projet-chatbot, projet-analyse, projet-recherche—makes sense when initiatives are cross-functional and funded separately, with contributors from multiple services. Splitting by environment—team-production, team-staging, team-dev—best protects production: an experiment that spins into an infinite loop on a Friday night then consumes the development budget, not customer service.

Roles and the principle of least privilege

Roles define what each member can do within a team. The administrator handles full management: keys, members, billing, limits. The developer creates and uses API keys and views metrics, without touching team settings. The reader views metrics and billing without any modification powers, which fits piloting and reporting profiles. The billing role, finally, manages payment methods and views invoices, without any technical access.

Assign each user only the rights necessary for their mission. This fundamental security principle limits the impact of a compromised account, and its daily application is straightforward: a frontend developer needs only chat models, not image generation models; a data scientist has no reason to access billing; an intern should work in read-only mode. Applying this grid to an existing user list almost always reveals two or three people with administration rights because it was the fastest solution on their start date, and no one has revisited it since.

Lock down each key with ACLs

The Management API allows you to define granular access controls (ACLs) on each API key:

{
  "name": "cle-chatbot-support",
  "acls": [
    "api-key:endpoint:chat",
    "api-key:model:grok-4.3"
  ],
  "qps": 10,
  "qpm": 100,
  "tpm": 500000,
  "expireTime": "2026-12-31T23:59:59Z"
}

This key illustrates the previous principle exactly: it calls only the chat endpoint, only with grok-4.3, within a limit of 10 requests per second, and it stops working at the end of the year. If it leaks, an attacker can neither generate images nor query a more costly model, and their exploitation window is bounded in time without any intervention from you. ACLs cover four dimensions: authorized endpoints among chat, embed, image, tts, tokenize, and documents; accessible models, with restriction to one or more specific models; rate limits expressed in requests per second (QPS), per minute (QPM), and tokens per minute (TPM); and the key expiration date.

Your account’s memory

Audit logs record all significant actions performed on your Enterprise account: user logins and logouts, API key creation, modification, and deletion, role and permission changes, billing and spend limit modifications, key rotations. They constitute an essential element for compliance as well as incident detection.

Their utility shows up in four areas. For compliance, they demonstrate to auditors that access is controlled and traced, which directly feeds SOC 2 and HIPAA documentation. For investigation, they allow you to retrace actions during an incident: knowing which key was created, by whom, and at what time turns an assumption into an established fact, and considerably shortens crisis meetings. For optimization, they reveal unused keys and abnormal patterns, for example a test key that still runs six months after the prototype was abandoned. Finally, for governance, they verify that access policies are actually respected, not just written in a memo.

Key takeaways

• Teams allow you to segment access, billing, and limits by department or project
• Roles apply the principle of least privilege to each user
• API key ACLs control endpoints, models, rate limits, and expiration
• Audit logs trace all significant actions for compliance and investigation
• Structure your teams from the start to avoid governance debt