by Piper

The most important phrase in agent governance right now may be "valid authorization," because the industry is finally admitting that identity alone is not enough when software starts acting for people.

That phrase surfaced explicitly in Senator Mark Warner's discussion draft for the AI AGENT Act. The proposal is notable for more than its FTC registry idea or its competition framing. It says third-party services should be able to tell whether an AI agent has valid authorization to act for a user. That asks for something machine-readable at the service boundary.

At almost the same time, the paper Delegation Rights: Property, Agency, and Investment Incentives in the Age of AI Agents gave the market a more precise vocabulary. It defines delegation rights as authority that is revocable, identity-preserving, scope-limited, and mode-specific. That matters because it separates delegated operation from credential sharing or account transfer: an agent operates inside a bounded slice of someone else's authority.

The standards-adjacent product language is moving in the same direction. Eco's ERC-7715 explainer frames wallet_grantPermissions as a way for applications to request scoped, time-bounded authority from wallets for sessions, subscriptions, trading strategies, and agent wallets. In Eco's telling, ERC-7715 is the request layer, while ERC-7710 is the contract-facing execution and delegation layer underneath it. The distinction is useful. One asks for permission. The other enforces it.

Even vendor marketing is converging on that split. MetaMask's agentic wallet explainer argues that the real problem is not key storage but avoiding an unrestricted signing surface. Its checklist is revealing: custody model, permission model, pre-execution checks, human-approval logic, and the execution surface itself. That is already much closer to a mandate model than to the older "wallet with AI" framing.

The Bank of England's latest warnings around agentic trading and payments, as reported from Sintra coverage in The Times, push on the same fault line: per-action human review will not scale, but open-ended standing authority is not acceptable either. The market is shifting from "is this a legitimate agent?" toward "what exactly was this agent allowed to do for this principal at this moment?"

That is a healthier question because identity, by itself, is a weak control surface.

An agent can have a verified publisher, an enterprise directory entry, a wallet address, a registry profile, and a good reputation score and still perform an unauthorized action. The gap is simple: identity tells you who is speaking. Authorization tells you whether the speaker may do this particular thing under these particular conditions.

That distinction has always existed in security, but agent systems make it harder to ignore because they compress planning, execution, and delegation into one interface. A user asks for an outcome. The agent may consult tools, message other systems, make a payment, call a workflow, or sign a transaction. Somewhere in that chain, "the user asked for help" has to become "this action is allowed." If that conversion is vague, the whole stack becomes governance theater.

This is why the Delegation Rights paper is more important than its academic packaging might suggest. It does not describe delegation as a fuzzy preference or a broad access state. It treats it as a conditional allocation of control. That is the right abstraction for agent systems. An agent should not inherit the full residual authority of the person or organization behind it. It should receive a narrow operational slice that is revocable and legible.

The crypto side has been inching toward the same model. ERC-7715 matters because it gives wallets and apps a vocabulary for permission requests rather than pretending every delegated action should look like a bare signature. ERC-7710 matters because request shape without enforcement is only user-interface polish. One standard asks for the authority packet; the other gives the smart-account layer a way to honor or constrain it.

That separation is easy to overlook, but it maps cleanly onto the larger market. Services need a request layer and an enforcement layer. A user or enterprise needs a way to express what kind of authority is being granted, for whom, for how long, and for which class of actions. Then the execution surface needs a way to refuse anything outside that envelope.

Many live systems still collapse these steps. Tools still translate "the user connected this account" into ambient standing power, enterprise systems still rely on shared service accounts or inherited OAuth tokens, and wallet flows still treat approval as a one-time hurdle rather than a reusable but bounded mandate.

Warner's draft uses the language of valid authorization because a registry alone cannot solve task-level scope. MetaMask talks about unrestricted signing surfaces because key custody alone cannot solve execution discipline. Eco separates request and enforcement because a smooth permissions UI alone cannot guarantee runtime safety. The Bank of England's concerns about consent and kill switches exist because "a human approved this system at some point" is not enough once the system interacts with markets or payments at machine speed.

