Where should deterministic host-authority decisions and receipts fit in MCP? #3202

Overlap correction after reading recent Security IG context: two active SEP PRs are closer than my original post made explicit. SEP-3004 defines a tamper-evident audit-record contract and published vectors; SEP-3140 covers signed/versioned capability declarations and trust labels.

That narrows the possible AUEC contribution further: a host-owned per-action authority decision could, at most, consume authenticated declarations and compose with an existing audit-record format, rather than propose either generic primitive. I have updated my private routing notes accordingly. No SEP or adoption request is being made.

AI assistance disclosure: Codex assisted with this clarification; I reviewed it and remain responsible for the content.

The follow-up narrowing this against SEP-3004 and SEP-3140 is the right move — most of what would otherwise sprawl here is already scoped in those two.

One distinction that still looks open in both: where the decision is made and where the receipt is produced don't have to be the same component. A host can be authoritative for the decision while the record is emitted at the boundary the action actually crossed, which keeps the evidence close to the thing that happened rather than close to the policy engine. That matters for your intersection step specifically — the interesting record isn't the authority that was granted, it's the delta between what was requested and what was allowed.

The other half is what the record has to carry to be worth anything outside the system. Which policy version was in force, what identity the call was made under, and what the decision inputs were, not just the verdict. "Allowed" without the basis is a log line with extra steps, because the question that arrives later is always why, not whether. If your prototype already emits the inputs, that's a concrete contribution to the SEP-3004 contract rather than a competing format.

One practical note: SEP-3004 is open and still listed as needing a sponsor. If you have a working implementation and vectors it disagrees with, that route is probably more direct than a separate track.

Routing feedback, since that is what you asked for, plus one pointer correction.

The correction first. The opening post cites "signed access-decision receipts discussed in Discussion #2462." #2462 is "MCP Server Discovery via mcp:// — IETF Draft published, looking to coordinate" (Ideas-General, closed 2026-03-26) — server discovery, not receipts. Worth fixing before anyone follows the citation, since it is the only pointer in your list that does not resolve to the thing it names.

On routing. Your own narrowing is right, and @grabdoc's distinction sharpens it further: the decision site and the record site need not be the same component. That splits your AUEC work cleanly across the two SEPs you already identified, rather than needing a home of its own.

• The decision — intersecting requested against host-allowed operations, and keeping probabilistic claim values from becoming action authority — is host-side policy. SEP-2624 gives it an enforcement point; nothing about it needs new wire format.
• The record of that decision already has a registered home. SEP-3004 §2.2 registers caller-governance in full, and a per-action authority decision is an extension payload inside that registration, not a new primitive.

Which makes the interesting artifact narrower than a receipt: it is the delta between what was requested and what was allowed. A record of what executed answers "what happened"; the delta answers "what was asked for and refused", which is the part no downstream reader can reconstruct from the executed record alone. If AUEC contributes one thing to caller-governance, that asymmetry is the candidate.

One property worth carrying into whichever home it lands in, since it is cheap to state now and expensive to retrofit: a decision record is produced by the party whose authority it describes. That is fine for debugging and insufficient the moment the record is offered to anyone with a reason to doubt the producer — which is when authority decisions actually get read. SEP-3004's thread has been working exactly that boundary this week; worth reading before you pick a shape.

Disclosure: drafted with AI assistance, human-reviewed, consistent with the convention in the adjacent SEP threads. — Tersign

Thanks @grabdoc and @wowlegend — this resolves the routing question much more cleanly. I have corrected the erroneous #2462 pointer in the opening post.

The direction I am taking is now deliberately narrow:

• SEP-3140-style authenticated declarations are decision inputs, not authority;
• a host-side validator/interceptor is the decision point;
• SEP-3004 remains the record construction and caller-governance home;
• AUEC's candidate contribution is the deterministic requested→effective authority delta and its decision basis, not another receipt or wire primitive.

The current experimental spike already keeps the decision host-owned, ignores caller-supplied audit data as authority, and maps the terminal allow/deny result to a SEP-3004-shaped record. It does not yet serialize the full requested, host-allowed and effective sets, policy revision, separate decision/emission identities, or a commitment to all decision inputs.

I am updating that spike to separate the decision authority from the boundary emitter, reproduce SEP-3004's published vectors unchanged, and add negative vectors for delta inconsistency, policy/principal mismatch, action mutation and self-attested producer limits. If the current contract already carries the case cleanly, the result will be an implementation/vector contribution. I will only suggest minimal optional caller-governance fields if a concrete vector shows that the basis or delta cannot otherwise be represented.

AI-assistance disclosure: OpenAI ChatGPT and Codex assisted with analysis, implementation planning and drafting. I reviewed this response and remain responsible for it.

@grabdoc's distinction — that the decision site and the record site need not be the same component — matches what we ran into building the effect side of this, and there's a consequence worth making explicit in whatever record format wins.

The decision and the effect are separated by time and a network call, and that gap is where the hard case lives. A host can authorize an action deterministically and still not know whether it happened: the call goes out, the effect lands, the response is lost. At that moment the honest record has three possible states, not two —

• authorized, confirmed to have occurred (the system of record says so)
• authorized, did not occur (asked, genuinely absent)
• authorized, outcome unknown (we could not find out)

The third is the one that gets silently folded into the second, and that collapse is exactly how a retried timeout becomes a duplicate charge. If a decision receipt only carries the authority basis and not the disposition of the effect, then at audit time "the host authorized this" reads as "this happened", which is a stronger claim than the evidence supports. I'd argue the record should be able to say "authorized, outcome unverified" as a first-class value rather than as an absence.

That also sharpens the placement question. A record emitted at the boundary the action crossed (grabdoc's framing) is the only place that can later be reconciled — it's where the provider's own handle for the effect exists. A record produced at the policy engine can attest to the decision faithfully and structurally cannot attest to the outcome. Both are useful; conflating them at read time is the risk.

One narrow, concrete suggestion, offered without any claim about where it belongs in the SEP landscape: whatever the record carries, keeping authority basis and effect disposition as separate fields — rather than one status — makes the difference between "we were allowed to" and "it happened" impossible to lose. We learned that the expensive way; our own logs once reported sends as successful that had verifiably never left, because the field being read was our claim about ourselves rather than the provider's record.

No position on routing or SEP overlap — deferring to your narrowing and to @wowlegend's read on that.