Zeropcter ·
What Does It Mean to Authorize a Machine?
By 0pcter
Artificial intelligence is crossing a boundary that matters more than another improvement in model intelligence. AI systems are beginning to act: deploying code, accessing databases, managing communications, calling APIs, purchasing goods, and performing tasks with limited human supervision. NIST describes this transition as a movement from systems producing generative outputs toward agents capable of taking actions such as deploying code to production. That changes the security problem because an incorrect answer and an unauthorized action are fundamentally different failures. An incorrect answer can mislead a person, while an unauthorized action can alter a system before a person ever sees it. The important question is therefore becoming not simply what an AI knows, but what a machine is allowed to do on someone else's behalf.
Human institutions already have elaborate mechanisms for answering that question when people act. Employees receive identities, permissions, credentials, roles, spending limits, approval requirements, and records linking important actions to responsible individuals. Software has long operated through service accounts and machine credentials, but autonomous agents complicate that model because they can select actions dynamically rather than merely execute predetermined instructions. NIST is now investigating how agents should be identified, authenticated and authorized, how least privilege should apply when their future actions cannot be completely predicted, and how an agent can prove its authority for a particular action. Its work also asks how delegated authority should operate when an agent acts “on behalf of” a person. These are not questions about whether an AI response sounds trustworthy; they are questions about the infrastructure of authority.
The distinction between identity and authority is essential. Proving which agent sent a request does not prove that the agent was permitted to make it, just as identifying an employee does not give that employee permission to transfer corporate funds. An agent may possess a valid cryptographic identity while attempting an action outside the scope its owner intended. That is why emerging technical work is separating agent identity from fine-grained authorization, including proposals for tokens representing specific operations approved by a human principal. One IETF Internet-Draft proposes a structured mechanism in which an authorization request describes proposed operations and a subsequent token represents confirmed authority for those operations. The significance is not that this particular draft will become the standard, but that engineers are beginning to represent machine authority as something that should be explicit, constrained and verifiable rather than inferred from possession of a password or API key.
This becomes harder when agents cross organizational boundaries.
An agent acting for one company may eventually interact with another company's agent, payment service, database, marketplace or API, each operating under different identity providers and authorization systems. An August 2026 Internet-Draft involving contributors from Cisco, AWS, Skyfire and others is examining precisely this problem: securely sharing authorization information between agents operating across different administrative domains. Another August draft proposes workload authorization grants in which individual agents receive non-reassignable identifiers and obtain access tokens from cryptographically signed authorization grants. These efforts remain works in progress rather than established standards, and that limitation matters. Yet their existence shows where the infrastructure problem is moving: from identifying software inside one controlled environment toward proving delegated authority between systems that may not share the same authority infrastructure.
Authorization alone still does not create accountability. After an agent acts, an organization may need to establish which agent performed the action, what authority existed at that moment, which human or organization delegated that authority, what resources were accessed, and what sequence of events followed. NIST's concept paper explicitly raises auditing and non-repudiation, including how agent actions can be logged in a tamper-resistant and verifiable manner and bound back to human authorization. That requirement exposes an important distinction between an operational log and evidence: a database saying that an action occurred is only as independent as the party controlling that database. Conventional cryptographic signatures, secure logging, hardware-backed keys and transparency systems can substantially strengthen those records without using a blockchain. In many organizations, those technologies may be entirely sufficient.
That is where claims about Bitcoin require restraint. Bitcoin cannot determine whether a human should delegate an…