When a Machine Acts for You, Who Authorized It? By 0pcter

Artificial intelligence becomes a different kind of problem when it stops recommending an action and starts taking one. An AI system that summarizes an email can be wrong, but an agent allowed to send the reply, alter a database, deploy software, approve an order, or access another system can create consequences before a person reviews its reasoning. NIST now describes agentic systems in precisely these terms: software capable of autonomous decision-making and action with limited human supervision. The agency is investigating how organizations should identify these agents, authenticate them, limit what they can do, and determine what authority they possess when acting for someone else. That turns an abstract question about trusting AI into a concrete infrastructure problem. When a machine acts in your name, what proves that it had permission to take that particular action?

Computer systems have dealt with permissions for decades, so the problem is not entirely new. Employees have accounts and roles, applications receive credentials, APIs use access tokens, and automated workloads can be assigned tightly controlled identities. What changes with an AI agent is the range of actions that may be chosen dynamically rather than specified completely in advance. NIST asks how “least privilege” can be established when an agent's required actions may not be fully predictable before deployment, how authority can change with context, and how an agent can prove that it is permitted to perform a specific action. It also asks how a machine acting “on behalf of” someone should be connected to the human identity that authorized it. Identity and authority therefore have to be separated: knowing which machine made a request does not establish that the machine had the right to make it.

Engineers are already trying to formalize that distinction. A July 2026 Internet-Draft in the IETF OAuth working group describes an authorization framework for AI agents that combines cross-domain identity, policy-based authorization, evidence of user consent, and multi-hop delegation. Instead of giving an agent a broad permission such as access to an account, the framework can express conditions governing what operations are allowed, including rules such as limiting a transaction to a particular amount. Another component is intended to preserve cryptographic evidence of what a user approved, while delegation mechanisms address authority passing from one agent to another. These documents are Internet-Drafts, not established standards, so their existence does not prove that the proposed architecture will ultimately prevail. What they do prove is that machine authorization is becoming specific enough for engineers to define the evidence that should accompany an autonomous action.

The problem becomes more difficult when the machine leaves the environment that issued its credentials. An agent working for one company may eventually need to interact with another company's APIs, services, payment systems, or agents, while each organization maintains its own identity provider and authorization rules. An IETF draft updated on August 4 examines exactly this cross-domain problem, including dynamic identity, interoperable authorization claims, verifiable credentials, and delegation across administrative boundaries. The underlying question is straightforward even if the technical architecture is not: how does Organization B determine what an agent from Organization A is actually entitled to do? A username issued by Organization A is not enough, and neither is a claim from the agent itself. As autonomous systems begin crossing organizational boundaries, authority has to become portable without becoming meaningless. There is a second problem after authorization has already succeeded.

Suppose an agent spends money, changes a production system, signs an agreement, releases information, or delegates part of its task to another agent, and the action is disputed months later. The important record is no longer simply the final transaction; investigators may need to reconstruct which agent acted, which authority existed at that moment, who granted it, what restrictions applied, and what happened next. NIST's current work explicitly includes auditing and non-repudiation, asking how agent actions and intent can be logged in a tamper-resistant, verifiable manner and bound back to human authorization. That is a stronger requirement than ordinary operational logging because the log itself may eventually become evidence in a dispute. The emerging problem is therefore not merely controlling machines before they act, but preserving enough trustworthy history to explain their authority after they have acted.

There are already powerful conventional tools for doing this, and any serious analysis has to begin there. OAuth can delegate access, PKI and digital signatures can establish possession of keys, workload-identity systems such as SPIFFE can identify software processes, and policy engines can enforce fine-grained restrictions. NIST's own concept paper considers these existing technologies alongside zero-trust architecture, digital-identity standards, token protections, and attribute-based access controls rather than proposing a blockchain replacement. Append-only transparency systems also demonstrate that cryptographically auditable history does not require Bitcoin: Certificate Transparency uses Merkle trees, signatures, inclusion proofs, and consistency proofs to make changes to its logs detectable. Its purpose is instructive because the log does not prevent a certificate from being wrongly issued; it creates evidence through which the misissuance can later be detected. An autonomous-agent evidence system could use similar principles without ever touching a public blockchain.

That counterargument eliminates the easiest Bitcoin claim. Bitcoin cannot decide whether an employee was entitled to delegate purchasing authority, whether a machine interpreted an instruction correctly, whether a proposed action is legal, or whether an authorization policy is sensible. It cannot prevent prompt injection merely by recording an event, and it cannot make a dishonest authorization legitimate by timestamping it. An immutable record of excessive permission remains a record of excessive permission, just as an immutable falsehood remains false. Real-time access control therefore belongs primarily to identity systems, authorization servers, policy engines, signatures, secure key management, and other technologies designed for that job. Putting every agent instruction on a blockchain would add infrastructure without answering the central question of whether the instruction should have been authorized in the first place.

Bitcoin becomes interesting only after narrowing the problem further. Imagine an autonomous purchasing agent that receives authority to buy approved supplies for up to $5,000 during a particular week. Conventional systems should authenticate that agent and enforce the spending limit, but a later dispute might concern something different: whether that was actually the authority in force when a contested purchase occurred. A signed authorization record can establish who approved the mandate, while a hash can commit to its exact contents; periodically committing such evidence to a public timestamped transaction history could make later alteration independently detectable outside the systems controlled by either disputing party. The blockchain would not prove that the purchase was wise, that the supplier behaved honestly, or that the person granting authority had good judgment. Its possible contribution would be narrower: providing an external historical reference against which competing versions of the evidence could later be tested.

Even that narrower function has to earn its complexity. Certificate Transparency shows that append-only Merkle logs can already provide inclusion and consistency proofs, although its specification also acknowledges that a dishonest log can attempt to present inconsistent views and therefore retains trust assumptions around the log operator. Organizations can also use signed hash chains, trusted timestamp authorities, replicated audit systems, hardware-backed attestations, or combinations of these approaches. If those systems provide adequate independence for a particular use case, Bitcoin offers little reason to be added. A public proof-of-work ledger becomes materially different only where parties need a historical commitment that does not depend on one organization's continued control of the evidentiary system and where that additional independence is valuable enough to justify using it. The correct test is therefore not whether blockchain can record agent activity, but whether an independently maintained public history changes what the parties can prove when their own records are no longer mutually trusted.

This leads to a broader consequence than AI security alone. Human institutions have long treated authority as something expressed through signatures, contracts, credentials, approvals, roles, and records, but autonomous software forces those pieces into machine-readable form because another machine may have to evaluate them in real time. The result is an emerging chain that should not be collapsed into a single idea of trust: identity establishes who is acting; authorization defines what may be done; execution records what was done; provenance connects the action to its origin; and historical evidence allows the sequence to be reconstructed later. Failure at any one layer is different from failure at another. Bitcoin can potentially strengthen the historical-evidence layer, but it cannot substitute for the layers before it. Understanding that boundary is more useful than declaring that autonomous agents either need blockchain or have no use for it.

AI agents are therefore exposing something that becomes difficult to see when humans remain inside every transaction: authority has a history. A machine can be correctly identified but improperly authorized, properly authorized but compromised, or fully compliant while leaving behind records that another party cannot independently verify. The technical work now emerging around agent identity, consent, delegation, authorization evidence, and auditability is an attempt to make those distinctions explicit before machines gain still greater control over real systems. Most of that infrastructure can and probably should be built with conventional security technologies. Bitcoin earns consideration only where independently verifiable chronology adds something those systems cannot provide efficiently enough on their own. The important question is no longer whether machines will act for us, but what evidence will remain when we later have to prove why they were allowed to act at all.