The payment every layer accepted

At 10:02, a treasury analyst asks a fictional system called Juniper Treasury to “pay the approved supplier invoice JN-447”. The client agent discovers a payment agent through an Agent2Agent card. It submits a valid task. The payment agent calls a typed payment tool through the Model Context Protocol. TLS succeeds. The OAuth token has the right audience and scope. The tool input matches its schema. The remote task enters a completed state and returns a payment reference.

Every protocol check is green. Yet the payment is wrong.

At 10:01:58, a separate accounts-payable process marked JN-447 as a duplicate. The approval used to obtain the token was valid when issued, but it was no longer valid when the payment effect was committed. Nothing in the transport failed. No message was malformed. No attacker forged a credential. The system performed an unauthorised action through a sound exchange.

The first intuition is to ask for a stronger protocol. Add a richer task state. Put the invoice identifier into the token. Sign the tool call. Propagate a trace identifier. Require a unique message identifier. Each is useful. None answers the decisive question: was this payment still permitted against the authoritative invoice state at the moment money moved?

This is the agentic version of a much older systems problem. Saltzer, Reed and Clark argued that some functions can be implemented completely and correctly only with knowledge held by the application at the endpoints. Lower layers may support those functions, sometimes dramatically, but cannot discharge the final responsibility. Their examples included duplicate suppression, crash recovery, encryption and delivery acknowledgement.¹

The modern mistake is not using protocols. It is treating protocol conformance as semantic closure. A protocol can carry evidence about an action without possessing the application knowledge needed to decide whether the action is right.

A valid exchange can still be a wrong act

MCP and A2A solve real interoperability problems. MCP gives hosts, clients and servers a common way to expose resources, prompts and tools. A2A gives independent agent systems a common model for discovery, messages, tasks, artifacts, asynchronous work and lifecycle states. These are valuable because a shared envelope reduces custom integration and lets implementations evolve behind a stable boundary.²⁵

Good specifications also reveal their limits. The MCP specification says that the protocol itself cannot enforce its trust and safety principles and assigns consent, access control and data protection to implementors. Its tools specification leaves the interaction model to applications and recommends confirmation interfaces for tool use.²³ A2A requires authentication of requests, but says that authorisation logic is implementation-specific. For in-task authorisation, A2A explicitly does not define the scope, representation, validity or revocation semantics of the resulting decision or credential.⁵

That is not a defect. A general protocol cannot know whether JN-447 is a genuine invoice, whether the payer has a remaining daily limit, whether a sanctions hold arrived five seconds ago, or whether “pay” means schedule, reserve, release or settle. If the protocol attempted to hard-code those meanings, it would become a treasury application rather than a general agent protocol.

Five kinds of closure

The word “success” hides several different achievements. A response can close one layer while leaving the next unresolved. The distinction matters most when a task has external effects.

A2A’s TASK_STATE_COMPLETED means that an agent task finished successfully under that implementation’s task semantics. It does not universally mean that a bank settled funds, a warehouse changed title, a medical order reached the right patient, or a regulator would accept the action. Likewise, a trace identifier correlates calls across services, but correlation is not a proof that the intended postcondition occurred.⁵¹²

The hidden assumption is that the protocol’s success predicate and the application’s success predicate are the same. They coincide only when the application has deliberately made them coincide, through typed semantics, fresh checks, effect receipts and readback.

Why the green lights are persuasive

Each green light answers a legitimate question, so the chain feels cumulative. A signature supports who produced a message. A schema supports how fields should be interpreted. An audience-restricted token supports where a credential may be used. A completed task supports what the remote agent claims about its lifecycle. A trace supports which calls belong to one distributed path. When these answers are placed on one screen, the eye reads them as a single proof.

But the questions are not substitutable. A signature does not establish purpose. A scope does not establish that approval remains current. A task state does not establish that an external ledger changed. A trace does not establish that the correlated calls caused the intended effect. Assurance accumulates only when the conclusion of one check is a valid premise for the next. Otherwise the dashboard is a row of true statements surrounding an unproved claim.

Protocol soundness is a component property

A protocol can be sound relative to its own contract while the configured system remains unsound relative to the user’s goal. Suppose A2A correctly authenticates a client, delivers a message once, preserves task history and reports a terminal state. Suppose MCP correctly validates the tool schema and returns structured content. Those are meaningful guarantees. They constrain possible failures and make evidence easier to inspect.

System soundness asks a different question: does every accepted execution satisfy the application invariant? For the payment case, the invariant is not “a valid client invoked the tool”. It is “only a currently approved invoice, for the approved beneficiary and amount, may cause one settled payment”. The protocol contracts become premises inside that proof. They are not the proof’s conclusion. This distinction avoids two opposite errors: blaming a protocol for semantics it never claimed, and crediting protocol conformance for application obligations it never observed.

