A machine identity refers to the identity of a non-human actor within a digital system, such as a workload, service, container, VM, pipeline, bot, script, device, integration, or agent. It allows infrastructure to distinguish between machine actors, issue and rotate credentials, revoke access, apply access rules, and audit interactions between machines and systems.
Modern infrastructure is primarily machine-to-machine. Services interact with other services, pipelines deploy artifacts, and agents invoke tools. While human users are still present, software identities now manage most of the execution path.
So we gave machines names and credentials: service accounts, workload identities, certificates, tokens, IAM roles, mTLS, SPIFFE, secret managers, and device identities.
That solves the first part of access control: the system can identify the caller and determine which capabilities it can access. The next part is more subtle. Once a machine reaches a capability, the important question becomes what this specific call is allowed to cause.
The initial phase of machine identity was designed for infrastructure that operated more predictably than current systems. Workloads had defined roles, pipelines had specific jobs, and services had designated APIs. While incidents still occurred, the model was largely static: define the machine, grant access, rotate credentials, and audit usage.
This model is now challenged as machine actions become more dynamic and financially significant. AI agents are integrated with tools that search, purchase, refund, book, trade, deploy, and interact with other services. Wallet infrastructure is evolving to support agents that hold funds, make payments, and interact with on-chain systems. Payment protocols are being developed specifically for APIs and agents, rather than human checkout flows. For example, Coinbase launched x402 for HTTP-native stablecoin payments across APIs, apps, and AI agents; AgentKit enables AI agents with wallet and on-chain capabilities; Google’s AP2 structures agent payments around authorization and accountability; and AWS AgentCore Payments connects autonomous agents to payment flows through Coinbase and Stripe integrations.
This issue extends beyond crypto wallets. Wallets simply make the authority problem more visible, as transactions have clearly defined consequences such as recipient, amount, spender, chain, calldata, fee, and validity constraints. Similar challenges arise when an AI support agent issues refunds, an infrastructure agent changes deployment configurations, a procurement workflow pays invoices, or internal automation modifies permissions. In these cases, the machine does more than call an API; it produces business, financial, operational, or trust-related effects.
The key shift is that systems are moving from machine access to machine execution. Machines are now positioned in front of capabilities where the same authenticated call can produce significantly different outcomes based on parameters, context, and downstream state. As a result, identity and capability access alone are insufficient boundaries, since the primary risk now resides within the requested action.
When machines begin to cause external effects, access control must consider more than just the interface being called. Permissions such as can_use_signer, can_deploy, can_issue_certificate, can_refund, or can_call_tool are only starting points. The critical authority question lies within the request itself: what is being signed, which artifact is being deployed, which certificate is being issued, which customer action is being performed, and which tool effect is being triggered.
Policy engines are essential because hardcoded access checks do not scale across diverse contexts. Policies can define limits, recipients, environments, time windows, approval rules, allowed domains, asset types, and other constraints without embedding every decision in application code. However, a policy engine is only effective if it receives the appropriate object to evaluate. Providing only action = sign or resource = deployer offers minimal value.
The system must transform the request into a format that policy can evaluate. For simple operations, request fields may suffice. For structured protocols, the system must parse the object and determine its actual effect, such as transaction effects from calldata, certificate effects from extensions and subject names, deployment effects from artifact identity and target environment, and permission effects from the access delta. Otherwise, policy authors are forced to reason over raw verbs and loosely related fields, increasing the risk of errors.
Effects provide policy with a standardized target, making the evaluated consequence explicit, such as value movement, spender approval, or credential issuance. This reduces the risk that policy checks one field while the actual consequence is elsewhere.
This approach is effective only for effects the system can model. Some effects require interpretation, such as determining whether a configuration change introduces risk. These are separate challenges. They can be researched, classified, and marked as interpreted, but they lack the enforcement strength of deterministic effects.
The outcome of a policy check must persist beyond the process that initiated it. Returning ALLOW to a caller is insufficient if the component causing the effect remains directly accessible. The decision should be accompanied by evidence, ideally signed, so that the signer, issuer, deployer, wallet, payment rail, or tool can verify it before execution.
Additionally, if the policy engine is separate from the system that issues evidence and the authority-bearing component does not verify that evidence, the policy engine serves only as an advisory tool. A guardrail that can be bypassed is merely a recommendation.
MAF is a framework for evaluating machine-authority risk in existing infrastructure. It begins by examining why the action was possible.
While statements such as “A pipeline deployed the wrong artifact,” “an agent issued the wrong refund,” “a signer approved the wrong transaction,” or “a service minted the wrong certificate” describe the incident, MAF focuses on why the authority boundary permitted it.
Was the authority defined by a broad capability rather than a specific outcome? Did a credential, signed artifact, approval, or deployment persist beyond its intended context? Did enforcement occur outside the component that caused the consequence? These questions make MAF a practical review tool. Teams can apply it to signers, CI/CD pipelines, wallets, agent tools, certificate issuers, cloud roles, internal admin flows, or payment workflows to identify where machine authority might exceed intended boundaries before issues arise.
The current classes describe the main failure mechanisms:
Scope failures identify authority granted wider than the job. The review question is whether the machine can cause outcomes outside the intended boundary through a permission that looks legitimate.
Delegation failures identify authority that changes as you move through services, agents, workflows, or deputies. The review question is whether the chain can produce an outcome that no single actor was meant to authorize.
Lifecycle failures identify authority and consequences that survive their original context. The review question is whether credentials, approvals, signatures, issued artifacts, or deployments remain valid after the reasons for them change.
Consequence modeling failures occur when decisions are made without a reliable model of the effect. The review question is whether the policy evaluates the outcome or merely evaluates a surface action.
Enforcement failures identify controls placed outside the authority path. The review question is whether the component that causes the effect verifies the decision, or whether policy can be bypassed by reaching the primitive directly.
Composition failures identify unsafe outcomes that result from combining individually valid actions. The review question is whether the system checks aggregate effects across steps, actors, or time.
This makes the framework valuable both before and after an incident, providing teams with a method to assess existing systems and determine where the architecture permits machines to cause unintended outcomes.
Machine authority is not going to stay inside one domain. AI agents amplify the problem, but the same mechanics already exist in wallets, CI/CD, certificate issuance, cloud automation, internal admin tools, support operations, finance workflows, and payment systems.
That matters for the taxonomy. A wallet engineer will see failure patterns that an IAM team will miss. A CI/CD team will notice delegation and deployment issues that an agent builder may not classify correctly. People working on policy engines, signing infrastructure, cloud platforms, incident response, and internal tools will bring different examples of the same authority boundary-breaking.
MAF needs that pressure. If a case does not fit, the class is challenged. If a class becomes too broad, it gets split. If two classes overlap too much, the boundary is tightened. If the taxonomy cannot describe a real failure, the taxonomy changes.
The point is not to collect opinions. The point is to make the framework useful for evaluating real systems.
exploit.org keeps the work public: cases, disputes, proposed changes, rejected changes, member votes, and the reasoning behind taxonomy updates. Members help review candidate failures, vote on taxonomy-changing proposals, and bring examples from systems they actually understand.
If you build or break machine systems, contribute a case. The map gets better when it is forced to explain real failures.