Home / The model / The capabilities / write.budget.tenant
write.budget.tenant
Spend money or tokens against an account it holds. Its effect is no: cannot be undone.
What this id is made of
This is not a string. It is write.budget.tenant, three nodes joined by three edges, and each of them has an address, a page and a JSON file. Follow any of them and you get the query for that word rather than a definition of it.
| Node | Edge | Reads as |
|---|---|---|
write | has_verb | this capability has the verb write |
budget | acts_on | this capability acts on budget |
tenant | reaches | this capability reaches tenant |
money | in_family | this capability is in the money family |
no | has_undo_class | this capability has the undo class no |
The gloss above is a convenience, not the definition. A node carries no inherent meaning: what
write.budget.tenant is emerges from the edges traceable from it. The strongest case is tenant, where the deployment shapes that use it do not agree about what it means, and the page keeps the disagreement rather than averaging it.In 2 of 17 published shapes
| Deployment shape | Barrier there | Known by | Whose material | Note | |
|---|---|---|---|---|---|
| ● | A scheduled job running as a service account | none (not a control) | derived | not stated | if the credential is billed |
| ● | A self-hosted n8n instance, reached with an owner-scoped API key (contributed by riskmandate.ai) | none (not a control) | measured | organisation | a real model credential was added by the deployer through the UI and a real execution returned a model response through the node - spend against that account, as the workflow's author. The first attempt failed with "does not have access to the credential": a wrong reference from ambiguous name matching between two credentials of the same type, not a barrier, found only once the MCP interface could list them. |
| Barrier | What stands in the way | Is it a control | |
|---|---|---|---|
| ● | none | nothing in the way | no |
| ◉ | expectation | a rule in prose, enforced by nobody | no |
| ◐ | setting | a switch the agent's own account can flip | no |
| ○ | boundary | enforced above the grant, out of the agent's reach | yes |
What the starting mandates say about it
| The mandate says | Which mandates |
|---|---|
| authorised | A sandbox: build and run one AI-agent workflow |
| refused | Chat in the browser, nothing connected, A scheduled job under a service account |
| unstated | A coding assistant on my machine, A coding assistant in a container on the web, The desktop app, with local tools switched on, Chat, with connectors switched on, A CI job on a hosted runner, A browser extension I installed, A reader on my mailbox, Find things in the inbox, draft replies, never send, A reader on my drive, Search our tenant, read-only, Find and read my files, An assistant over my Workspace, reading, What the agent inferred it was authorised to do, from one session |
Unstated is not authorised. A mandate that never mentioned a capability did not authorise it, and the delta on every example page counts it as excess and says which kind it was.
What would move it to the fourth barrier
| What | What it costs | The barrier afterwards |
|---|---|---|
| a spend cap at the supplier, set by somebody other than the agent - the supplier has a reason to refuse: it is paying | the work stops when the cap is reached, which is the point | boundary |
This is a published reduction, not a recommendation. Whether it is worth doing depends on the assets and the consequences, which are not in this document and are not this site's to guess. Since v0.4.3 it is also a node,
setting/write.budget.tenant, in the deployment shape universe: it narrows this capability and moves it to the barrier named in the third column, which is the path the prohibitions table's last column is a projection of.