Architecture and Trust Boundaries

Architecture and Trust Boundaries

Reviewer-oriented flow

flowchart LR
    A[Agent or workload\nrequest producer] --> B[Effect-boundary\ninterceptor]
    B --> C[Canonicalizer]
    C --> D[action_digest engine]
    D --> E[Verifier]
    R[PermitReceipt and\nauthenticity evidence] --> E
    P[Policy digest / epoch] --> E
    S[Status, revocation,\nand recency evidence] --> E
    X[Explicit context and\nanti-replay state] --> E
    E -->|all required checks pass| L[ALLOW decision record]
    E -->|missing, stale, mismatch,\nreplay, malformed, unsupported| N[DENY + reason]
    L --> F[Optional downstream\ncapability verifier]
    F -->|valid and bound| G[Synthetic provider\nadapter commit]
    F -->|absent, expired, replayed,\naudience-invalid, mismatched| N
    E --> H[Audit logger /\nevidence references]
    F --> H

Loading

Components

Component	Responsibility	Reviewer focus
Request producer	Proposes an effect; may be untrusted or compromised.	No security conclusion should depend on the producer explaining benign intent.
Effect-boundary interceptor	Captures the proposed effect before commitment.	Are all effect-bearing paths covered? What prevents bypass?
Canonicalizer	Produces deterministic bytes for all effect-relevant fields.	Are types, encodings, duplicate keys, defaults, and omitted fields unambiguous?
Digest engine	Computes the action binding.	Is the digest profile identified and collision-resistant for the use?
PermitReceipt handler	Parses and validates the authorization artifact and profiles.	Are unknown, malformed, or unsupported values rejected?
Verifier	Applies policy, epoch, scope, time, status, issuer, replay, and profile checks.	Is every authorization-critical failure fail closed?
Policy/epoch source	Supplies the policy state applicable to the attempt.	Can rollback, ambiguity, or stale caches produce ALLOW?
Status/revocation source	Supplies current-enough status evidence.	Are recency and unavailable-state semantics explicit?
Anti-replay state	Prevents reuse and race-driven double use.	Are reservations transactional and bound to the active receipt/effect?
Audit logger	Emits reproducible decision records and evidence references.	Are records useful without leaking secrets or personal data?
Downstream verifier	Optionally enforces a second gate at the destination.	Is derived evidence audience-, digest-, epoch-, time-, and replay-bound?
Provider adapter	Represents the final synthetic effect commit.	Does it reject direct bypass lacking gate evidence?

Trust boundaries

Boundary 1 — request producer to interceptor

The request producer is not trusted to self-authorize. Prompts, retrieved content, tool arguments, scheduled jobs, plugins, and background triggers may be adversarial.

Boundary 2 — raw request to canonical representation

Canonicalization is security-critical. Every field that can materially change the effect must be represented deterministically. A profile that omits a meaningful field cannot claim exact-effect binding for that field.

Boundary 3 — receipt and evidence to verifier

Parsing and schema validation must be total and fail closed. Authenticity, policy, status, and anti-replay evidence require explicit profiles and trust configuration.

Boundary 4 — local ALLOW to downstream commit

For high-risk effects, dual enforcement is preferable: local verification yields a decision receipt or capability bound to the action digest, audience, policy, epoch, validity, and replay material; the downstream boundary independently rejects absent or mismatched evidence.

Boundary 5 — audit output

Decision evidence must support reproduction while minimizing disclosure. Production credentials, customer data, regulated data, raw payment data, and sensitive internal mappings do not belong in this public evaluation artifact or public issues.

Repository map

Path	Role
orprg_eval/	Core public evaluation model and verifier behavior.
evaluation_vectors/	Deterministic positive and fail-closed negative vectors.
ietf126/	Small reviewer packet, independent recomputation, independent crypto checks, and results.
schemas/ and schema-specific directories	Public schema and profile material.
attestations/	Supply-chain and release evidence.
tools/	Release, manifest, metadata, validation, and QA helpers.
tests/	Strict automated test suite.
paygate_* and policy_paygate_domain/	Optional provider-neutral synthetic agentic-commerce profile; not the domain-neutral core.
docs/ and GLOSSARY.md	Canonical boundary, release, reviewer, and terminology documentation.

Deployment claim boundary

A correct verifier is necessary but not sufficient for production non-bypassability. A production claim would also require complete effect-path inventory, enforced routing, hardened roots of trust, durable and consistent replay state, issuer and key lifecycle, status availability semantics, policy governance, observability, incident response, and operational validation. Those claims are outside this public evaluation artifact.