A Valid Signature Is Not an Authorized Action

An agent presents a signed instruction to a purchasing service. The signature checks out. The agent is recognised, its access token is accepted, and the instruction says it may arrange a supplier order. Is the service now entitled to place the order?

Not yet. It has established something about the request, but it has not necessarily established the business authority for the commitment. Who was entitled to delegate it? Does the instruction cover this supplier, this order and these terms? Has the mandate expired or been revoked? Did the proposed order change after approval?

This is a hypothetical procurement scenario, not a client incident or evidence of a deployed vulnerability. It gives a CIO, COO, identity lead or procurement owner a bounded decision: allow the proposed transaction, narrow the authority, or hold the action for a valid decision by the appropriate approver. That decision belongs before the commitment, not in the explanation written afterwards.

The question a green identity check cannot answer

Authentication, delegated authority and execution approval are related, but they answer different questions. Authentication checks the identity presented under the system's trust arrangements. A token can convey access rights. A cryptographic signature can help establish integrity and origin under the accepted key and verification arrangements. The remaining question is whether a recognised grant of authority permits the specific business effect now being requested.

A properly verified signature over a mandate does not independently establish that its signer had the right to make that mandate. Nor does a valid credential make every reachable action legitimate. A signed instruction to prepare an order is not permission to commit it. A correct record of an unauthorised commitment remains a record of an unauthorised commitment.

The practical distinction is not a claim that existing identity systems cannot enforce business rules. Well-designed IAM and approval workflows often can. It is a request to show how the rules apply to the proposed transaction, rather than substituting a successful identity check for that answer.

What NIST proposes—and where the proposal stops

On 27 October 2026, Harold Booth, Bill Fisher, Ryan Galluzzo and Tom Clancy published NIST's *Design Tenets for Agent Identity Management Systems*. They describe an initial proposed set of ten design tenets, to be applied according to transaction risk, environment and the data and tools involved. This is institutional design guidance, not a binding standard, certification or demonstration of customer outcomes. The authors explicitly caution that current standards and technology will not immediately fulfil every tenet across deployment models. [1]

Several tenets sharpen the buying question. Tenet 1 calls for distinct agent identification, ideally tied to workload, environment and approved configuration. Tenet 2 proposes linking agents to the initiating entity and attenuating delegated scope so downstream entities cannot claim more authority than their parent. Tenets 3 and 4 address minimum privilege, separation of duties, time-bounded grants and runtime revocability. [1]

Tenet 6 describes cryptographically signed mandates stating intended outcomes and constraints, which downstream services can verify and use to support authorization decisions. Its wording matters: a mandate supports a decision. Treating its signature as the whole decision omits whether the grantor is recognised, the constraints apply and the receiving service can enforce them. That last observation is this article's interpretation, not a NIST finding about a particular product. [1]

Tenets 7 and 8 separate the agent's reasoning from policy enforcement and retain deterministic mechanisms as the primary basis for access decisions. Tenet 10 proposes independent, tamper-evident, append-only evidence. Taken together, they offer a useful design direction: the agent may propose an action, a separate mechanism determines whether it is allowed, and an appropriate record survives. They do not establish that a supplier claiming these features has implemented them effectively. [1]

Token exchange is not a complete business trust model

OAuth 2.0 Token Exchange, RFC 8693, is an Internet Standards Track specification published in January 2020. It distinguishes delegation, in which an actor retains its own identity while representing a subject, from impersonation, in which the actor is indistinguishable from the represented party within the authorised rights context. That distinction can be useful when a service acts for another party. [2]

But RFC 8693 explicitly limits its scope to the token-exchange protocol and places no requirements on an implementation's trust model. It does not settle who may bind a company to an order or how every implementation enforces a transaction's terms. Those need defined policy and deployment arrangements. [2]

