---
title: "The Contractor Gets Their Own Card"
date: "2026-06-05T11:00:00-07:00"
lastmod: "2026-06-05T11:00:00-07:00"
description: "Lending your corporate card to a contractor is the convenient failure everyone recognizes on sight. The right answer is a narrower instrument with the contractor's own name on it, one that dies with the project. AI agents spawn helpers by the dozen, and the same rule is the difference between delegation and contagion."
summary: "Crunch week. The contractor needs materials, and the project manager hands over her own card, just this once. Everything about it is convenient and everything about it is wrong, and every finance team knows exactly why. This post walks delegation the way a mature card program runs it: the contractor\u0026rsquo;s own card with a lower limit, attribution that survives the handoff, cards that die when the project closes, and caps on how many cards a project may issue, not just how big each one is. Then the three places the analogy breaks for AI agents, where the fixes have to be built."
slug: "the-contractor-gets-their-own-card"
tags:
  - "Agentic Identity"
  - "Delegated Authority"
  - "IAM"
  - "Authorization"
  - "Security Architecture"
series:
  - "what-the-corporate-card-already-solved"
---


Crunch week on the renovation project. The contractor needs to buy
materials this afternoon, the purchasing process takes two days, and
the project manager does the obvious thing. She hands him her card.
Just this once.

Everything about it is convenient. No forms, no waiting, the work
keeps moving. And everything about it is wrong, in ways every finance
team can recite from memory. The statement will say *she* bought
whatever he buys. Her limit, tuned to her role, is now backing his
judgment. If the card number leaks from his pocket, her card dies and
her month gets complicated. And when the project ends, nothing about
that card changes, because the card never knew it was working for the
project at all.

The failure is not that the contractor is untrustworthy. He may be
excellent. The failure is that the *authority arrangement* is wrong:
borrowed instead of granted, broad instead of narrowed, attributed to
the wrong person, and immortal with respect to the work it was
supposed to serve.

> Delegation narrows, or it contaminates.

AI agents hit this exact fork dozens of times a day, because agents
spawn helpers. A research sub-agent, an extraction worker, a reviewer,
each needing some slice of authority to do its piece. And the
convenient thing is always the same thing the project manager did:
hand the helper the credentials already in hand. This post is about
why the spend world refuses that convenience, and how.

# Borrowing Is the Default Because Borrowing Is Free

Be honest about why the card got lent. The right path had friction and
the wrong path had none. The parent's credential is already there,
already works, and requires nobody's involvement. That asymmetry, not
malice, is why borrowed authority is the default failure mode of every
delegation system ever built.

A mature card program does not win by lecturing project managers. It
wins by making the right thing nearly as cheap as the wrong thing.
Issuing a contractor card takes minutes, not days. The moment the
sanctioned path costs two days while the unsanctioned path costs
nothing, the program has designed its own bypass.

The agent version is sharper, because for agents the borrowed path is
not just convenient. It is invisible. A sub-agent spawned inside the
parent's process inherits the parent's credentials by simple physics,
by being in the same memory with the same connections. Nobody decides
to lend anything. The lending is the default state of the runtime, and
an explicit grant has to be built to exist at all.

# What the Right Version Looks Like

The contractor gets his own card, and five properties come with it.
Each one fixes a specific thing the borrowed card broke.

**His own name.** The statement now says who actually spent. When a
charge looks wrong, the question "who did this" has an answer that
does not require interviewing the project manager about her wallet.
Attribution is not bureaucracy. It is the difference between an audit
and an interrogation.

**A lower limit, on the same project code.** His card draws against
the same approved project budget, but bounded to his slice: materials,
say $2,000, this month. The delegation *narrowed*. In a well-run
program it always narrows. The contractor's card should not be able to
do more than the project it serves, because his authority is carved
from the project's, not conjured beside it.

**Issued, never copied.** His card came from the program, through a
request the program saw. He could not manufacture it from the project
manager's card number, and she could not create it by handing over
plastic. Every delegation is visible to the issuer at the moment it
happens, which is precisely the property the borrowed card destroyed.

**It dies with the project.** When the project closes, every card on
that project code stops working at once, hers, his, all of them.
Nobody collects plastic from wallets. Nothing depends on the
contractor remembering to stop. The cards were always projections of
the project, so ending the project ends them, transitively, wherever
they are.

**The program caps the count.** Here is the subtle one. Twenty
contractors with $500 cards is a different risk than one contractor
with a $10,000 card, even though the arithmetic looks similar. Breadth
is its own exposure: more instruments in the field, more places to
leak, more judgment operating in parallel. So the program does not
just bound each card. It bounds *how many* cards a project may have
open, and whether a contractor may sponsor cards for his own
subcontractors at all. Depth limits do not control breadth. Breadth
gets its own limit.

Swap in the agent and the mapping is one-to-one. The sub-agent gets
its own explicit grant, narrower than the parent's, issued through a
path the system can see, attributed to the sub-agent itself, dead the
moment the parent's task ends, with the fan-out counted and capped.
Spawning a helper is a runtime event. Authorizing one is a governance
event. The whole discipline is refusing to let the first stand in for
the second.

# Where the Analogy Breaks

Three breaks, and each is a build item the card world never needed.

**Cards have one holder. Agents have a thousand copies.** A contractor
card names a human, and there is exactly one of him. An agent is
software. The "contractor" may be forty concurrent instances of the
same worker, spun up and torn down in minutes, all legitimately acting
under the same delegation. The expense world never had to ask *which
copy* of the contractor was at the register, and its instruments carry
no answer. Agent delegation needs identity for instances, not just for
roles, or every one of those forty workers is indistinguishable in the
record and in the containment.

**Every card comes from the issuer.** There is no field-expedient way
to mint a narrower card from your own card, and for plastic that is
fine, because delegation happens at human speed. Agent swarms delegate
at machine speed, hundreds of narrow grants per minute, and a round
trip to the issuer for each one becomes the bottleneck that tempts
everyone back to credential-sharing. The agent world genuinely needs
what the card world rarely has to expose: a way to derive narrower
authority in the field that still cannot exceed the parent and still
dies with it. That is new machinery with sharp edges, and it only
works if the narrowing is provable and the kill switch still reaches
it.

**The contractor's limit is a number. The agent's is a shape.** A
card's delegation collapses to amount, category, and dates, because
money is one-dimensional. An agent helper's slice is which actions on
which systems with which parameters, a shape, not a scalar. "Narrower"
is easy to verify for $2,000 against $10,000. It has to be *defined*
before it can be verified for "may read the financials but not notify
anyone." The card world's subset rule comes free with arithmetic. The
agent world has to specify its subset rule, and everything downstream
depends on getting it right.

The build list from this room: identity for every copy of the helper,
field-speed delegation that provably narrows, and a subset rule for
authority that is a shape rather than a number.

# The Rule That Survives the Breaks

Strip the plastic away and one rule remains, and it is the whole
post. **A helper's authority is granted, narrower, named, and mortal,
or it is contagion.** The project manager's card in the contractor's
pocket is the same object as the parent agent's token in the
sub-agent's memory: authority that arrived by proximity instead of by
decision.

The spend world beat this by making the granted path cheap and the
borrowed path unnecessary. The agent world has to do the same thing at
machine speed, which is harder and less optional, because agents fork
faster than any project ever staffed up. The rule is usable today:
make the granted path cheaper than borrowing, or borrowing will be the
architecture.