Concepts and Threat Model

Concepts and Threat Model

Why permit-before-commit exists

An agent, model, scheduled workload, plugin, or compromised application path may produce a request that changes external state or discloses information. Authorization checked only when a session begins or when a prompt enters an application can be stale, too broad, or bypassed by the time a concrete effect is committed.

Permit-before-commit moves the decisive check to the effect boundary: capture the proposed effect, canonicalize the effect-relevant fields, bind them to a digest, verify current authorization evidence, and commit only on ALLOW.

Core terms

Term	Meaning in this evaluation model
Protected external effect	An operation crossing an execution boundary that may disclose information, change state, invoke privilege, release output, delegate authority, or change future effect semantics.
Effect boundary	The logical or physical point at which the external effect would be committed.
Permit-before-commit	The control-flow posture in which verification succeeds before the protected effect is committed.
PermitReceipt	A machine-verifiable authorization artifact binding the request to policy, epoch, validity, scope, action binding, authenticity, and required status evidence.
Canonical request representation	A deterministic representation containing the effect-relevant request fields selected by a profile.
action_digest	A digest over the canonical request representation, used to bind authorization to the exact attempted effect.
Policy epoch / digest	The version or cryptographic commitment identifying the policy state applicable to the effect.
Scope	Constraints such as effect type, interface, target, tenant, purpose, audience, jurisdiction, identity, operation, or budget.
Status / recency evidence	Evidence showing that authorization, revocation, issuer, or policy state is current enough for this attempt.
Anti-replay state	A nonce, sequence, counter, reservation, or equivalent mechanism preventing reuse outside the authorized attempt.
Verifier	The component that evaluates the request, receipt, policy, status, context, and replay state and returns ALLOW or DENY.
Fail closed	Missing, stale, ambiguous, conflicting, malformed, revoked, replayed, unsupported, or unverifiable critical evidence produces DENY.

Exact-effect example

Assume a receipt authorizes:

operation: transfer
amount: 25.00
currency: EUR
target: merchant-A
purpose: order-481
policy_epoch: 42
audience: synthetic-provider

A request for 25.01 EUR, a different merchant, a different purpose, a stale epoch, a different audience, or a replayed nonce must not inherit authorization merely because it “looks similar.” The canonicalized effect fields and receipt binding determine whether it is the same authorized effect.

Threats the model is intended to expose or deny

• action substitution after authorization;
• stale policy or policy rollback;
• expired validity;
• scope, target, audience, tenant, purpose, jurisdiction, operation, or budget mismatch;
• missing or stale revocation/status evidence;
• receipt, carrier, or evidence tampering;
• receipt or capability replay;
• malformed or ambiguously encoded input;
• duplicate JSON keys and unsupported profiles;
• conflicting authorization-critical context;
• direct access to an external interface that bypasses the intended gate.

Protected effect families

Profiles may be defined for:

• network transmission and data egress;
• data access and retrieval;
• tool calls, privileged APIs, transactions, and scheduler operations;
• signing, decryption, unwrapping, and key release;
• inter-agent messages and representation negotiation;
• plugin, model, policy, extension, or configuration updates; and
• protected output release.

Every effect family needs an explicit canonicalization and verification profile. A generic receipt must not silently authorize fields that the profile failed to bind.

Explicit non-goals

This evaluation artifact does not, by itself:

• make the model honest or aligned;
• prove that a production interceptor is non-bypassable;
• prove policy correctness;
• establish trust anchors, issuer governance, or production revocation operations;
• define a complete policy language or mandatory universal wire format;
• replace downstream authorization, wallet, payment, identity, or settlement systems;
• provide certification, conformance, compliance, or IETF endorsement; or
• grant production, commercial, trademark, or patent rights.

Read Architecture and Trust Boundaries next.