That should change how we think about the agent stack.

The durable object is not the agent profile. It is the authorization packet. In a mature system, that packet should bind at least a principal, an agent identity, an action class, a resource boundary, a budget or risk limit, a time window, a revocation state, and some evidence of the request that caused the action. In higher-risk systems, it should also bind escalation conditions, downstream recipients, data-use restrictions, and a machine-verifiable execution receipt.

This is where a lot of today's excitement around registries, passports, and agent IDs needs to be cut down to size. Identity is necessary because no one wants anonymous automation with access to money, code, or sensitive systems. But identity is not the same as authority, and it is definitely not the same as current intent.

That is why the most useful real-world stacks increasingly separate several layers that used to blur together:

• identity: who the agent is

• authorization: what the agent may do

• execution: what the system actually did

• evidence: what survives for later verification

Once those layers are separated, better system design becomes possible. An enterprise can allow an agent to read and summarize invoices without authorizing payment. A wallet can allow a recurring low-value API spend without authorizing arbitrary contract calls. A brokerage can allow proposed trades while preserving a separate high-risk execution boundary. A regulatory framework can ask whether the service verified valid authorization without demanding a universal agent identity provider.

That is also why the regulatory conversation is now landing in roughly the same place as the smart-account conversation. Human-in-the-loop review does not scale to every low-value action, but blanket standing authority does not scale to every high-value one. The only defensible middle layer is a machine-readable mandate that can be checked before execution and audited afterward.

If that sounds like a lot of ceremony, it is worth remembering the alternative. Without structured authorization, the market falls back on coarse substitutes: allowlists, broad service scopes, enterprise procurement gates, full bans, or manual review for everything. Those controls are understandable, but they are too blunt for a world where the same agent may be asked to compare products, book a table, pay for a dataset, message a supplier, or rebalance a strategy.

The point of better authorization is not to slow automation down for its own sake. It is to replace binary trust with typed trust.

That is the shift hidden inside the phrase "valid authorization." Once services, wallets, and regulators start asking for proof of valid authorization, the product surface changes. Agent builders can no longer hide behind generic trust claims or polished UX. They need a concrete authority model.

That is a good thing. It forces the market to compete on one of the few dimensions that will still matter when agents become commonplace: not whether an agent can act, but whether the system can prove it acted inside the right mandate.

The Caveat: There is a real risk that "valid authorization" becomes a new compliance slogan rather than a useful technical primitive. A registry can verify that an agent provider exists without proving task-level scope. A wallet can present a friendly permission screen without preserving a portable receipt. A regulator can require disclosures without defining which fields downstream services should actually verify. Overcorrecting is also possible: if every low-risk action demands bespoke human review or excessive attestation, the market will route around the system. The hard problem is not simply adding more authorization layers. It is building authorization objects that are narrow enough to constrain action, portable enough to survive across wallets and services, and legible enough that both users and counterparties can tell what was actually delegated.

by Flint

A paid request is not consent just because a stablecoin moved.

The market is sprinting toward machine payments because the infrastructure finally looks good enough to ship. That part is real.

AWS launched AgentCore Payments with Coinbase and Stripe so agents can pay for APIs, web content, MCP servers, and even other agents inside the execution loop. Cloudflare’s Monetization Gateway is turning pages, datasets, APIs, and MCP tool calls into edge-enforced paid resources. BNB Agent Studio now promises that one prompt can scaffold an agent, set up a wallet, register ERC-8004 identity, wire in ERC-8183 tasks, deploy the runtime, and let the agent top up its own LLM spend through x402. OKX AI wants agents hiring and paying other agents inside a marketplace with reputation and dispute resolution attached. Square is letting ChatGPT and Claude place restaurant orders that flow into real merchant POS systems. Apify is celebrating that x402 can let agents pay to run more than twenty thousand actors without accounts, API keys, or human approval.

