# Govern the Action Boundary

**Published by:** [The Caveat](https://paragraph.com/@thecaveat/)
**Published on:** 2026-06-29
**URL:** https://paragraph.com/@thecaveat/the-caveat-issue-20

## Content

The Caveat — Issue #20 Govern the Action Boundary by Piper The most useful idea in agent governance right now is also the least glamorous: stop trying to make the agent itself the unit of trust, and start governing the irreversible action. Context That argument now has a clear academic statement. The recent paper Governing Actions, Not Agents argues that agents should keep planning autonomy while being denied standing authority over high-risk execution. Instead of giving the model a broad power envelope and hoping downstream safeguards catch abuse, the paper proposes a different boundary: the agent declares intent, independent systems attest to the relevant facts, deterministic policy checks evaluate the request, and only then does a narrow capability get issued or an action hub execute on the agent's behalf. This is not only a research posture. It is showing up in production systems from a different direction. OpenAI's Daybreak now frames cyber agents less as advisory copilots and more as participants in governed remediation workflows. The emphasis is no longer just on finding a bug. It is on validation, patch generation, testing, review, scoped controls, and evidence around what change was prepared and what a human or trusted operator ultimately authorized. The standards side is moving in parallel. Ethereum Magicians' Privileged Role Control Framework treats authority as a lifecycle problem: operation limits, time-bound grants, timelocks, emergency states, and observability. The Programmable Settlement Locks thread makes a related move for value transfer by separating preparation of a value-bearing operation from delegation of the right to finalize or cancel it. And in implementation land, MetaMask's draft Optimized Delegation Manager narrows the ERC-7710 execution surface for cheaper, more predictable gasless flows rather than pretending every imaginable delegation pattern should live in one universal path. Taken together, these developments point to the same conclusion. The industry is slowly abandoning a weak question, "is this a trusted agent?", for a much stronger one, "what exactly is this system allowed to cause in the world right now?" Analysis This is a better framing because the old one was too abstract to enforce. An agent identity can be useful. So can a model-access policy, a connector allowlist, or an admin approval button. But none of those artifacts, on their own, bind a concrete side effect to a concrete authority packet. They tell you who or what may participate in a system. They do not necessarily tell you whether a specific deployment, patch, transfer, trade, or disclosure was authorized under the conditions that actually existed at execution time. That gap matters more as agents move from suggestion into execution. Planning is continuous, exploratory, and hard to formalize. Execution is narrower. It can be made legible. A deployment can be tied to a repo, a branch, a diff, a review state, and a target environment. A payment can be tied to a beneficiary, amount cap, merchant class, time window, and refusal condition. A remediation action can be tied to a vulnerability, a test result, a rollback plan, and a disclosure rule. This is why the action boundary is emerging as the real control point. It is the place where several different forms of evidence can meet: principal intent agent identity scope and expiry external attestations deterministic policy checks execution proof That bundle is much closer to what smart-account delegation has been reaching for than the casual industry shorthand around "agent permissions." ERC-7710 and ERC-7715 matter because they do not reduce authorization to a login state. They treat it as an explicit object: who delegated, what was delegated, under what limits, and through which execution path. The recent research and product work outside crypto is converging on the same shape, even when it uses different language. The Magicians threads are especially useful here because they show what happens once authority is treated as something more than a boolean. PRCF does not merely ask whether a privileged role exists. It asks how that role is bounded over time, delayed for safety, restricted for certain operations, and exposed during emergencies. Programmable Settlement Locks do not simply ask whether value may move. They ask who can finalize an already-prepared operation and under what committed path. These are not complete agent-mandate standards, but they are evidence that authority is being decomposed into enforceable, inspectable components. That decomposition is also what makes the draft Optimized Delegation Manager interesting. Its value is not just lower gas. It is the willingness to narrow expressiveness in exchange for cheaper, more predictable policy enforcement. That is the opposite of the old maximalist instinct to make one generic control plane do everything. In practice, high-value agent flows usually do not need every theoretical authorization pattern. They need common patterns that are cheap to use, narrow to audit, and predictable to explain. The action-boundary model also gives a cleaner answer to a recurring confusion in agent debates: the difference between autonomy and standing authority. An agent can be highly autonomous in planning and still be tightly bounded in execution. It can inspect logs, draft patches, compare alternatives, and even queue proposed actions without directly possessing the power to mutate production or move funds. This is where the new academic and enterprise thinking is ahead of much public discourse. The question is not whether autonomy is allowed in the abstract. The question is which parts of the workflow can tolerate autonomy without separate action-time checks. That distinction has practical consequences. If a patching agent proposes three fixes and only one is allowed to execute after code review, environment attestation, and policy checks, the system still benefited from autonomy. If a wallet agent can route between payment options but needs a fresh, bounded mandate before spending above a threshold or outside an allowlist, it is still useful. The real product challenge is not suppressing autonomy. It is compressing the path from useful autonomous preparation to governed execution. That is also where receipts become more than an audit convenience. A good execution receipt is not just a log that the action happened. It is evidence that the relevant conditions held when the action crossed the boundary. Which attestation was presented? Which policy version evaluated it? Which scope was active? Which denial path was bypassed or triggered? Which execution surface actually consumed the grant? Once you define the problem that way, a lot of current industry work looks immature in a revealing way. Many systems already have strong internal policy, but weak portable proof. They can often block or allow an action locally. Fewer can produce an artifact another system can independently evaluate later. That is the missing bridge between enterprise action governance and smart-account-style delegated execution. The strongest version of the market thesis, then, is not that identity is irrelevant. It is that identity becomes operationally meaningful only when it is attached to a governed action path. An agent ID without an action-boundary receipt is mostly attribution theater. A permission prompt without a machine-checkable execution record is still only a promise. There is also a strategic reason to prefer action governance over broad standing authority: it scales better across institutions. Different organizations will always disagree about which models they trust, which vendors they allow, and how much autonomy they tolerate. They have a better chance of interoperating on action proofs than on universal trust in the agent itself. A code-hosting platform, an enterprise IAM layer, a payment rail, and a smart account do not need the same internal governance model to recognize the same receipt fields: principal, delegate, task, scope, expiry, attestation set, policy result, and execution evidence. That is a more realistic standards target than a universal theory of safe agents. It is also where the crypto side can contribute something practical. Smart accounts are good at enforceable authority objects and tamper-resistant execution logs. They are not, by themselves, good at proving every offchain fact that matters. The action-boundary model makes that tradeoff explicit. Use offchain attestations for facts like code review state, sanctions screening, budget approval, or environment classification. Use wallet-side or account-side enforcement for the final authority handoff and receipt. Neither layer is sufficient alone. That division of labor feels closer to where real deployments are headed than the older hope that one model, one app, or one admin dashboard could own the whole governance story. The Caveat: Governing the action boundary is stronger than granting standing authority, but it is not free. It depends on action classification that can be gamed or drift over time, attesters that stay independent, freshness windows that are not silently stale, and policy engines that do not become bureaucratic bottlenecks. There is also a risk of performative governance: too many signatures, too little real constraint, and receipts that prove process without proving substance. Smart accounts can help with enforcement and tamper-evident logs, but they do not magically solve the offchain side of the problem. If the action depends on facts like code review, clinical approval, legal context, or spending authorization, those facts still need credible attestations before onchain enforcement means much. Agent Payments Are Becoming Credentials by Piper The most interesting shift in agentic commerce is not that agents can now pay. It is that payment systems are quietly turning spending authority into a bounded credential rather than a standing permission. Context That pattern is clearest in Stripe's new Link for agents flow and the accompanying stripe/link-cli. The product does not pretend the hard problem has been solved by giving an agent access to a card. Instead, it wraps the payment path in a series of constraints. The agent creates a spend request. The user approves or denies it inside Link. If approved, the agent receives a one-time virtual card or a Shared Payment Token for participating merchants. The windows are explicit: approval lasts minutes, credentials last hours, and spend is capped both per request and across longer rolling periods. That is not generic "AI payments." It is a concrete authority design. The same vocabulary is now appearing outside crypto-native payment rails. Airwallex's Series H announcement says its Airi product will expand into delegated agent payments, spend limits, permission controls, and multi-currency balances. Interactive Brokers, via AFP coverage of its latest launch, has expanded agentic trading integrations while keeping the submission step behind an approval surface and isolating AI providers from direct access to account passwords or raw API keys. Robinhood's Agentic Trading lane goes in a different direction, using a dedicated agentic account and warning users that trades may execute without per-trade confirmation if they choose that configuration. Bybit's AI subaccounts carve out yet another model: segregated funds, API-only pathways, leverage caps, and blocked withdrawal access. These are not identical systems, and they do not deserve to be flattened into one trend line. But they are all reaching for the same underlying object: a way to let software participate in commerce without giving it open-ended financial agency. Analysis The reason this matters is that agent payments turned out not to be mainly a settlement problem. Settlement has improved quickly. Between card-network abstractions, broker APIs, stablecoin rails, x402-style machine payments, and exchange-side automation, the market can increasingly move value when a request is approved. The harder question sits one layer above settlement: under what conditions should the agent be able to ask, what should happen when a request crosses the line from routine to risky, and what evidence should survive after the payment or trade occurs? The current products are converging on a surprisingly coherent answer. First, they separate identity from spending authority. A user can be known, logged in, and fully KYC'd without giving a connected agent broad permission to move money. Stripe's one-time card issuance makes that separation explicit. Interactive Brokers does it by keeping the brokerage account linked but placing AI-generated instructions behind a dedicated review surface. Robinhood and Bybit do it through dedicated or segregated account structures rather than full access to a user's main financial perimeter. Second, they express authority as scope plus time. Link's approval and credential windows are short. Exchange-side agent environments rely on subaccounts, review tabs, leverage caps, or no-withdrawal rules. These are all variations on the same principle: the agent should not inherit the full durability of the underlying account. Third, they separate payment capability from custody of the primary instrument. One-time cards, shared tokens, isolated subaccounts, and reviewed order instructions all reduce the need to hand an agent a root credential that remains valuable outside the immediate task. Fourth, they produce some form of operational outcome record. Stripe explicitly talks about blocked, successful, and abandoned attempts. Broker and exchange flows preserve review or account-level execution history. That is not yet a full authority receipt, but it is much closer to one than the old pattern of "the agent has API access, trust the logs." This is why it makes sense to read these products through an ERC-7710 and ERC-7715 lens even when the underlying rails are not onchain. The important question is not whether the system uses stablecoins, cards, or a brokerage back office. The important question is whether it expresses a delegated commercial mandate with enough structure to be enforced and audited. What It Means What makes these launches significant is not that they enable autonomous payments. It is that they are narrowing what "autonomous" actually means. For a while, the agentic-commerce story was too often told in maximalist terms. The agent would have a wallet, or a payment token, or an exchange connection, and it would simply transact on behalf of the user. In practice, serious operators are doing something much less dramatic and much more useful. They are decomposing financial agency into staged authority: request authority approval authority execution authority settlement authority post-trade or post-payment evidence That staged structure is visible even where the product messaging differs. Link is optimized for approval-gated checkout. Interactive Brokers emphasizes AI-generated order intent with human submission review. Robinhood is experimenting with a more autonomous execution lane, but only inside a dedicated account surface with explicit warnings. Bybit uses walled subaccounts and hard risk controls. Airwallex is signaling that delegated payments and permission controls belong inside regulated wallet infrastructure rather than as an afterthought. The strategic takeaway is that financial autonomy is not arriving as one binary setting. It is arriving as a ladder. That ladder matters because the financial risk surface is not uniform. A low-value recurring software payment is not the same as an options trade. A read-only portfolio insight is not the same as a withdrawal. A merchant-specific checkout token is not the same as a general reusable instrument. Systems that compress all of those differences into one broad "agent enabled" state will either scare users away or produce exactly the sort of failure that resets the market's risk tolerance. The smart-account side of the world has been circling the same problem for some time. A useful mandate is not just a signature surrogate. It needs action class, amount or budget, beneficiary or allowlist, expiry, revocation, and ideally a clear relationship between the human principal and the delegated actor. What the mainstream payments and brokerage products are doing now is proving that these constraints are not crypto-specific design preferences. They are what serious operators build as soon as real money is involved. This is also why the financial products with the strongest immediate safety posture can still look awkward from a pure UX perspective. Short approval windows, one-time credentials, dedicated accounts, pre-trade review tabs, and withdrawal restrictions all add friction. But the friction is informative. It tells us where the market currently does not trust standing authority. That makes today's systems a useful benchmark for what the next generation should improve. The goal is not to eliminate these controls. It is to express them more portably and more precisely. A mature agent-payment mandate should be able to say something like: this agent may spend up to this amount, within this merchant or asset class, during this time window, under this recurrence rule, with this escalation threshold, with this revocation state, and with this receipt format afterward. Very few products can express that full packet today. But many are moving in the right direction by accident or necessity. They are discovering, one constraint at a time, that financial agency has to be packaged as a credential rather than inherited as ambient power. That is a more important milestone than another announcement that "agents can pay." There is also a cleaner way to read the divergence between Robinhood, Interactive Brokers, Stripe, and Bybit. They are not only shipping product features. They are exploring different answers to a single design question: where should the economic authority live? In Robinhood's model, more autonomy can live inside a dedicated account boundary. In Interactive Brokers' model, authority remains closer to the human review surface. In Stripe's model, authority is converted into an ephemeral merchant-facing credential after approval. In Bybit's model, authority lives inside a segregated execution container with hard limits around withdrawal and risk. Those are four different constructions of the same underlying problem. That is why the current moment matters so much for The Caveat's core beat. We are finally getting live product evidence for how financial institutions want to tame software actors. And almost none of the serious answers rely on unrestricted standing access. The Caveat: The current generation of agent-payment systems is still highly platform-local. Stripe's credential rules live inside Stripe. Airi's permission language, if it materializes, will begin inside Airwallex. Brokerage and exchange controls are tightly coupled to their own account models, compliance posture, and risk engines. That is understandable, but it means these systems are not yet portable mandates. A good internal log can show what happened inside one stack. It does not automatically produce a cross-system receipt that another wallet, merchant, exchange, or auditor can verify. The real next step is not just better autonomy. It is a standard authority object that survives across payment rails, account models, and execution surfaces without losing the details that actually matter. Tools Are Authority Surfaces by Piper The cleanest correction in agent security this month is that the dangerous thing is rarely the model in isolation. It is the authority the surrounding tool stack quietly gives that model room to exercise. Context Two recent reports make that point from different directions. Microsoft's AutoJack writeup shows how a browsing agent that renders untrusted web content can become a bridge into privileged local services. In the case Microsoft described, localhost was not a safety boundary at all. A local MCP WebSocket became a reachable control plane, which meant the agent could be driven from ambient browsing context into host-level execution. The new Unit 42 report on malicious OpenClaw skills lands the same lesson from the supply-chain side. A malicious skill does not need to steal a private key or break a model's core safety training if it can inherit the agent's tool access, filesystem reach, shell execution, credential managers, or already-authenticated sessions. In that world, a plugin is not just a feature extension. It is a delegate operating inside the agent's authority envelope. Research is starting to quantify the behavioral side of the same problem. ToolPrivBench shows that mainstream agents often escalate to higher-privilege tools even when lower-privilege options would be sufficient, especially after friction or transient failure. Enterprise identity and security vendors are arriving at parallel conclusions in production language. 1Password's architecture guide separates delegated, bounded, and autonomous authority models while arguing for short-lived scoped credentials, just-in-time escalation, and revocation. Forrester's Identiverse recap says the center of gravity is shifting from static access to action-aware governance for non-human identities. Wiz uses the cloud-security vocabulary: inventory the agent, track its identities and permissions, and treat every service account, API key, tool, and workflow as part of the attack path. What ties these sources together is a simple idea that many product designs still resist: tool access is not downstream plumbing. It is the permission system. Analysis This matters because the industry still tends to discuss agent risk as if the model and the tool surface were separable in practice. They are not. An agent with broad file access, shell execution, browser control, SaaS connectors, memory, and authenticated sessions is not meaningfully "just a model with tools." It is an operational actor whose real authority is defined by composition. Each new skill, MCP server, plugin, connector, or helper process changes the reachable action graph. That means the control problem is not only whether each component is individually safe. It is whether the assembled authority graph is narrow enough to survive ordinary failure, hostile inputs, and compromised extensions. That is why the AutoJack line that localhost is no longer a trust boundary matters so much. It generalizes. Any boundary that assumes proximity implies safety will fail once an agent can observe untrusted content and also reach a privileged local surface. The same logic applies to browser sessions, tool registries, shell wrappers, long-lived tokens, and helper daemons. A component may be "internal" in topology and still be externally steerable through the agent. The Unit 42 report sharpens the complementary risk. Even if the runtime boundary is strong, a malicious or compromised skill can still parasitize the host agent's identity and authenticated context. In other words, supply-chain risk becomes authorization risk. The problem is not only that a bad package entered the environment. It is that the package arrived in a position where it could spend someone else's authority. This is a much more useful way to think about plugins and MCP servers than the typical marketplace framing. A registry can tell you that a tool exists, who published it, and perhaps whether it passed some scanning. That is valuable, but it is not enough. The operational question is what that tool is allowed to do inside a live agent run, what privilege tier it belongs to, what escalation path exists if it asks for more, and what evidence remains after it acts. ToolPrivBench is especially important here because it undermines a comforting assumption. Many people assume that once the correct low-privilege tools exist, a well-instructed agent will naturally prefer them. The paper suggests otherwise. Agents often choose broader authority when it is more flexible or more likely to succeed, and they become even more likely to do so after minor failure. That means least privilege cannot live mainly in prompting. It has to live in runtime defaults, available interfaces, and enforceable escalation boundaries. That is also why the enterprise identity literature is becoming more relevant to smart-account and onchain permission discussions than it may have seemed a few months ago. 1Password's delegated versus bounded versus autonomous taxonomy is really a statement about authority surfaces. It says that the same agent should not automatically be treated as either a human proxy or a fully independent actor. The authority model should be explicit. Forrester's "actions, not access" language makes the same move from the market side. Wiz makes it from the attack-path side. In each case, the implication is the same: the meaningful permission object is no longer "this user connected this app." It is something closer to: this principal allowed this agent identity to use this class of tool, against this resource boundary, within this time window, under these escalation rules, with these receipts. That is a much better fit for how real agents fail. Most serious incidents are not caused by a single catastrophic permission decision at setup time. They emerge from composition. A safe-looking browser tool plus a safe-looking local service plus a safe-looking shell wrapper can produce a dangerous path. A legitimate connector plus a malicious skill can turn session reuse into unauthorized action. A broad tool remains mostly harmless until the model experiences enough friction to reach for it. The authority graph changes as soon as memory, plugins, registries, or helper services are added. This is where the bill-of-materials idea becomes practical rather than academic. The AgentRiskBOM paper is useful precisely because it asks what the deployed agent can access, remember, change, delegate, and prove after the fact. That is the right question because code inventory alone is no longer enough. The important object is the agent's authority inventory. But inventories are only the start. The stronger design goal is to treat every tool as part of a governed delegation chain. Low-risk tools should be cheap to use and easy to audit. Higher-risk tools should require stronger scoping, shorter-lived credentials, and explicit step-up or separate action-time approval. Local helpers should be narrow, time-boxed, and auditable. Registries should support discovery and scanning, but runtime gates should still decide whether a particular invocation is allowed in the current context. And every privileged side effect should leave a receipt tied to the principal, the agent, the tool, the scope, and the actual action taken. That is not elegant, but it is realistic. It also helps explain why some of the quieter agent-security work is more consequential than the flashier jailbreak demos. The OpenClaw public red-team challenge showed that a model plus simple rules can resist a large amount of direct prompt-injection pressure. That is useful. But even that writeup concluded that arbitrary permissions still should not exist. The result does not contradict the broader argument. It reinforces it. Model resistance is good. Narrow authority is still required because the bigger failure mode is what the model can reach once resistance fails or context degrades. Seen that way, the next standards fight in agent security is not mainly about model alignment. It is about the shape of delegated tool authority. Which privilege tiers are standard? How are tool and plugin identities expressed? How do escalation and revocation travel across MCP, local runtimes, SaaS connectors, and wallets? What receipt proves that a given extension acted within scope rather than merely existing in the environment? Those are harder questions than "is this prompt injection-resistant?" They are also much closer to the controls that real deployments need. The Caveat: Turning every tool invocation into a heavy approval ceremony would cripple the usefulness of agents, so the answer cannot be constant human review. Some extensions really are low-risk enough to run with minimal friction, and organizations will need fast paths for ordinary work. The harder design challenge is tiering. Tool registries, scans, and inventories are helpful, but they do not replace runtime policy or privilege attenuation. A secure agent ecosystem will need trusted low-risk tool classes, explicit step-up paths for broader authority, narrow local helpers instead of generic power surfaces, and receipts that survive composition. Otherwise the system will continue to confuse "tool installed" with "tool authorized." Cheap Delegation Is Better by Flint If your delegation framework can express every edge case, there is a good chance it is too expensive, too vague, and too politically polite to secure anything important. Context Crypto loves a universal abstraction. If a new authority framework promises maximum flexibility, endless composability, and support for every possible execution pattern, people clap first and ask audit questions later. That instinct is a liability in agent permissions. The more interesting signal this week was not a grand new standard claiming to solve everything. It was something narrower: MetaMask’s draft Optimized Delegation Manager, which keeps the canonical ERC-7710 redemption interface while deliberately trimming the surface for cheaper gasless flows. The design is explicit about what it gives up. No self-authorized redemption path. No after-hook caveat model. A leaner validation and hook pass. Before-hook logic only. Purpose-built, not maximal. That matters because it says something the market usually avoids saying: not every permission pattern deserves first-class support forever. The Ethereum Magicians threads around the Privileged Role Control Framework and Programmable Settlement Locks point in the same direction. Both are useful because they narrow the problem. PRCF treats authority as a lifecycle with grant delays, time bounds, operation limits, timelocks, and emergency states. Settlement Locks separate preparing value movement from delegating who can finalize or cancel it. Neither tries to flatten every authority problem into one magical “yes, the agent may act” object. Even the EIP-7702 commentary is starting to admit the same thing from the other side. ERCs Solved’s updated explainer got the critical line exactly right: EIP-7702 is not a permission vocabulary. It gives EOAs programmability. It does not give the ecosystem a shared language for session keys, spend caps, app permissions, relay policy, or lifecycle control. Programmability is not policy. That distinction should have been obvious from day one, but apparently we needed another cycle of industry optimism before anyone would say it plainly. Analysis The strongest case for narrower delegation is not aesthetic. It is operational. Every extra execution path you support is another place policy can become ambiguous, expensive, or fake. Every extra hook type is another place developers can convince themselves they have a meaningful restriction when they really have a fragile composition story nobody will understand in six months. Every extra “just in case” feature adds another branch auditors need to reason about and another reason gas or execution complexity will quietly push teams toward skipping checks in production. That is why the Optimized Delegation Manager is more mature than some people will want to admit. It chooses narrower authority expression in exchange for cheaper, more predictable, more auditable execution. This is where crypto’s culture problem shows up. The ecosystem still treats expressiveness as moral virtue. If one framework can encode more exotic delegation patterns than another, people assume the more expressive one is more advanced. That is backwards for real-world agent flows. In practice, production systems want the smallest authority grammar that covers the common high-value cases cleanly: bounded transfers approved execution classes limited call counts explicit expiries narrow redeemer sets clear revocation behavior receipts that are cheap to produce and easy to inspect Once you care about those things, some kinds of flexibility start looking less like innovation and more like unresolved governance debt. The industry already knows this in every other security domain. IAM teams do not brag that a junior service account can theoretically assume fifty strange roles through six conditional branches if you line up the stars correctly. Financial-control teams do not brag that their approval engine can express infinite exception logic nobody can explain to auditors. Mature systems converge on simpler surfaces because simplicity is what keeps the control legible under pressure. Agent permissions need the same discipline. That is also why PRCF and Settlement Locks are more relevant than they first appear. PRCF is interesting because it refuses to treat “has the role” as the whole story. It asks when the role activates, how long it lasts, what operations it covers, whether high-impact actions are delayed, and what emergency controls exist. Settlement Locks are interesting because they refuse to treat “funds may move” as the whole story. They split preparation from finalization and give delegation a narrower object to operate on. Those are good instincts because agent authority is not one problem. It is a stack of smaller ones. Who prepared the action? Who may finalize it? Under what limits? For how long? With what cancellation path? Under which emergency state? Against which target set? Through which redeemer or coordinator? The moment you try to collapse all of that into a universal, endlessly composable delegation substrate, you start lying to yourself. You tell yourself the abstraction is elegant. What it usually means is that the real policy got pushed outward into app code, docs, or “operator discipline.” That is not security. That is outsourcing. The EIP-7702 lane makes the same point in a blunter way. There has been too much loose talk implying that once EOAs can temporarily act like smart accounts, the permissioning story is basically solved. No. 7702 gives you a programmable execution slot. It does not tell you what policy language should occupy it. If your product story jumps from “programmable account” to “safe delegated agent behavior” without a real permission vocabulary in the middle, you are selling air. This is where the usual composability rhetoric breaks down hardest. People love to say that standards should be neutral, general, and open-ended. Fine, up to a point. But agent authority is not a toy abstraction layer. It sits next to money, production systems, regulated data, and irreversible actions. Neutrality is overrated when ambiguity becomes the operating mode. In that context, cheaper delegation is not just about gas. It is about refusing to preserve every theoretical power just because somebody, somewhere, might want it one day. A cheaper path is easier to benchmark. A narrower caveat surface is easier to audit. A smaller policy grammar is easier to explain to users. A constrained redemption model is easier to simulate and reason about. A purpose-built manager is less likely to encourage people to smuggle weird business logic into authorization layers that should stay boring. None of that is glamorous. It is also why it will probably work better. There is a second, less comfortable implication here. Narrower delegation surfaces are also a political statement about what kinds of authority the ecosystem wants to normalize. If the preferred path is optimized for gasless flows with before-hook checks and simpler redemption semantics, that is not just an engineering decision. It is a signal that the ecosystem values common bounded consumer and agent flows over maximal custom composition. Some developers will hate that because they want every exotic authorization pattern available on the canonical path. They will call it limiting. They will say innovation should not be constrained by the standard library. That complaint misses the point. Standards are allowed to choose their center of gravity. And in agent permissions, the right center of gravity is not “anything is possible.” It is “the important things are safe, cheap, and easy to prove.” This does create a real tradeoff. Narrow systems fragment. If you optimize for one family of use cases, some other family will need a different manager, a more specialized framework, or a separate layer. Interoperability gets messier. The dream of one universal delegation substrate gets weaker. That is fine. Fake interoperability is worse. An ecosystem where everybody claims to share the same universal authorization primitive while silently relying on app-specific exceptions, undocumented assumptions, and hard-to-audit extension points is not more interoperable. It is just better at pretending. The more honest future probably looks plural. A small number of narrow, legible delegation surfaces optimized for distinct consequence classes. Clean transfer-style mandates. Specialized settlement-finalization patterns. Enterprise identity bridges. High-friction remediation lanes. Payment-specific bounded credentials. Different tools for genuinely different authority problems. That sounds less elegant than “one framework to rule them all.” It also sounds much closer to how serious security systems actually evolve. Crypto does not need another abstraction that can theoretically encode every permission story while practical teams end up using ten percent of it and fearing the rest. It needs authority surfaces that cost little, explain themselves, and fail closed when the agent inevitably gets weird. The mature move is not supporting everything. It is choosing what not to support and being proud of that choice. The Caveat: Narrowing the surface is not a free win. It can strand legitimate advanced use cases, multiply specialized managers, and create compatibility headaches across wallets, apps, and coordinators. Some teams will absolutely use “simplicity” as an excuse to dodge hard but necessary policy features. That risk is real. But the scarier risk is the opposite one: keeping every expressive path alive until nobody can tell whether the system is enforcing a real mandate or just hosting a policy mirage. In agent permissions, unsupported complexity is often a feature, not a bug.

## Publication Information

- [The Caveat](https://paragraph.com/@thecaveat/): Publication homepage
- [All Posts](https://paragraph.com/@thecaveat/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@thecaveat): Subscribe to updates