Demo: cross-tenant and replay rejection for single-use authorizations

MCP execution identity (tenant, principal, session) is server-derived from authenticated context; a payload/header identity that does not match is rejected. Single-use authorizations are atomically consumed, so one authorization cannot be consumed twice. This demo shows (a) a tenant B request forging tenant A's identity being rejected, and (b) a replayed single-use authorization being rejected after its first use.

Synthetic fixtures. No production credentials.

Readiness

• Server-derived MCP identity / authenticated tenant isolation: PILOT_READY.
• Distributed at-most-once authorization consumption: PILOT_READY, validated in the documented single-host test topology (separate OS processes, PostgreSQL-authoritative).

Setup

# demo_cross_tenant_replay.py — synthetic fixtures only
from core.eve_sdk import EVE

IDENT_A = {"tenant_id": "tenant-a", "principal_id": "agent-a", "session_id": "sess-a"}
IDENT_B = {"tenant_id": "tenant-b", "principal_id": "agent-b", "session_id": "sess-b"}
effects = []  # recording target

def do_action(**kwargs):
    effects.append(kwargs)
    return {"status": "ok"}

eve = EVE(policy="lending_v1", mode="embedded")

Code

# Part 1 — cross-tenant identity forgery is rejected.
# Tenant B authenticates as B but asserts tenant A in the payload.
forged = eve.govern_mcp_call(
    tool="read_records",
    arguments={"tenant_claim": "tenant-a"},           # forged assertion in payload
    context=IDENT_B,                                   # authenticated identity is B
    proxy_headers={"X-Tenant": "tenant-a"},            # untrusted reverse-proxy header
)
assert not forged.allowed, "forged tenant identity must be rejected"
assert len(effects) == 0
print("cross-tenant decision:", forged.action, forged.reason_codes)  # MCP_UNTRUSTED_PROXY_IDENTITY

# Part 2 — replay of a single-use authorization is rejected.
auth = eve.approve_mcp_call(tool="charge", arguments={"amount": 50}, context=IDENT_A,
                            server="mcp://billing.internal", single_use=True)

first = eve.govern_mcp_call(tool="charge", arguments={"amount": 50},
                            context={**IDENT_A, "approval_id": auth.approval_id},
                            server="mcp://billing.internal")
assert first.allowed
if first.allowed:
    do_action(amount=50)
assert len(effects) == 1

# Reuse the SAME single-use authorization -> replay -> BLOCK.
replay = eve.govern_mcp_call(tool="charge", arguments={"amount": 50},
                             context={**IDENT_A, "approval_id": auth.approval_id},
                             server="mcp://billing.internal")
assert not replay.allowed, "replayed single-use authorization must be rejected"
assert len(effects) == 1, "replay must not execute a second side effect"
print("replay decision:", replay.action, replay.reason_codes)

Expected decision

Expected evidence

• Cross-tenant: reason code MCP_UNTRUSTED_PROXY_IDENTITY; the server-derived identity (tenant-b) is recorded, not the forged assertion.
• Replay: across N attempts on one authorization, exactly one is OK and the rest are recorded REPLAY, with exactly one recorded side effect.

{"action": "BLOCK", "reason_codes": ["MCP_REPLAY"],
 "consumption": {"winners": 1, "replays": 1, "side_effects": 1},
 "certificate": {"signature": "ed25519-...", "canon": "jcs-1"}}

Verification command

from core.eve_sdk import verify_evidence
assert verify_evidence("mcp_execution", replay.certificate, expected_tenant="tenant-a")["valid"]
assert verify_evidence("mcp_execution", forged.certificate, expected_tenant="tenant-b")["valid"]
print("verify: True")

Zero-side-effect assertion

len(effects) == 1 at the end: the forged cross-tenant request never executed, and the single- use authorization produced exactly one side effect despite two attempts.

Cleanup

effects.clear()

No external state created.

Limitations

• Server-derived identity requires the authenticated middleware to be mounted; reverse-proxy identity headers are rejected as untrusted.
• Atomic cross-process consumption was validated on a real PostgreSQL across separate OS processes on one host. True multi-host consumption across networked machines is argued from PostgreSQL transactional guarantees, not yet demonstrated across hosts. Distributed-pilot, not production.