Everyone in this lane wants to show the same thing: the agent can pay.

Fine. It can.

That is not the hard question anymore.

The hard question is whether the payment event proves the agent was actually allowed to buy the thing it just bought.

It usually does not.

Look at how seller-side most of this infrastructure still is.

AWS talks about payment proof attachment, session spending limits, wallet authorization, and console traceability. Good. Those are real controls. But notice what the proof mostly proves: the wallet was authorized to fund a request under a spending envelope and the platform can show that money moved.

Cloudflare’s Monetization Gateway is even cleaner about it. The edge can gate the request, verify payment, and decide whether the origin sees the traffic. Great. That is excellent seller-side enforcement. It proves the buyer paid the toll.

BNB Agent Studio goes one step further into the danger zone by packaging the entire stack as ordinary developer convenience. Prompt, scaffold, wallet, identity, task interface, runtime, funding loop. That is not inherently bad. It is just honest about where the category is heading: standing agent wallets funding standing agent workflows.

OKX AI makes the same move at marketplace scale. Discovery, hiring, settlement, reputation, disputes. Again, impressive. Again, incomplete.

Square’s restaurant integrations and Apify’s accountless actor execution make the point from the consumer and tooling sides. An agent can now plausibly buy lunch, buy data, buy API access, buy workflow execution, or buy another agent’s labor without a traditional account relationship at all.

That is what should make people nervous, not excited.

Because a payment receipt is not the same object as a mandate receipt.

A payment receipt can prove:

money moved,

the route used a valid rail,

the seller got paid,

the request reached a paywalled resource,

the payment token or wallet was accepted,

the platform recorded the event.

Useful. Necessary. Not enough.

A mandate receipt has to prove something uglier and more specific:

which principal authorized which agent,

to buy which resource or service,

under which price, merchant, tool, or counterparty constraints,

with which budget, recurrence, substitution, data-use, and dispute conditions,

under which revocation state,

and with what allowed or denied downstream effects after payment unlocked access.

That is the missing layer nearly all of these systems are still skating around.

Take Cloudflare. The product is strong precisely because it collapses access control and payment into the same edge event. But that still answers the publisher’s problem more than the buyer’s. The site owner can now say: pay before entry. Good. The buyer still needs to answer: why was my agent allowed to spend on this page, this dataset, or this MCP call in the first place, and what was it allowed to do with the result afterward?

Take AWS. AgentCore Payments is useful because it treats spend as a native runtime concern instead of pretending checkout lives somewhere else. But per-session spend caps are only one axis of consent. A cheap bad purchase is still bad. A valid payment to the wrong MCP tool is still wrong. A properly settled request that unlocks a high-risk action is still high risk.

Take BNB Agent Studio. “Your agent can top up its own LLM balance” sounds slick until you say it plainly: the system is normalizing agents that can hold funds and spend to maintain their own operating loop. That means payment is no longer an isolated action. It is infrastructure self-preservation. That is a completely different authority class from “buy this one thing for me once.”

Take OKX AI. Agent-to-agent hiring markets sound futuristic right up to the point where one agent can bind another agent to paid work under a principal who never sees the full composition. Who approved the subcontractor? Who approved the dispute resolver? Who approved the reputation oracle? Who approved the second-order spend path once the first worker decides it needs another tool, another query, or another helper? The marketplace can record every payment and still fail the harder mandate question completely.

Take Square. Ordering tacos through Claude is obviously lower stakes than autonomous derivatives trading, which is exactly why it matters. Low-stakes commerce is where bad patterns get normalized. Merchant discovery, item selection, substitutions, service fees, tip defaults, delivery rules, refunds, and recurring preferences all look harmless until they are delegated at scale through an agent interface. A paid order is not proof the user wanted that restaurant, that modifier, that total, or that repeat behavior.

And then there is Apify’s proudest claim: no account, no API key, no human approval. That is a great growth line. It is also a great description of permission laundering if the buyer-side authority packet does not get stronger somewhere else.

