Main claim: A machine action is controlled when the executing system verifies who requested it, whether that caller may access the resource, and whether the caller may authorize that exact effect.
A service can authenticate an agent and authorize access to a payment API while still executing an unintended payment. The first control verifies the caller, and the second grants access to a resource. A separate action authority must approve one exact transfer. This article separates authentication, authorization, and authority, then shows how to enforce all three before a machine action creates an effect.
Why separate three security questions?
Security designs fail when one control is expected to answer three different questions. A valid identity, an allowed API call, and an approved business action are related controls with different jobs.
This article uses the following model:
| Control | Question | Example |
|---|---|---|
| Authentication | Who is making the request? | This request came from treasury-agent-prod |
| Authorization | May this caller access this resource or operation? | The agent may call POST /payments |
| Authority | May this identity authorize this exact effect? | The agent may send 25,000 USDC to the named vendor for invoice INV-4821 |
Authentication and authorization have established definitions. NIST defines authentication as establishing confidence in a claimed identity and access control as granting or denying requests to use resources.
Authority has several meanings across security, law, and organizational governance. Here, authority means the declared set of real-world effects that a cryptographic identity may approve. TKeeper uses this model; other standards use the term more broadly.
What does authentication prove?
Authentication proves that a caller controls a credential bound to a claimed identity. The credential may be a private key, certificate, token, workload credential, or another authenticator.
Caller identity and caller behavior require separate controls. A compromised service can use its legitimate certificate, and a hijacked agent can use its legitimate OAuth token.
Assume a backend authenticates treasury-agent-prod through mutual TLS. The successful handshake tells the backend which workload presented the certificate. Policy must evaluate the vendor, amount, network, and invoice separately.
Authentication is still necessary because every later decision needs a subject. Without a distinct identity, policy cannot assign permissions, ownership, lifecycle, or accountability to the caller.
What does authorization grant?
Authorization grants or denies access to a resource or operation under a policy. An API gateway may allow one client to read balances, another to prepare payments, and a third to submit payments.
OAuth represents authorization with access tokens. RFC 6749 defines a token as a credential with a scope, lifetime, and other access attributes that a resource server enforces.
Scopes can be narrow or broad. balances:read describes a smaller capability than payments:write, but neither string defines every payment field by itself.
OAuth Rich Authorization Requests can carry structured details such as actions, locations, identifiers, and API-specific fields. This gives an authorization server more context than a flat scope. The protected API must still define the meaning of those fields and enforce them when it processes the request.
Authorization therefore answers whether a caller may attempt an operation within a resource model. The resource server remains responsible for validating the requested action.
What does authority constrain?
Authority constrains the effects an identity may make real. Its boundary follows the meaning of the downstream action beyond the API route.
A payment identity may have authority limited by:
- asset
- maximum amount
- destination
- network or payment rail
- invoice or business purpose
- time window
- required approval
A deployment identity needs a different authority. Its boundary may include the service, artifact digest, environment, release window, and approver.
An authority definition becomes useful when the system can turn a request into a canonical intent and compare that intent with policy. The identity should produce cryptographic proof only after the intent passes those checks.
How can authentication and authorization both succeed for the wrong action?
Broad access can carry a valid caller to an invalid effect. The failure occurs when policy controls the route while the request's full meaning remains ungoverned.
Consider this example payment request:
{
"action": "transfer",
"asset": "USDC",
"amount": "25000",
"destination": "0x8c...42",
"network": "base",
"invoice": "INV-4821",
"expiresAt": "2026-07-28T16:00:00Z"
}
The agent authenticates as treasury-agent-prod. Its token permits payments:write. Authentication and authorization both succeed.
An attacker then changes the destination through prompt injection or compromised application state. The identity and token remain valid, so a route-level check still passes. The payment becomes unsafe because the system never checked whether this identity had authority for the new destination.
An action-level authority check would evaluate the asset, amount, destination, network, invoice, and expiry together. A changed destination would create a different intent and fail unless policy or an approver explicitly accepted it.
Where does policy fit?
Policy decides whether a presented intent falls within an identity's authority. Policy may use static rules, runtime context, external risk verdicts, or human approvals.
The policy engine should receive structured fields with stable meaning. A rule cannot reliably limit payment amounts when the signing service sees only an opaque digest and has no trusted parser for the transaction.
An ALLOW result becomes enforcement when the payment backend requires it and executes the same payload that policy evaluated.
The accepted intent must therefore remain bound across policy evaluation, proof generation, verification, and execution:
request
-> canonical intent
-> policy decision
-> cryptographic proof over the accepted intent
-> backend verification
-> execution of the same intent
Each arrow carries a security requirement. A payload substitution between any two stages can detach the approved meaning from the final effect.
Why add cryptographic proof?
Cryptographic proof lets the executing system verify authorization without trusting an unprotected ALLOW field or an agent-provided claim. The signature binds an expected identity to specific bytes.
Policy selects acceptable intents. Cryptography makes later modification detectable.
The verifier supplies semantic meaning by mapping the signed bytes to the action it will execute.
Google's Agent Payments Protocol demonstrates this separation for agentic commerce. A user delegates a cryptographically verifiable mandate, and the final verifier checks both the mandate's integrity and whether its content permits the requested action. AP2 is payment-specific, but the verification pattern applies to other consequential machine actions.
How is governed signing different from ordinary signing?
Ordinary signing services often control who may invoke a key and which algorithm the caller may use. The caller supplies the message or digest.
AWS KMS, for example, requires kms:Sign permission and accepts a message, digest, or ML-DSA external representative for an asymmetric signing key. KMS produces a valid signature over that input; the surrounding application defines what the input means.
Governed signing adds semantic controls before signature generation. The signer materializes a known intent, evaluates authority and policy, then signs only the accepted representation.
The difference is the security question:
Ordinary signing: May this caller use this key to sign these bytes?
Governed signing: May this key identity authorize the exact action represented by these bytes?
Both models can protect key material. Only the second model claims to understand and govern the action.
Where must enforcement happen?
The component that creates the effect must require the proof. A check placed beside the execution path can be bypassed.
For the payment example, the payment backend should:
- Build or validate the exact payment intent.
- Require proof from the expected treasury identity.
- Verify that the proof covers every effect-changing field.
- Check expiry, nonce, sequence, or idempotency rules.
- Execute the same payment covered by the proof.
The backend should require the trusted treasury key. A signature from another key proves a different identity authorized the payload.
The backend should reject unsigned fields that change the effect. A signature covering the amount while omitting the network or destination leaves those fields open to substitution.
When do you need all three controls?
Use all three controls when a machine can produce a financial, security, compliance, or operational consequence. The cost of an extra authority layer should match the effect it protects.
Common cases include:
- moving funds or signing blockchain transactions
- deploying code or changing production infrastructure
- issuing certificates or credentials
- exporting protected data
- approving a privileged internal command
- accepting a high-risk action from an AI agent
A low-risk read may need only workload authentication and narrow resource authorization. A production write usually needs action validation, replay protection, and stronger audit. An irreversible or high-value action may also need quorum or human approval.
The decision should follow the failure mode. Ask what happens if a valid identity uses an allowed operation with malicious or incorrect parameters.
What are the common design errors?
One broad role grants too much authority. A payments-admin permission compresses many assets, destinations, amounts, and environments into one access decision.
Shared credentials hide the actor. Multiple agents using one token prevent the backend from applying distinct authority, ownership, and lifecycle rules.
Policy evaluates incomplete data. A rule over amount cannot control the effect when destination or network remains outside the governed intent.
Approval records a description while the payload remains unbound. Bind invoice INV-4821 to the exact destination, amount, asset, and rail presented to the approver.
The signer accepts arbitrary bytes. Raw signing may be necessary for some systems, but it cannot support a claim that the signer understood the action.
The verifier checks the expected identity, exact intent, freshness, and external context that policy used.
An alternate path bypasses proof. A direct administrator credential or secondary API can defeat the authority boundary if it creates the same effect with weaker controls.
Where does this model stop?
Policy quality sets the authority boundary. A policy that allows every destination authorizes every destination when implemented correctly.
Compromise of every required authority defeats the model. In a threshold design, compromise of enough peers breaks the quorum assumption.
Availability depends on policy services, approvers, signers, and verifier checks. An unavailable dependency can block execution.
Host security, network controls, sandboxing, prompt-injection defenses, fraud systems, and operational monitoring address other causes of failure.
What should you do next?
Map one machine action through three columns: authenticated identity, resource permission, and exact effect authority. Then identify the backend that creates the effect and make that backend reject requests without proof over the full intent.
Read What Is AI Agent Identity? for the identity model, Governed Cryptographic Identity for the TKeeper boundary, and Authorities for the signing model.