API keys are not an authorisation model for an agent that can move money

The arithmetic is left implicit in the post, so here it is. The example capability lets finance-agent send payments up to a ceiling of 100, valid until 30 August 2026 ^[5]. That agent can hand a sub-agent the same payments.send capability narrowed to 50 ^[9], which caps a compromised sub-agent at half the parent's per-payment authority ^[14]. Set that against the two failure cases the post opens on: a leaked finance key that drains the account, and a compromised code-review agent pushing malicious commits [c2b]. In both, the loss is bounded by the resource rather than by the token. Attenuation is the property that changes that number, and it is the one an API key has no syntax for ^[3].

The second thing worth reading closely is where the risk moves rather than disappears. The SDK's issue call takes a private_key argument, and the post says nothing about where that key lives or how it is rotated ^[6]. Every capability the system will ever honour is minted with it. The operating systems work the author draws on, where permissions are unforgeable tokens that can be delegated and attenuated ^[12], treats custody of the root as somebody else's chapter. In deployment it becomes an environment variable on whichever box does issuance, and at that point the signing key carries the blast radius the API key used to have. Better, because minting is now a recorded act, but not smaller.

Third, the expiry in the example is an absolute timestamp, not a lifetime ^[5]. A capability issued in a hurry and forgotten is good until that date. Time-bound by default only holds if callers pass short dates, and the sample code invites the opposite habit.

The implementation deserves cautious reading. The author reports 1,438 passing tests including adversarial regression coverage, plus architecture docs and a threat model ^[1], and describes himself as a recent CS graduate who was building coursework COVID detection models six months earlier ^[11]. A test count is evidence of care, not of correctness. The failure mode that would hurt here is not a signature bug but a revocation store that answers stale while a tool call is in flight, and nothing visible from outside the repo speaks to that.

None of this argues against the primitive. If an agent can move money or write to a repository, the object it presents should name the agent, the action, the ceiling and the deadline, and it should be killable on its own with a record of what it did. That is a short specification, and it is implementable against a gateway you already run if you would rather not take a pre-1.0 dependency at your authorisation boundary. The thing not to keep doing is handing an autonomous process the same static key you gave your CI job and calling the result access control ^[3].