Don't "Define" Agents. Give Them a Credit Limit.
Authors
TLDR
- Stop defining "agent" — the shape keeps changing, the consequences don't. Govern the consequences.
- An agent isn't an agent until it has memory (durable state) and a budget (bounded allowance to act).
- Borrow underwriting from banking: scoped limits, escalating proof for higher authority, re-evaluate on material change.
- Govern at choke points: tool gateways, data egress, memory writes, infra changes, economic actions.
- Scale friction to risk: weather check gets a rubber stamp, money movement gets holds and receipts.
- If it can act, it can be underwritten. If it can't be bounded and revoked, it's not ready.
There's no "agent" there there — apologies to Gertrude Stein — until you give it memory, credentials, and a budget.
- Memory (in agentic systems) isn't a single place. It's any durable state the system can use later: conversation summaries, retrieved docs, vector stores, task queues, tool logs, user profiles, cached results — anything that lets it carry intent and context forward and compound effects over time.
- Budget isn't always money. It's any bounded allowance to cause consequences: dollars, number of actions, volume of data touched/exported, compute/time, concurrency/spawn limits, or even a risk threshold. A budget is what makes an actor operationally powerful — and therefore governable.
Once you give a system durable memory and a bounded allowance to act, it starts behaving less like a program and more like an actor. And that's why the deceptively simple question — "what is an agent?" — keeps dissolving into edge cases: scripts that schedule themselves, workflows that fork, swarms that spawn, assistants that "go away" and resume later, tool routers that fan out across SaaS, and systems that act on behalf of humans.
The shape shifts. The consequences don't.
So instead of chasing the perfect definition of "agent," I think we should borrow a model that has spent centuries dealing with fuzzy actors, shifting risk, and expensive mistakes: Underwriting. Not as a gimmick. As a control philosophy.
Why "what is an agent?" keeps failing
If you've been following the agentic space, you've probably seen several competing definitions (all partially right):
- Agent as an executable process: something running somewhere that can take actions.
- Agent as a workflow unit: a durable, multi-step job with state and branching.
- Agent as an embodiment: a device/robot that senses and acts in the physical world.
- Agent as a stack: LLM + memory + tools + orchestration + feedback loop.
- Agent as delegated authority: software acting "for" someone (or something) within a scope.
It's worth acknowledging these because they're not wrong — they each capture a slice of reality.
But here's the problem: every one of those definitions breaks when the implementation changes. And the field is moving fast enough that implementations will keep changing.
- A "process" today becomes serverless tomorrow.
- A "workflow" becomes an emergent swarm next week.
- The "LLM+tools" stack changes shape with every new tool protocol.
- Delegation chains become multi-hop, multi-party, and long-lived.
- The same "agent" disappears and later resumes in a new environment.
So if you build your governance around one crisp ontology, you'll keep getting surprised. The "agent" will route around your definition.
A better move is to shift the question: Not "what is an agent?" but "where do consequences happen, and how do we bound them?"
That pivot is the entire game.
Consequences have addresses (even if agents don't)
"Agents" may be distributed and fuzzy. But the points where they can cause harm are usually very concrete:
- Token minting / delegation — what authority gets granted?
- Tool gateways — where do tool calls pass through?
- Data ingress/egress — what can be read/exported?
- Durable memory writes — what gets stored, learned, retained?
- Infrastructure changes — who can change prod?
- Communications — who can message humans or systems at scale?
- Economic actions — who can spend, commit, refund, or obligate?
These are boundary conditions. Choke points. Places where intent becomes consequence.
And this is where underwriting becomes a powerful metaphor — because underwriting is built to handle exactly what agentic systems introduce: fuzzy actors, shifting context, escalating privileges, and expensive mistakes.
Underwriting: the right mental model for agentic security
Banks don't try to philosophically define "trustworthy personhood." They do something more operational:
- You get an account before you get a loan.
- You get a small credit line before you get a big one.
- Your ATM withdrawal limit is not your net worth.
- Big purchases can get holds and manual review.
- A sudden spending change triggers fraud checks.
- Material changes prompt re-evaluation.
That maps astonishingly well to agentic systems. So here's the thesis:
Treat agentic access like a credit system: issue scoped limits at the choke points, observe behavior, and adjust authority continuously — especially when something materially changes.
This is "Zero Trust" translated into a language people instinctively understand: risk, limits, escalation, and liability.
The Agent Underwriting Model
1) Start with an account, not carte blanche
Before an agent can do meaningful work, it needs a home for accountability — an "account record" you can point to.
That usually begins with an owner/sponsor (human or org) because someone ultimately carries responsibility. But here's the key: underwriting doesn't require a human to click "approve" every time. In the real world, banks don't ask a manager to approve every coffee purchase. They approve the account, set limits, and let most activity run autonomously.
Agent systems are heading the same way:
- Agents will discover opportunities, initiate actions, and sometimes transact on their own behalf
- Payment rails like stablecoins or protocols such as X.402-style agent commerce concepts push exactly in that direction
- HITL will exist, but it won't scale as "press OK for every tool call"
Underwriting accommodates autonomy by shifting control from per-action permissioning to account-level constraints:
- Define who/what is accountable (even if the agent initiates)
- Define what "normal" looks like
- Set budgets and rails
- Require step-up only at higher risk tiers
The "account record" should include:
- An accountable principal (org-owned, user-owned, or product-owned)
- A risk tier and permitted action classes
- Policy attachments (purpose, allowed domains, data classification)
- Logging and audit sinks
- A lifecycle (creation, rotation, suspension, deletion)
- A place to store (or forbid) durable memory
In bank terms: you don't get a credit line without a customer record — even if the customer uses it autonomously.
2) Issue limits like a bank does: small, specific, timeboxed
Instead of "Agent can access Salesforce," think in limits:
- ATM limit: how much impact per time window (e.g., records/min, emails/hour)
- Per-transaction cap: max refund, max config change per action, max "write" operations
- Merchant restrictions: which endpoints, tenants, objects, or tools are allowed
- Environment restrictions: which regions/runtimes are acceptable
- Timeboxing: short-lived grants that must be reissued
This is what least privilege looks like when you stop thinking in static roles and start thinking in operational risk.
3) Underwriting inputs: build a real "agent credit file"
Banks evaluate income, history, ratios, existing relationships, and references. Your agent credit file might include:
- Sponsor strength ("income"): who delegated this and at what seniority/approval level? (Even for "self-initiating" agents, this becomes: what product/org boundary is liable for it?)
- Existing relationship ("account size"): has this identity behaved well over time?
- Risk ratio ("DTI"): requested scope vs observed stability and controls
- Behavioral history ("payment record"): incident history, anomaly rate, policy violations
- Verified references ("proof"): attestation, code signing, SBOM pointers, known toolchain
- Delegation provenance: acting-for chain, what it derived from, what it can pass downstream
The key word is verified. "References" that aren't anchored in something checkable become a reputation game.
4) Step-up: higher limits require stronger proof
If the system wants more authority, it has to qualify — just like a borrower. Examples of step-up requirements:
- Stronger attestation claims
- Cleaner behavioral history
- Narrower purpose binding
- Stricter monitoring
- Approvals for certain action classes
- Dual control for irreversible operations
This creates a path from "toy agent" to "trusted automation" without blind faith.
5) Holds and pending states for irreversible actions
Some actions are not "single swipe." Money movement is the obvious one, but so is:
- Exporting sensitive datasets
- Changing network/security posture
- Provisioning privileged accounts
- Deleting resources
Finance uses holds, pending states, and dispute mechanics because irreversible actions create liability. Agent systems should borrow that structure:
- Two-phase commit for high-risk actions
- Review queues
- Rollback windows where possible
- Auditable receipts: what was requested, under what authority, what was approved
This is where "agent security" becomes "governance," in the best sense.
6) Material change → re-underwrite (the most important rule)
Banks re-check when something changes: unusual spending patterns, address changes, fraud signals. Agent systems need the same instinct.
Material change triggers might include:
- Agent version/hash changed
- Toolset changed (new tool, new MCP server, new permissions)
- Environment changed (new runtime, new region)
- Delegation chain changed (new sponsor, new derived authority)
- Behavior anomalies (bursting, unusual targets, unusual data access)
- Memory profile changed (new persistent store, wider retrieval scope)
When material change happens, the safe default is: shrink limits, re-verify, re-issue grants.
Because "agent comes back later" isn't a corner case. It's normal.
Risk-proportionate friction: weather vs money
This is the part that makes the model usable instead of bureaucratic.
- "Give me the weather" → tiny blast radius; basic rate limiting is fine.
- "Read 20 CRM records" → data risk; enforce scopes, DLP, audit.
- "Change a WAF rule" → operational blast radius; require step-up, change windows, rollback.
- "Issue refunds / move money" → liability risk; caps, holds, receipts, dispute hooks.
Underwriting gives you a principled way to decide how much friction is appropriate.
Swarms: you're underwriting a portfolio, not a single borrower
Swarms are the "1000 cards opened in your name" problem. Even if each worker has low authority, the aggregate can be dangerous.
So you need portfolio controls:
- Parent budget that all spawned agents draw from
- Monotone narrowing (children only get subsets)
- Spawn/concurrency caps
- Circuit breakers at the parent grant
- Lineage/audit graphs that connect outcomes to delegation chains
This is where governance stops being about "the agent" and becomes about the authority graph plus budgets.
The payoff: you don't need the perfect definition of agent
Definitions will keep breaking as architectures evolve. Underwriting survives because it's anchored to invariants:
- Actions have consequences
- Consequences have boundary points
- Authority must be bounded
- Risk changes over time
- Memory makes effects compound
- Evidence and revocation matter
So here's the bottom line:
If it can act, it can be underwritten. And if it can't be bounded, observed, revoked, and accounted for, it's not ready for high-stakes autonomy.
In the agentic era, the goal isn't to win the ontology debate. It's to build systems where the worst-case outcome is still acceptable.
Underwriting is one of the most battle-tested ways humans have ever done that.