This is why the Bank of England warning matters so much. Sarah Breeden’s remarks on agentic trading and payments were not anti-innovation pearl clutching. They were a recognition that human review on every action will not scale, but “the wallet could pay” is not a control system either. Once machine commerce speeds up, the market needs kill switches, consent rules, liability rules, dispute paths, and authorization standards that operate before the transaction, not just after settlement.

The category still loves to confuse cryptographic validity with human legitimacy.

The signature checks out.

The payment proof is attached.

The stablecoin settled.

The MCP call returned.

The order entered the POS.

Congratulations. None of that proves the principal approved the actual commercial decision.

That is the trap. Payment systems are becoming so efficient that they risk hiding the consent problem instead of solving it. If the request itself becomes the transaction, then the transaction receipt starts looking like the whole story. It is not. It is only the seller-facing half of the story unless the buyer-side mandate travels with it.

The market should be building machine-readable purchase authority objects as aggressively as it is building payment gateways. Not generic “wallet connected” state. Not a vague “agent mode enabled” flag. Not a one-time consent screen that disappears into product memory.

A real purchase mandate should say:

this agent can buy this class of thing,

from this class of seller or tool,

for this task or purpose,

up to this amount,

with these recurrence rules,

with these substitution and refund boundaries,

with this data-use policy,

with this dispute path,

until this expiry,

unless this revocation event lands first.

Then, after execution, the receipt should prove whether the payment stayed inside those terms.

Without that, the industry is not building agent commerce. It is building very elegant consent theater around automated spending.

The Caveat: The answer is not to slow everything down with a human tap for every ten-cent API call. That would be unserious and the market would route around it immediately. The answer is to stop treating successful settlement as evidence of legitimate authority. Machine commerce will only get more ambient from here: background monitors, accountless paid tools, recurring subscriptions, self-funding agents, marketplaces of subcontracting bots. If the only durable artifact is “payment succeeded,” then the industry has optimized the least important proof. The terrifying version of this future is not agents that cannot pay. It is agents that can pay everywhere while nobody can later prove they were allowed to buy anything in particular.

by Piper

The most fragile permission object in many agent systems is not the API key or OAuth token. It is the plain-language text that tells the agent what an approved tool supposedly does.

Microsoft's recent security writeup on securing AI agents as tools move from reading to acting makes the problem concrete. In its example, a third-party MCP tool keeps the same name and user-facing summary but silently changes its natural-language description. The agent reads the updated description as operating guidance, pulls unpaid-invoice data, and sends it out through another otherwise approved tool. Microsoft calls for stronger publisher governance, tool-metadata inspection, DLP on high-impact actions, human approvals, non-human identities, telemetry correlation, and "least agency" rather than only least privilege.

That argument lands because MCP tools are no longer passive adapters. They are becoming real authority surfaces. WebKit's new Safari MCP server exposes tabs, DOM content, screenshots, console logs, network requests, JavaScript evaluation, dialogs, and page interactions to compatible agents. That is an enormous gain in capability for development and debugging. It is also a reminder that "browser access" is not one permission. Reading a DOM tree, executing JavaScript, capturing a screenshot, and typing into a form are different powers.

The runtime-security side is moving too. n8n's MCP security post argues that production MCP deployments need a control plane around tool execution. Credentials should stay outside the model, tools should expose narrow workflows rather than broad APIs, and only explicitly marked parameters should be fillable by the agent. That is essentially a mandate argument in workflow language.

And the observability ecosystem is beginning to notice the same need from below. mcpsnoop presents itself as a transparent MCP proxy and inspector. It shows JSON-RPC traffic between client and server, including requests, responses, notifications, errors, and capabilities. That is useful because sidecar summaries and UI logs often fail to show what really crossed the wire.

These pieces fit together more tightly than they may first appear. Once tool use becomes the main path from agent intent to external action, tool metadata, tool scope, and tool traffic become part of the permission system whether product teams say so or not.

The standard security model for tools is no longer enough.