flowchart TD
  A["The payment every layer accepted"] --> B["A valid exchange can still be<br/>a wrong act"]
  B --> C["Where correctness can be known"]
  C --> D["The protocol obligation profile"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#B96D00,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Where correctness can be known

The end-to-end argument is often reduced to “put intelligence at the edge”. That slogan is too crude. The original argument is about function placement under incomplete knowledge. A lower layer should not claim complete correctness when only the application can observe all conditions that define correctness. Lower-layer support still matters for efficiency, common defence and early rejection.¹

For agent protocols, the practical question is not “protocol or application?” It is: which facts can distinguish a permitted operation from a forbidden one, and which component can observe those facts at the required time?

The transcript-indistinguishability test

Let τ be the complete protocol transcript visible to a protocol-level control: messages, identities, signatures, scopes, task states, timestamps and correlation identifiers. Let x contain application facts not necessarily present in that transcript: current approval state, business purpose, beneficiary status, resource version, transaction limit and intended postcondition.

Suppose g(τ, x) is the correct decision, while h(τ) is a protocol-only decision rule. A protocol-only rule can be complete only if every application world compatible with the same transcript requires the same decision.

Call the pair (x₁, x₂) a semantic separation witness. Finding one proves that the obligation cannot be discharged from the transcript alone. The control must move to, or receive help from, a boundary with access to the distinguishing fact.

The smallest useful example

Assume the protocol sees two positive facts: a valid credential and a completed response. The application has two hidden bits: whether authority is still current and whether the effect actually occurred. Four worlds share the same visible transcript. Only the world with current authority and a real effect deserves an accepted success. One world should have been rejected before execution; another requires recovery because the claimed effect is absent. No refinement of the two visible bits can separate those worlds. The system needs one fresh pre-effect observation and one post-effect observation.

Use the test on duplicate prevention. A2A says that Send Message operations may be idempotent and that an agent may use messageId to detect duplicates.⁵ That prevents the same message from being processed twice when implemented. It does not decide whether two different messages represent the same business operation, whether one request intentionally supersedes another, or whether a repeated operation is safe after a partial effect.

HTTP makes the distinction explicit. An idempotent method has the same intended server effect when repeated, but clients should not automatically retry a non-idempotent request unless they know the application semantics are idempotent or can determine that the original request was not applied.⁶ An idempotency key is therefore assistance, not semantic closure. The application still defines the operation identity, payload fingerprint, retention window and response to a changed request.

Authority is a time-indexed relation

OAuth can make delegation far more precise than a bearer token with a broad scope.⁷ Resource Indicators bind a token to an intended protected resource. Token Exchange can distinguish the subject whose rights are used from the actor exercising them. Rich Authorization Requests can carry structured details such as amount, creditor and account. DPoP can sender-constrain a token and reduce replay.⁸⁹¹⁰¹¹

These mechanisms improve the evidence available to the application. They do not freeze policy or world state. A valid token proves something like “this actor has a credential minted under these conditions”. The application must still answer “does that delegated capability permit this action against the present resource version and current policy?”

Protocols can help that decision in three disciplined ways. They can carry the facts the application will evaluate, such as actor, subject, audience, purpose and action parameters. They can protect those facts against alteration, replay or delivery to the wrong peer. They can coordinate the interaction, for example by signalling that more authorisation is required or by preserving a long-running task handle. What they cannot do generically is assign domain meaning to those facts or guarantee that the facts remain sufficient until commitment.

This division is productive. A protocol extension that carries a resource version lets the executor reject stale decisions without re-parsing prose. A task state that requests authorisation lets a client obtain a credential through the correct channel. A trace identifier lets investigators join evidence across services. The application still defines which resource version is authoritative, what authorisation permits, and which joined events prove the required outcome.

MCP’s security guidance on token audience, confused deputies and scope minimisation illustrates the same pattern. A token intended for one resource should not pass through unexamined to another. Broad scopes obscure user intent per operation. The remedy is more than a better envelope; it is an application boundary that validates audience, narrows privilege and evaluates the requested operation.⁴

The protocol obligation profile

The Protocol Obligation Profile turns the argument into a design instrument. For each obligation, it records what the protocol can guarantee, the semantic separation witness that defeats protocol-only enforcement, the component that owns the final decision and the evidence required to close the outcome.

The key move is to profile obligations, not products. “We use OAuth”, “we support MCP” and “our agents communicate over A2A” are implementation facts. They do not answer where authority, effect and recovery terminate.

How to construct a profile without guessing

Start with the consequence, not the API method. “Send message” is too low-level; “release £5,000 to supplier SUP-8831” names the effect whose correctness matters. Next, write the ideal decision predicate in plain language. For Juniper Treasury it is: release only when the named invoice is approved, the beneficiary and amount match that approval, the actor is acting for the authorised subject and purpose, limits remain available, and no superseding hold exists.

Now freeze the protocol transcript. Keep the same identities, signatures, scopes, task identifier, message identifier, payload and success response. Change one application fact at a time. Revoke approval. Change the resource version. Replace the beneficiary after authorisation. Let the executor commit but lose its response. Let it return success while the downstream ledger rejects the transfer. Every change that flips the correct decision is a separation witness.

Finally, assign an owner and evidence path to each witness. The protocol can reject malformed or unauthenticated requests. The authority kernel owns facts required before commitment. The executor owns the effect attempt. The verifier owns acceptance of the postcondition. The recovery controller owns unresolved or partial outcomes. This division is more useful than a generic “secure agent” label because every obligation has a named place to fail closed.

One operation, four meanings of “retry”

Consider four payment failures that all appear to the client as a timeout. In the first, the request never reached the executor. Retrying the same operation is necessary. In the second, the executor reserved funds but did not submit settlement. A blind retry could create a second reservation, so the recovery action is to resume or cancel the existing operation. In the third, settlement succeeded and only the response was lost. Retrying would duplicate the payment unless the domain idempotency record returns the original result. In the fourth, settlement succeeded and was then reversed by a downstream control. The correct next step might be review, not retry.

The transport symptom is identical, but the domain action differs in every case. A message identifier helps correlate the attempts. An idempotency key can bind retries to one operation. Neither discovers which state the operation reached. The profile therefore places timeout signalling in the protocol, operation identity in the application boundary, durable progress in the executor, and the retry decision in recovery after readback. “Retryable” is not a property of silence; it is a conclusion about the prior effect.

A toy case: the door during a fire alarm

A badge reader receives a signed request to unlock laboratory L7. The badge is valid and the holder has normal access. In ordinary state, unlock is correct. During a containment alarm, the same request must be denied, or routed through an emergency rule. The protocol proves who presented the badge. The building controller supplies the distinguishing fact. If the alarm status is unavailable, the safe response follows the domain’s failure policy, not the protocol’s optimism.

This example is small enough to see mentally, yet it contains the whole pattern: identity is stable, authority is contextual, world state is volatile and the consequence of stale information is asymmetric.

A configured action contract

Return to Juniper Treasury. The protocol should carry more than natural-language intent, but every extra field has a specific job. A typed action contract turns a model proposal into inspectable data. It does not make the proposal authoritative by itself.

{
  "action": "payment.release",
  "actor": "agent-17",
  "subject": "analyst-42",
  "purpose": "settle-approved-invoice",
  "invoice_id": "JN-447",
  "amount": {"currency": "GBP", "value": "5000.00"},
  "beneficiary_ref": "SUP-8831",
  "resource_version": "invoice:v31",
  "decision_ref": "pd-7d9…",
  "idempotency_key": "pay:JN-447:v31",
  "expected_postcondition": "status=settled"
}

Rich Authorization Requests show that structured authorisation can carry fine-grained payment details.¹⁰ The profile adds two conditions. First, the authorisation decision is bound to a resource version and expires quickly. Second, the executor returns an effect receipt that the verifier does not treat as self-proving.

How to apply it: profile one obligation at a time, such as “prevent duplicate payment” or “prove the shipment was released”. A positive separation result means at least one application fact can flip the correct outcome while the transcript stays fixed. The protocol may still carry inputs and reject obvious failures, but the final check must reach an application boundary. A negative result permits protocol-level placement only for the facts actually tested. It is not proof that no unimagined witness exists.

The profiler assumes that the protocol transcript has been defined honestly and that authoritative sources exist. It cannot tell whether a policy is ethically acceptable, whether an identity proof is trustworthy, whether the verifier is independent, or whether a human confirmation interface produces informed consent. It places responsibility; it does not certify implementation quality.

function countMisclassified(rule) {
  let wrong = 0;
  for (const credential of [false, true]) {
    for (const authority of [false, true]) {
      for (const effect of [false, true]) {
        for (const receipt of [false, true]) {
          const idealRelease = credential && authority;
          const idealSuccess = idealRelease && effect;

          let predictedRelease;
          let predictedSuccess;

          if (rule === "protocol") {
            predictedRelease = credential;
            predictedSuccess = credential && receipt;
          } else if (rule === "boundary") {
            predictedRelease = credential && authority;
            predictedSuccess = predictedRelease && receipt;
          } else {
            predictedRelease = credential && authority;
            predictedSuccess = predictedRelease && effect;
          }

          if (predictedRelease !== idealRelease ||
              predictedSuccess !== idealSuccess) wrong += 1;
        }
      }
    }
  }
  return wrong;
}

console.log({
  protocol: countMisclassified("protocol"), // 6
  boundary: countMisclassified("boundary"), // 2
  full: countMisclassified("full")          // 0
});

stateDiagram-v2
  [*] --> Claim
  state "The responsibility tunnel" as Claim
  state "Thought experiment, the<br/>perfect courier" as Test
  state "One transcript, two correct<br/>decisions" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Build the boundary, do not decorate the protocol

An application boundary is more than another API gateway. It is the point where a stochastic proposal becomes a typed action, where actor and subject meet purpose, where policy sees fresh state, and where an effect is accepted only after evidence closes the requested postcondition.

The architecture should keep ten concepts separate: intent, identity, world state, permitted context, model proposal, authority, typed action, evidence and receipts, verified outcome, and release or recovery. Calling all of them “context” or “memory” hides who may change each one and what makes it authoritative.

The flow is deliberately asymmetric. The model may propose. The protocol may transport. The authority kernel decides. The executor effects. The verifier accepts or disputes the claimed outcome. A human participates where ambiguity, policy or irreversibility requires judgement, not as a decorative approval button on every low-risk call.

In a configured payment flow, the A2A adapter first receives the task and preserves its protocol identity. A compiler then rejects prose-only action semantics and produces the payment contract shown earlier. The fresh-state reader obtains the invoice version, approval, beneficiary status and limits from authoritative systems. The authority kernel evaluates policy and emits a narrow decision receipt. The commit gate verifies that the action digest and resource version still match, then invokes the MCP-exposed tool with a domain idempotency key. After execution, the evidence ledger records both the tool result and downstream reference. Only the readback of the authoritative payment state releases the task as operationally complete.

The pre-effect decision receipt

A useful decision receipt is short lived and narrow. It binds at least the actor, subject, purpose, action type, normalised parameters or their digest, resource version, policy version, decision time, expiry and required confirmation state. It is not a reusable bearer of general permission. The executor rejects a receipt if the resource version or action digest differs.

NIST’s zero trust architecture separates policy decision and policy enforcement roles and removes implicit trust based on network location.¹³ The agentic extension is to make the policy decision action-specific and temporally adjacent to effect. Authentication performed when a session begins is helpful, but a long-running agent task can outlive the facts under which access was granted.

Human confirmation is one possible policy input, not automatic semantic closure. A confirmation screen that says “allow tool call” hides the consequence. A useful confirmation names the subject, purpose, amount, beneficiary, irreversibility, source of the facts and what will happen next. Repeated low-information prompts create ceremonial clicking. The boundary should require human judgement only where it changes the decision and should make that decision legible.

The effect receipt is not the verdict

The executor should return an effect receipt: operation identifier, committed resource version, timestamp, downstream reference and any partial-effect markers. That receipt is evidence from the actor that performed the operation. It is not independent proof.

The RATS architecture makes a useful structural distinction between Evidence, a Verifier’s appraisal, an Attestation Result and a Relying Party’s decision.¹⁴ The same discipline applies here without claiming that business readback is remote attestation. The executor reports. A verifier appraises evidence through a separate route. The application decides whether the evidence is sufficient to release the workflow.

What makes a verifier meaningfully different

Independence does not require a separate company or a second language model. It requires a failure path that is not identical to the executor’s claim. Reading the same cached response through another service adds little. Asking a second model to interpret the same receipt may reproduce the same omission. A stronger verifier reads an authoritative ledger, resource version or downstream status through a separately controlled interface and compares the observation with the expected postcondition.

Independence is relative to the threat and failure model. A separate database replica may protect against an application-process crash but not against a bad source transaction copied to every replica. A signed effect receipt may protect against tampering but not against a truthful receipt for the wrong beneficiary. A human review may catch semantic mismatch but fail under volume or poor presentation. The obligation profile should therefore name the rival failure the verifier is intended to break. Verification is different-path evidence, rather than only repeated agreement.

Unknown outcome is a state, not an error message

The hardest case is a lost response after commit. The client times out. Retrying may duplicate the effect; abandoning may leave an unpaid obligation. A generic “failed” label destroys the information needed for safe recovery.

Retry is a business decision disguised as a transport reaction. Safe retry requires a stable operation identity, payload binding, retained idempotency record and evidence that the prior effect did not occur. Otherwise the system should reconcile, compensate or escalate.

The adversarial path: purpose laundering

Protocols can be individually sound while composition is unsafe. The MCP security guidance describes confused-deputy risks when tokens are passed to downstream services without validating the intended audience. Agent chains add a semantic version: a broad permission can be repeatedly rephrased until the last agent performs an action never approved at the start.

The mitigation is a delegation compiler, not a longer prompt. Each hop receives a narrow capability whose action types and maximum effects are explicit, expiring and revocable. The application boundary compares the compiled capability with the final typed action. If the final action is not a refinement of the original purpose, execution stops or returns for confirmation.