There is a particularly important revocation limit. Section 2.1 says exchanging a token is a one-time event, not a tight ongoing linkage between input and output tokens. Propagating revocation may be desirable, but it is not a general property of the protocol. A buyer should therefore ask how a withdrawn upstream delegation affects authority already passed downstream, rather than assuming token exchange makes withdrawal immediate everywhere. [2]

There is also a provenance limit. Section 4.1 allows nested actor claims to represent delegation history, but requires access-control decisions to consider the token's top-level claims and current actor; prior nested actors are informational only. A historical chain is not a set of independently operative permission grants. If a deployment needs evidence of the business mandate's origin and limits, it must supply that through appropriate policy and trusted records—not reinterpret nested actor history as permissions the RFC says it is not. [2]

RFC 9700, *Best Current Practice for OAuth 2.0 Security*, supplies an established security foundation. Its recommendations include sender-constrained access tokens and restricting privileges to the required audience, resources and actions, with checks at the resource server. These mechanisms can reduce token misuse and excessive access. They are not agent-specific proof that an entire business transaction is authorised; the application still needs the right rules and enforcement boundary. [3]

Write the mandate around the effect, not the intention

Return to the hypothetical order. “Help procurement buy the required parts” is a goal. It leaves too much unresolved to be the sole authority for an external commitment.

A useful mandate record should identify the represented organisation or person, the authorised grantor, the executing actor and any permitted onward delegation. It should distinguish preparing a proposal from placing an order. It should specify the permitted supplier and order subject, material terms, relevant limits, effective period, approval requirements and withdrawal route. The receiving service must know which record and policy version are authoritative.

These are proposed buyer questions, not a universal mandate format or a requirement that every organisation sign every individual instruction. Some deployments can express the boundary through an existing procurement workflow, identity policy and approval record. Others may need a portable signed statement across company boundaries. Choose the representation after defining what the service must decide.

At a cross-company boundary, two questions remain separate: does the receiving service recognise the issuer and evidence, and does the proposed action fit the authority they establish? A cryptographically sound message from an unrecognised issuer cannot answer the first. A recognised issuer's message with the wrong action or expired authority cannot answer the second. Recognition arrangements, business rules and technical validation must be explicit; no proprietary network or new ledger is assumed here.

Six checks before the action

The following framework is an original management decision aid, not a tested method, security certification or legal conclusion. Apply it to one defined class of consequential action before procurement or expansion.

1. Provenance: who could grant this authority? Identify the recognised grantor, the represented subject, the acting agent and the trusted record of delegation. Show that the grantor's role permits this commitment and any onward delegation. Identity history helps explain the chain; it does not replace an applicable grant.
2. Binding: is this the action that was authorised? Bind approval to the intended effect and material parameters: for the hypothetical order, the supplier, order contents and commercial terms. State which changes require a new decision. A generic “approved” flag should not cover a materially different order merely because the same agent submits it.
3. Scope: what is excluded, including downstream? Separate reading, proposing, committing and making subsequent changes. Define resource, audience, task and business limits. Require downstream services to operate within the applicable boundary, not inherit a broad credential and infer permission from the overall goal.
4. Time and withdrawal: does authority still apply at execution? Define effective time, expiry, revocation and how relevant policy changes reach the enforcing service. Ask about authority already delegated downstream, cached decisions and queued actions. Agree an acceptable propagation bound and the response when current status cannot be established; do not invent a universal “instant revocation” guarantee.
5. Enforcement: what can actually stop the effect? Locate the decision and enforcement points outside the agent's reasoning. Show how applicable rules produce allow, deny or escalation before the receiving system commits the action. A prompt telling the agent to respect policy, or an alert after commitment, is not the same preventive mechanism.
6. Decision evidence: what explains this particular outcome? Retain proportionate evidence of the actor, mandate reference, relevant policy version, action parameters, approval and enforcement outcome. Keep the evidence outside the agent's unilateral control. Protect access and minimise sensitive data; an append-only trail is evidence of what was recorded, not independent proof that the original grant was legitimate.