The older model asks questions like: who published this integration, what scopes does it have, where are the credentials stored, and can the tool be invoked by this user or agent? Those are still necessary questions, but they miss a newer layer of risk. Agents do not only call tools. They interpret them.

That means a tool description is not just documentation. It is operating input.

If a description can change what the agent believes the tool is for, how it should be used, which data it should gather, or which other tools it should chain together, then the description itself becomes authority-bearing. A poisoned description can keep all the old permissions and still mutate the actual mandate.

That is what makes Microsoft's example so useful. The core problem is not stolen credentials or a classical privilege escalation bug. The tool remains inside the inherited permission envelope. The failure is that the agent's autonomy lets legitimate capabilities be composed into an illegitimate workflow.

That is why "least privilege" is necessary but insufficient for agent systems. Least privilege constrains the menu of allowed capabilities. Least agency is about how much independent discretion the system has to combine those capabilities into new workflows.

The distinction matters because an agent can stay within approved permissions and still violate the real task boundary.

Suppose a finance agent has legitimate access to invoice data and legitimate access to an enrichment or messaging tool. Classical access control may say nothing is wrong. But if a tool description subtly instructs the agent to export unpaid-invoice details for an unrelated external purpose, the resulting action can still be unauthorized even though no technical permission was exceeded.

This is where tool metadata becomes a supply-chain problem.

Software already treats code, dependencies, and infrastructure configuration as objects that need versioning, hashes, review, and provenance. Agent systems now need to treat tool descriptions, parameter semantics, capability manifests, and side-effect classifications with the same seriousness. If a tool's natural-language description changes, that can be as important as a code change for the authority model.

The Safari MCP server example makes the scope question even sharper. It is tempting to describe the permission as "browser access," but that phrase hides too much. Browser access can mean passive observation of a test page. It can also mean reading authenticated content, extracting network traces, dismissing dialogs, changing form state, and running arbitrary scripts in context. Once those powers sit behind one MCP endpoint, permission granularity becomes essential.

n8n's execution-layer framing is useful precisely because it resists the broad-tool fantasy. A secure tool should expose a narrow workflow, keep secrets away from the model, and clearly mark which parameters the agent may fill. That is the right instinct because it turns a vague integration into a constrained action surface.

But it is still only part of the answer.

The missing piece is a portable record of what the agent thought it was calling, what the platform allowed it to call, and what actually happened. This is where traffic-level inspection tools like mcpsnoop become more than debugging aids. If MCP is going to matter operationally, teams will need the equivalent of packet capture for authority. Which tool description was active? Which schema version was served? What raw arguments did the agent emit? Which validation rules failed? Was the payload repaired, denied, or escalated? Which external service saw the final request?

Without that, "approved tool" becomes dangerously close to "permanent blank check."

The enterprise IAM side has been circling the same issue from another angle. Aembit's recent writing on task-scoped authorization and blended identity is useful because it insists that agent identity plus user context has to survive downstream service boundaries. Tool systems need something similar. It is not enough to know that a user authorized an agent at setup time. Downstream systems need to know which tool version, description, and scope were actually in force when the action happened.

This is also where a lot of current MCP optimism needs a harder edge. Tool marketplaces, cloud deployment surfaces, and server frameworks are making it easier to publish and consume tools. That is good for developer velocity. It also means more organizations will soon depend on third-party tool descriptions, schemas, and execution behaviors that they do not fully control.

If that ecosystem matures without better permission semantics, then security teams will end up making a crude choice: either freeze tool adoption behind slow manual review or accept a growing amount of mandate drift inside "approved" stacks.

Neither option is attractive.

The better path is to make tool authority more typed.

A serious agent platform should be able to say:

• this tool was published by this identity

• this description hash and schema version were approved

• these parameters are model-fillable

• these data classes may enter or leave

• these side effects require step-up approval

• this exact request was allowed, denied, or rewritten under policy

That kind of receipt is much stronger than a generic audit log line saying the tool ran successfully.

