Instructions Are Not Authorization

Why a sentence cannot bound spending

Take an instruction that sounds precise: spend up to fifty dollars on supplies.

Scope is undefined. Is a subscription that delivers supplies a supply purchase? Is a delivery fee? Is a tool used to make something? Every one of these is arguable, and the agent is the thing doing the arguing.

The period is undefined. Fifty dollars once, per day, per task, or per month. Absent a stated period, an agent running continuously can satisfy the instruction repeatedly and stay literally compliant while spending an unbounded amount.

Aggregation is undefined. Fifty per item or fifty in total. A limit that applies per transaction is not a limit at all when transactions are free to create.

A human employee resolves these silently using context, professional judgement, and an understanding of consequences. A model resolves them by producing the most plausible continuation, which is not the same operation and does not fail the same way.

The deeper problem is where the instruction lives. It is text in a context window, alongside other text, including content the agent retrieved from somewhere else. That means it can be diluted by volume, overridden by later instructions, or directly contradicted by input crafted to do so. A constraint that an attacker can address in the same channel as the constraint itself is not a control. It is a suggestion with good intentions.

So the rule worth internalising: anything the model can reason about, the model can reason around.

What enforceable authorization looks like

Move the limit somewhere the agent has no ability to reinterpret. Concretely that means the credential and the policy layer, both outside the model's reach.

A scoped key with an amount cap. The agent holds a session key that can sign payments up to a fixed total. Once exhausted, further attempts fail at the signing boundary rather than being declined by a system the model could try to talk past. The cap is arithmetic, not interpretation.

An expiry. A credential that stops working at a known time bounds the damage from a compromise you have not detected yet, which is the compromise that matters.

A counterparty allowlist. Where the agent may send value, evaluated before signing. Deny by default and allow by explicit rule.

Rate and period limits. Per hour and per day, which is what closes the repetition gap that an amount cap alone leaves open.

Custody the agent cannot exfiltrate. Keys held in the operating system keychain rather than in a file the agent can read or an environment variable it can print. If the agent can retrieve the key material, every other control is advisory, because a compromised agent simply signs directly.

This is the shape CryptoCadet implements: a bounded spending float delegated through session keys, non-custodial, with key material in the OS keychain, settling in USDC on Base. The design principle is that the model never holds an unbounded ability to move value, so a prompt injection reaches a wall made of arithmetic rather than a wall made of instructions.

The instruction still has a job. It tells the agent what it should do. It just cannot be what determines what the agent can do.

The legal question, which is genuinely unsettled

The technical controls above are well understood. The legal position is not, and anyone claiming otherwise is ahead of the law.

The core difficulty: an agent is not a legal person. It cannot hold rights, owe duties, or be a party to anything. So when it commits to a payment, the binding effect has to attach to a person or company, and the theories available were built for humans acting through other humans.

Several questions follow that do not have settled answers across jurisdictions.

Is the operator bound by a transaction they did not see? Ordinary agency reasoning suggests that giving something authority to act creates responsibility for its acts within that authority. Applying it to software raises the question of what the authority actually was, which returns to the ambiguity problem above.

What counts as authorization? If the operator set a fifty dollar cap and the agent spent forty on something unexpected, the amount was authorized and the purpose arguably was not. Which one governs is the question, and the answer likely depends on how clearly the constraint was expressed and recorded.

Who bears the loss on a compromised agent? Between the operator, the counterparty, and any intermediary, and the analogy to existing unauthorized transaction rules is imperfect because those rules assume a consumer and a reversible rail.

Does the counterparty have any duty to check? Accepting payment from an unattended process is a new position for a merchant, and current rules mostly do not contemplate it.

The practical response is not to wait. It is to build the evidentiary record you would want to rely on: what the credential permitted, when it was issued, what the agent was instructed to do, what it actually did, and what the counterparty was told. Bounded authority is also the strongest available argument, since a cap that was set and enforced is a fact rather than an assertion.

This is general information rather than legal advice, and the treatment varies by jurisdiction and by facts.