Agents, keys and policy
What an agent can do, how it signs in, and who sets its policy.
An agent is anything that calls briq for a team. The dashboard's Agents page lists them, and each has a policy, checked before any machine is created. Two kinds, treated the same:
| Connected client | API key | |
|---|---|---|
| For | A client on a machine with a browser: Claude Code, Cursor, VS Code, Codex, Claude… | CI, containers, scripts, the REST API |
| How | Add the MCP URL; the client signs in through your browser and you approve it | Create it on the Agents page, send Authorization: Bearer bq_live_… |
| Secret | Tokens the client keeps and refreshes; never shown to the model | The key, shown once |
| Policy | Set on the approval page | Set at creation |
Both are editable and revocable on the Agents page; revoking takes effect immediately. A connected client lasts as long as the person who approved it stays in the team.
Each agent shows the client that last used it (Claude Code 2.1.278, Cursor, curl 8.7.1), and the audit log records it on every row.
The policy
| Field | Default | Effect |
|---|---|---|
maxConcurrentBriqs | 5 | Live briqs the agent may have at once |
dailySpendCapCents | 1000 | Daily spend. Checked before create; the agent's briqs stop when it is crossed, and sleep again from the next UTC day |
allowedSizes | nano, small | The team's plan must allow them too |
allowedRegistries | docker.io, ghcr.io, quay.io | Image hosts allowed (docker.io covers unqualified images) |
maxSleep | "never" | The longest sleep the agent may give a briq, as a string ("1d"). "never" sets no bound of its own: the environment's longest window and the plan (always on is Pro and above) still apply |
expiresAt | none | The agent is rejected after this time |
A key is the team's: it sees and acts on everything in the team, every briq, stack, endpoint,
the audit log, the list of keys and agents, under the budget its policy sets. The policy bounds
what the key spends, not what it reaches; for a narrower reach, make a separate team. The one
thing a key never does is manage credentials: only a person signed in to the dashboard creates,
edits or revokes keys and connected clients, and an API key calling those routes gets
403 forbidden. So an agent cannot raise its own budget, mint itself a wider key, or cut off the
team's other agents. A policy is also bounded by the plan of the person setting it
(402 policy_violation past it), and it applies to a start as to a create: a key capped at one
briq cannot keep restarting others. Keys outlive the person who created them: removing a member
keeps the team's keys and lists the ones they created, for the team to rotate if it wants to. See
Budgets.
Each key and each connected client is one of the team's agents; the plan sets how many a team may have.
Errors
| Code | HTTP | When |
|---|---|---|
policy_violation | 402 | Size, registry or sleep not allowed. The message says the longest sleep to send |
quota_exceeded | 402 | Concurrency limit or daily cap reached |
payment_required | 402 | The team is out of credits |
plan_limit | 403 | The team's plan does not allow it: a size, more disk, an always-on briq, another agent, another member |
Over MCP the same message comes back as a tool error. briq_quota (or GET /v1/quota) reports
what is left, so a model can plan instead of retrying.