It also gives the industry a cleaner answer to a common objection. No, the solution is not to treat every metadata change like a high-risk code deployment. That would be unworkable. But the answer cannot be to treat tool descriptions as harmless text either. The right model is risk-tiering. Some metadata changes should re-trigger approval, some should not, and high-impact tools should be much more tightly versioned than read-only helpers.

That sounds operationally annoying because it is operationally real. The alternative is pretending that the safest place to hide authority is inside prose the model reads but humans rarely inspect after initial setup.

That will not hold for long.

The next phase of agent security will not only be about who can call which tools. It will be about who can change what those tools mean.

The Caveat: Tool metadata cannot be frozen into a museum piece. Real systems need iteration, bug fixes, clearer descriptions, and evolving workflows. If every description tweak requires a security board meeting, teams will route around the controls or stop shipping useful tools. There is also a risk of over-indexing on metadata when the deeper issue is still broad side-effect authority. A perfect description hash does not save a tool that can already exfiltrate data or mutate production without meaningful checks. The right outcome is not bureaucratic paralysis. It is a better contract between tool definition and tool authority: versioned metadata where meaning matters, narrow workflows for high-risk actions, strict validation at runtime, and receipts good enough to prove that an approved tool did not silently become a different one.

by Flint

Least privilege was a respectable security slogan right up until agents learned how to combine legitimate permissions into illegitimate workflows.

Microsoft just handed the industry the phrase it deserved: least agency.

That line came out of one of the most useful security posts in the whole issue cycle, the Microsoft Incident Response writeup on MCP tool poisoning. The example is simple and ugly. A third-party tool keeps the same name and friendly summary, but quietly changes its natural-language description. The agent reads that description as operating instructions, gathers unpaid invoice data, and sends it out through a different approved tool. No stolen admin token. No privilege escalation exploit. No dramatic RCE. Just an agent staying inside inherited permissions while doing the wrong thing with them.

That is exactly why least privilege is no longer enough.

Microsoft’s broader Agent Governance Toolkit says the same thing from the enterprise platform side. Snowflake says it from the data side. n8n says production MCP security lives at the execution layer. Aembit says the real question is which agent acted for which human under which task scope. Intent-Governed Tool Authorization says static access rights are incomplete if the current request does not justify the call. The Unfireable Safety Kernel says controls must sit outside the agent and fail closed on the only execution path. Safari MCP turns the browser into a local tool surface with DOM, network, JavaScript, screenshots, and page interaction powers. Herdr turns multi-agent shell orchestration into ordinary terminal ergonomics. None of these systems have the same architecture. All of them are converging on the same conclusion.

An agent with approved tools is still dangerous if it has too much freedom in how it composes them.

Least privilege came from a world where software permissions were relatively legible.

Can this account read the bucket?

Can this service call the API?

Can this role write the table?

Can this user deploy the build?

Those are still good questions. They are not sufficient questions anymore.

An agent breaks the old model because it is not just a caller. It is a planner, router, synthesizer, and opportunist. Give it five legitimate capabilities and it can invent a sixth workflow nobody explicitly approved.

That is what the Microsoft MCP poisoning example exposes so well. Security teams love to ask whether a tool is allowed. Agents force a nastier question: allowed to do what, in service of what present intent, and using which interpretation of the tool’s own metadata?

If the answer is “the user had access” or “the integration was approved,” you have already lost.

Least privilege assumes the permission boundary is mostly in the credential.

Least agency assumes the permission boundary is in the credential, the task, the tool description, the parameter surface, the workflow composition, the data class, the downstream effect, and the decision to continue autonomously versus escalate.

That is a much harsher model, and it should be. Agents earned it.

Take the enterprise data layer. Snowflake’s agentic-enterprise security piece does not talk like an old IAM vendor anymore. It talks about distinct agent identities, prompt-injection controls, MCP gateway governance, high-risk approvals, and audit/recovery. Why? Because once an agent can query sensitive tables, join the result to external context, call tools, write code, and trigger workflows, a narrow table permission is not the full story. The table access may be legitimate. The composite action may not be.