The checks should not be averaged into a readiness percentage. Missing authority for an approval-required commitment is not cancelled out by excellent identity or logging. Make the unresolved condition visible and decide what narrower action remains permissible.

Ask for a boundary demonstration, not a signature demonstration

In an authorised, isolated environment, ask the supplier or internal team to demonstrate the defined boundary using benign test records. First show an in-scope transaction proceeding with the required authority. Then show ordinary rejection cases: a request outside the mandate, a changed material parameter, expired or withdrawn authority, and a required approval that is absent. Include a downstream handoff if the planned deployment uses one.

For each case, agree the expected decision beforehand and inspect the receiving system's state. An agent saying “blocked” is weaker evidence than confirmation that no prohibited commitment occurred. Conversely, a failed request alone may reflect an unrelated integration error; preserve the decision reason and relevant configuration so a test does not accidentally pass for the wrong reason.

Ask what happens when a transaction waits in a queue while its authority changes. Where the receiving system cannot guarantee the needed check at commitment, the design may need a shorter grant, a fresh approval, a constrained transaction path or no autonomous commitment. The appropriate choice depends on the effect and implementation; this is not a claim that one prescribed architecture solves every timing problem.

End with a bounded outcome: allow within the demonstrated mandate; narrow to a smaller action that can be enforced; or hold the consequential action pending valid approval or missing evidence. A test pass supports that tested configuration. New connectors, new delegation paths or changed business limits may require targeted reassessment. None of this establishes all future actions safe.

The strongest counterargument: ordinary controls may already be enough

An experienced identity lead may reasonably object that least privilege, resource-level policy and procurement approvals are established work. Adding a new “agent mandate layer” can duplicate those controls, introduce new issuers and make a simple workflow harder to operate. Cryptographic plumbing can add complexity without fixing a badly defined approval rule.

That objection is important. In their 27 August 2026 NIST perspective, Bill Fisher and Ryan Galluzzo explicitly argue for existing IAM foundations and note that many agentic use cases can be accommodated through modern authorization patterns. Their institutional commentary is not an independently tested outcome, but it is a strong reason not to assume a new platform is the starting point. [4]

For a bounded internal workflow, distinct workload identities, tightly scoped access and the existing business approval process may be sufficient. A conventional rules-based service can apply an approved change while the agent only prepares it. Keeping the current manual approval for rare, high-consequence commitments may be cheaper and clearer than engineering autonomous delegation. A specialist identity assessment may help when the trust boundary spans companies or the technical evidence is unclear, but it should name its scope rather than promise universal assurance.

More human approval is not automatically better. NIST's August discussion also warns about consent fatigue. Reserve review for meaningful decisions, give approvers the relevant context and avoid substituting habitual clicking for authority. The alternative to unrestricted autonomy is not necessarily a person approving every trivial step. It can be a well-defined mandate with exceptional cases routed for a real decision. [4]

What remains unproven

The sources support design principles, protocol semantics and security recommendations. They provide no evidence here of customer demand, commercial adoption, audited benefits or a vendor's successful implementation. NIST's new tenets describe a direction whose full realisation exceeds parts of today's standards and technology. RFC conformance alone cannot establish the organisation's business authority arrangements.

The framework in this article is a proposed way to make one decision explicit. It does not determine statutory authority, contractual enforceability or compliance obligations; those may require qualified advice. Nor does it claim that a valid mandate guarantees a good decision. A properly authorised order can still be commercially unwise. Authority is a necessary boundary for the commitment, not a substitute for judgement about its value.

The useful buying question is smaller than “Can we trust AI agents?” Ask instead: can this service show why this actor may perform this action, under this mandate, at this time—and prevent it when that answer no longer holds? If the answer is incomplete, narrow the permission or hold the commitment. If existing controls already establish it, use them.

If you need to frame the operational decision first, start the free Workflow Fit Diagnostic. It can help clarify the business problem and a possible next step; it does not validate mandates, audit identity controls or certify authorization. The free result may be enough.