English source · 5 min

Delegate an agent, keep control of the shop

An agent receives its own revocable credential, a small set of read permissions and an explicit model allowance. It can inspect authorized information and prepare a proposal. A person still approves business changes through the native operation.

Implementation state: deployed and publicly exercised, 16 October 2026. Hosted receipt and boundaries record the actual stop, purchase and session journeys. Current public status remains the release authority. These controls do not make the whole app-concept programme complete.

Configure a planning agent

Select the Live shop, then open Developer → API & integrations with a personal account that can manage team access. Agent credentials are live operational controls; creating one from a sandbox is rejected before issuance. Choose Dedicated agent, give it a recognizable name and select only the data it needs. The scope is the intersection of the key's grants and its creator's current membership; removing a role or revoking the key takes effect on subsequent admission and saved-run continuation.

Specify all of the following; there are no unlimited defaults:

Copy the credential once and keep it outside prompts, source code and browser storage. Subsequent lists show identity, permissions and counters, never plaintext. A revoked agent key retains its accounting row. Replacing it creates a new identity with a new allowance; agents cannot issue credentials or increase their own limits.

Agent profiles accept read permissions, assistant.use and explicitly granted customers.pii. They cannot complete purchases, apply proposals, mutate apps, create keys or invoke arbitrary app callbacks. HTTP admission and MCP discovery/ invocation enforce this, rather than relying on model instructions.

Compatibility: ordinary API keys remain available for their explicit native integration operations. To start saved merchant-agent work or use central model planning with a nonpersonal integration credential, create a dedicated bounded agent key. A generic key is no longer an unmetered native AI credential.

What is counted

Before each text-model request, PostgreSQL locks the live shop and key, checks current admission, reserves the complete envelope, records an allocation event and commits. Live-root locks use FOR NO KEY UPDATE: they serialize agent controls and allocations while remaining compatible with commerce foreign-key reference readers. This avoids a tenant/task lock-order inversion at worker completion. Only then may the provider call start. Two Rust replicas cannot spend the same remaining allocation. No transaction stays open while waiting for the model. The authority scope constructs a boxed child synchronously, preserving a small polling boundary for large native HTTP/POS futures; it does not enlarge worker stacks.

The envelope includes serialized UTF-8 request bytes, the bounded output allowance and 4,096 units of framing headroom. Its cost is rounded upward from the approved integer tariff. Successful, failed and uncertain requests retain their allocation; continuation reusing a completed checkpoint does not allocate that call again.

These are conservative allocation counters, not actual provider token invoices or a guaranteed provider billing ceiling. They do not reconcile credits or refunds. Budgeted agents currently accept text-only model requests; paid query embeddings and reranking are skipped in favour of native lexical retrieval. Background AI jobs, independently operated app services and ordinary human interactive use are not all covered by this per-key envelope. Existing daily attempt and shared concurrency limits remain separate controls.

Exhaustion returns HTTP 429 with kind: quota_exceeded, retryable: false and pointer: /agentBudget; it has no misleading short Retry-After. An administrator must review a replacement delegation rather than repeatedly retrying an exhausted key. Studio explains the administrator's stop and persistent allowance exhaustion in all four interface languages. Its localized recovery guidance is visible directly in the error notice, rather than hidden under a technical-details disclosure.

Stop the shop's merchant agents

A personal user with ai.manage sees Agent control in the same API workspace. Stopping requires an explicit confirmation and current revision. The switch always targets the live shop and all its private sandboxes, even when opened from a sandbox. It cancels queued, running and uncertain native merchant tasks, fences late worker results and blocks agent-key access and subsequent scoped central model admission. An agent or ordinary integration key cannot lift it.

Already admitted or sent provider requests may finish and may be charged; the stop cannot recall network requests. Late results from cancelled durable runs cannot become executable proposals. Normal shopping remains available. Enabling the switch permits new work; cancelled tasks do not restart automatically.

This is not a kill switch for every background indexer or independently operated external service. The switch, credentials and allocation counters are operational: configuration history, sandbox cloning and selected publication cannot restore or increase them. Original financial approvals and domain invariants remain authoritative.

Shared contracts and verification

agent_authorities runs actual HTTP/PostgreSQL, two Rust replicas and a local synthetic model provider. It checks allocation races, independent token/cost exhaustion, exact model mismatch, restart, two agents sharing a human creator, foreign shops, revocation, sandbox stop, stop under a held commerce-reference lock and denied credential/commerce writes. The signed-runtime foundation also repeats it through separate restricted tenant and system logins. durable_agents stops a real worker during a provider call and rejects its late result. UI tests fence late credentials and status from a previous shop and require explicit limit/confirmation inputs. No real paid provider is used.

The small arithmetic allowance check reuses the existing extracted kernel guard. That proof does not certify surrounding SQL, authentication, asynchronous workers or external providers. Proof boundary.