Governance and limits¶
Governance answers three questions for each operation: who is acting, which resources they may use, and whether the work fits the applicable rules and limits. A successful sign-in answers only the first question.
Access is an intersection¶
Effective resource access is catalog ∩ Team allowance ∩ key policy. A resource must be available in the Organization, allowed to the Team, and permitted by the key. The key also needs the operation, such as model.generate or tool.invoke.
For example, if the catalog contains support and analysis, the Team allows only support, and a key allows only analysis, that key can invoke neither. Widening the key alone cannot bypass the Team ceiling. Human role assignment controls management actions separately.
Current owner membership, key status and expiry, Team status, resource eligibility and limits are checked as well. A rotated key retains its logical identity and accounting history; rotation does not reset spending.
Budgets and operating caps¶
An allocation assigns a governance ceiling. An operating cap further restricts actual use. Every applicable ceiling must admit the work; a generous key cap cannot override a smaller Team cap.
| Example | Effect |
|---|---|
| Team monthly spend cap of $100; key cap of $10 | Both apply to that key's work |
| Key cap left blank | No additional local cap; ancestor limits still apply |
| Key cap set to zero | Blocks work in that dimension |
| Request, token or concurrency cap | Limits rate or concurrent capacity independently of spend |
These are illustrative values. The Console accepts spend in USD; configuration and APIs use the documented units, including USD micros. Daily and monthly spend windows use UTC.
Finite spend limits require a bounded estimate: configured route pricing and a supported finite output bound for generation, or explicit tool pricing for a business tool call. Missing pricing or usage is unknown, not free.
One application action can cause several charges¶
A model round, provider retry or business tool dispatch is physical work. Each has its own admission and ledger record. A managed Agent invocation can contain several such calls. The wrapper does not bill their total a second time.
The same physical cost can count against Organization, Team and key limits without creating multiple provider charges. This is why request counts, trace counts and billable attempts need not match.
Guardrails, approvals and upstream accounts¶
Model guardrails inspect supported inputs and outputs. Tool rules can block an invocation or require administrator approval. Consumer consent for an Action tool and authentication to an upstream Connector are separate from an administrator's policy decision.
Output guardrails can reject an answer after the provider has already done billable work. Approval permits a bounded dispatch under current authority; it does not grant permanent access. For uncertain execution, inspect the recorded outcome before repeating an operation that may have changed an external system.
Continue with budgets, model guardrails, tool rules, approvals, or error recovery.