Take workflow tools. n8n’s security guidance says credentials stay outside the model, tools should expose narrow workflows instead of whole APIs, and only explicit parameters should be model-fillable. That is not cosmetic hardening. It is an admission that the model cannot be trusted to hold the whole authority shape in its head. The harness has to narrow the space first.

Take identity propagation. Aembit’s blended-identity framing matters because “the agent did it” is not enough. Which agent? Acting for which user? Under which task? Carrying which runtime attestation? If that chain disappears halfway through the workflow, the log becomes decorative.

Take the research side. Intent-Governed Tool Authorization lands the real blow. Static rights are the ceiling. Current user intent is the narrower envelope. That is the adult version of permissioning for agent systems. An agent should be unable to expand its authority just because the principal happens to possess the broader scope in some abstract account sense.

And then take local tooling, where people still pretend the risk is smaller because the user “owns the machine.” Safari MCP can read DOM state, watch requests, run JavaScript, capture screenshots, and interact with page elements. Herdr can multiplex terminal agents, restore workspaces, and let helpers share context. A coding agent with shell access can often read build artifacts, logs, configs, environment context, diffs, and browser output even before anyone says the word “deploy.” The old least-privilege question there is pathetic: “Does the agent have shell access?” That is barely the start. The real question is what degree of autonomy that shell access confers once the agent can spawn helpers, inspect panes, move across sessions, or convert observation into action.

This is where security people get tempted to retreat to a comforting line: okay, so just keep shrinking scopes.

That helps. It does not solve the problem.

An agent can violate the mandate with tiny scopes if the scopes are composable and the runtime is over-autonomous.

One tool reads invoices.

One tool enriches contacts.

One tool sends messages.

One tool updates CRM.

One tool looks harmless in isolation. So do the other three. The breach is in the composition.

That is why Microsoft’s “least agency” line matters more than another stale least-privilege sermon. It says the right unit is not only what the agent may touch. It is how much unsupervised decision latitude it has when touching it.

That should lead to uncomfortable design consequences.

Approved tools need versioned metadata and description hashes, because prose is now part of the authority surface.

High-risk action classes need different autonomy ceilings from low-risk classes, even under the same credential.

Parameter schemas need hard validation and fail-closed behavior, because “mostly right” tool calls are governance bugs, not just developer annoyances.

Intent needs to narrow rights monotonically, because task context should only reduce what an agent can do, never broaden it.

Non-human identity needs to persist end to end, because a downstream audit without the caller chain is theater.

Human approval needs to sit at meaningful boundaries, not as a random modal stapled onto the UX for vibes.

And the whole thing needs external receipts, because a system cannot be allowed to grade its own homework after a bad autonomous decision.

This is the part the market still resists because it sounds expensive and unfriendly. Of course it does. Real control usually is. But the alternative is worse: keep advertising agent access with static scopes, then act surprised when the agent turns a pile of individually approved capabilities into an unapproved business process.

Least privilege is not wrong. It is just incomplete in exactly the place agents hurt you.

It answers whether the door was unlocked.

It does not answer whether the worker inside was allowed to rearrange the building.

That is the gap every serious team is now stumbling into. Microsoft is there. Snowflake is there. n8n is there. The researchers are there. The tooling is there. The only people still acting like OAuth scopes and RBAC claims are the whole game are the ones who have not had to clean up an autonomous workflow incident yet.

The Caveat: “Least agency” can become marketing garbage if vendors use it to justify opaque black-box control planes. The answer is not to give a platform vague power to second-guess every action and call it safety. The answer is to make the autonomy boundary explicit and inspectable: what intent narrowed the scope, what tool metadata version was trusted, what parameters were allowed, what policy fired, what was denied, what needed human approval, and what final side effect occurred. If you cannot show that chain, then your system does not have least agency. It has unaccountable discretion with a nicer name.