PIC Sandboxed Execution

Introduction This section is non-normative. It introduces the three concepts this specification builds on, and the single idea that connects them: PIC carries PIC.

= 1 independent PIC continuities evaluated together SANDBOXED EXECUTION ------------------- an outer PIC continuity carrying a Composition Collection ]]> The whole construction reduces to one picture:

The outer continuity applies PIC recursively to the execution that validates and controls the inner execution.

PIC Continuity

A PIC Continuity is a single-root PIC execution in which every non-root continuity advancement continues exactly one predecessor under PoR, and authority remains bounded by the root authority context.

one trusted root authority context; every later continuity advancement continues exactly one predecessor, witnessed by PoR; non-expansion at every hop, so authority only narrows; no authority is imported from another lineage; physical executor behavior is outside the protocol guarantee.

The construction — root representation, continuity advancement, Prover, and Verifier — is defined by the PIC Prover and Verifier Specification; revocation by the PIC Revocation Specification; the formal model and proofs by the PIC Model [1]. This document restates none of them.

Composition Collection

A Composition Collection is a bounded collection of one or more independently verifiable PIC continuities evaluated together for one sandboxed or enforced execution, without merging their authorities.

it carries n >= 1 independent PIC continuities; each continuity remains independently verifiable; it has no combined authority of its own; it is the execution input bound to the outer ENFORCE advancement (Section 2.4).

A composition member is an independently verifiable PIC continuity representation carried within a Composition Collection for joint evaluation in one exact proposed transition. A composition member is not an execution step, workflow stage, route segment, child continuity, subordinate continuity, additional outer predecessor, or authority fragment. A Sandboxed Execution profile layered on a PIC continuity profile defines the independently verifiable representation of each Composition Collection member and the exact binding of that collection to the outer execution. The Sandboxed Execution does not execute on or through its composition members. It carries and evaluates their joint participation while preserving each member's independently rooted PIC continuity state, revocation coordinates, position, effective authority, and execution contract. A Composition Collection is structurally composed of composition members. The outer Sandboxed Execution remains a separate PIC continuity with its own root, predecessor path, authority { ENFORCE }, execution contract, continuation semantics, and revocation coordinates. The existence of composition members motivates the execution being evaluated, but the outer continuity does not derive authority from them. The term "collection member" describes membership in the Composition Collection. It does not imply that the outer continuity is composed from, descended from, authorized by, or structurally continued from the composition members. The outer continuity is rooted independently by an authorized sandbox origin; the composition members define the authenticated execution inputs being evaluated, not the authority source of the outer continuity. The collection members are constitutive of the evaluated inner Composition Collection. Without at least one composition member, there is no Composition Collection and therefore no inner execution for this Sandboxed Execution profile to govern. The Sandboxed Execution exists to validate and control the proposed joint participation of its collection members; in that functional sense, the composition members define the subject matter and purpose of the outer execution. This dependency is semantic and structural, not an authority derivation. The outer continuity is not created from the authority of the composition members, is not their successor, and is not their union. It is independently rooted by an authorized sandbox origin and carries only its own authority, { ENFORCE }.

Removing all collection members removes the execution subject of the Sandboxed Execution; it does not attenuate the outer authority or transform the outer continuity into an empty authority container. A Composition Collection contains at least one composition member; an empty collection-member set represents no Composition Collection to evaluate and is invalid.

Sandboxed Execution A Sandboxed Execution is a multi-hop outer PIC execution. Its executors are guardrails, and each non-root guardrail advancement continues exactly one predecessor under the ordinary PIC Proof of Relationship rules:

The guardrails are the executors of the outer PIC continuity. They are not a parallel guardrail chain and do not use a separate continuity model. The executor at outer position n produces the profile-defined outer advancement; the executor at position n+1 verifies the resulting state as its received predecessor. Every non-root advancement continues exactly one predecessor in its own continuity, and composition members are never additional outer predecessors. Each guardrail: receives an ordinary outer continuity state bound to a Composition Collection; verifies the outer PIC continuation; verifies every composition member; applies the enforcement function; on permit, produces the next ordinary outer continuity advancement; on deny, produces no authorizing continuation for that crossing.

A guardrail is an executor of a Sandboxed Execution: it verifies the outer continuation, verifies the bound inner execution, applies the enforcement function, and, on permit, produces the next ordinary outer continuity advancement.

An execution is sandboxed not because a physical boundary forced guardrail invocation, but because the next conforming guardrail accepts and continues only valid outer continuity state.

The execution is sandboxed because it can continue as valid PIC state only through valid guardrail advancements of the outer continuity.

This specification does not prevent a compromised or non-conforming executor from attempting local physical actions outside the signed execution.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [2] [3] when, and only when, they appear in all capitals in normative text. The sections defining Composition Collection binding, its canonical binding, sandbox origination, the Guardrail Prover and Verifier profile, the operation profile, Acceptance, Bypass rejection behavior, materializing-guardrail requirements, and Recursion resource limits are normative. The Abstract, Introduction, explanatory diagrams, examples, deployment comparisons, the service-mesh explanation, and Security Boundary explanations are non-normative unless a requirement is explicitly expressed using BCP 14 keywords.

Recursive Execution Model

Outer and Inner Execution

The outer execution is an ordinary PIC Continuity with its own trusted root, authority context, PoR-governed advancements, execution contract, continuation semantics, and revocation coordinates. Every composition member independently has the same PIC continuity structure. The outer execution does not absorb the inner continuities. It carries them as execution inputs and continues on its own authority, ENFORCE.

PIC Carrying PIC (PIC of PIC) The inner execution is already represented by PIC. The execution that validates and controls it is therefore represented by another ordinary PIC continuity. This is PIC carrying PIC — informally, PIC of PIC. The guardrail process must itself be controlled, across guardrails not yet known, so the controlled Composition Collection becomes the authenticated subject of that outer continuity — and the same construction can be nested again.

advancement n --> state n --> advancement n+1 | +-- exact Composition Collection binding | +-- independently verified member continuities ]]>

PIC does not stop at protecting application execution. It can protect the execution that protects application execution.

Recursive Composition Collection Safety Ordinary PIC prevents authority originating in one PIC Continuity from being represented as a valid continuation of another. Composition Collection Execution preserves this property by carrying independently valid continuities as separate composition members rather than creating their authority union. Sandboxed Execution applies PIC recursively to the process that evaluates their joint participation. The outer continuity carries only ENFORCE; every composition member retains its own root-bounded authority.

Policy may permit composition member A and composition member B to participate in one concrete transition. Policy does not create { READ-ALL, BACKUP } as a new continuity authority. Both of the following are rejected by ordinary PIC origin binding and non-expansion:

PIC eliminates cross-lineage authority composition from valid PIC state. Sandboxed Execution recursively protects the decision that determines whether independently valid continuities may participate in one exact transition. At every recursive level, the local continuity preserves its own root-bounded authority, while nested executions are treated only as independently verified execution inputs. This is a guarantee about valid and accepted PIC state. It does not prove that a compromised executor cannot perform an unauthorized physical action locally.

Composition Collection Binding An ENFORCE advancement in a Sandboxed Execution MUST cryptographically bind the exact Composition Collection that the guardrail evaluated. This document uses Composition Collection and Composition Collection commitment as semantic names for that bound object and commitment. Their wire location, canonicalization, and serialization are defined by the selected Sandboxed Execution profile; they are not generic mandatory fields of every PIC continuity representation. The bound Composition Collection carries one bounded list of independently verifiable PIC continuity inputs. A Sandboxed Execution profile using the current Profile 0.2 artifact family may represent each member with a PIC Token JWT carrying a PIC Continuity COSE, but the base Profile 0.2 artifact profile does not by itself define Composition Collection processing. The following is a non-normative semantic view, not a wire schema and not a set of generic PIC continuity member names:

role: context: destination: ... requestSetDigest: sha256:... payloadDigest: sha256:... freshness: ... ]]> Semantics: the exact Composition Collection is authenticated or cryptographically bound by the outer continuity advancement representing the ENFORCE crossing; every composition member is independently verifiable under its own selected PIC continuity representation; each composition member keeps its own root, predecessor relation, authority context, and revocation coordinates; composition members are never merged; the list is bounded by the profile; a composition member MAY itself be a Sandboxed Execution; recursion has no special terminal depth in the model; implementations MAY impose resource and maximum-depth limits; these are implementation and profile limits, not PIC-semantic changes. The term "collection member" does not require the complete historical path to be embedded; the selected validation profile determines the independently verifiable representation for each member continuity. The Composition Collection binding MUST NOT alter the outer predecessor reference, create additional predecessors, enter the outer authority domain, import authority from composition members, or replace PoR, any composition member's authentication, or any composition member's validation. Exactness. The outer request binding commits to the complete presented Composition Collection. The Verifier reconstructs the collection-member set and context from the presented objects and recomputes every supplied digest; an added, removed, or substituted composition member causes rejection.

Exactness applies to the authenticated Composition Collection presented to the guardrail. Detecting inputs hidden before presentation requires a profile-defined authenticated input manifest or observation source.

Two distinct functions must not be confused:

For every non-root outer advancement that represents an ENFORCE crossing, the profile-defined request/execution binding MUST contain or cryptographically bind a commitment to the complete canonical Composition Collection. The binding includes at least the semantic values:

This profile does not redefine the base request format (PIC Prover and Verifier Specification, Section 2.3); it requires an ENFORCE-specific request binding. The authenticated continuity advancement protects or binds the complete Composition Collection, and the request commitment pins the concrete ENFORCE operation to that exact inner execution under the profile-defined executed-vs-bound rule. A Composition Collection commitment is mandatory in every non-root ENFORCE advancement and is computed over the selected profile's canonical Composition Collection representation:

The selected profile MUST define the concrete field placement, canonical encoding, hash suite, domain separator, collection-member ordering and whether it is semantic, duplicate-collection-member handling, maximum collection-member count, treatment of optional fields, normalization rules, and included context fields. requestDigest and payloadDigest MAY bind additional material, but MUST NOT replace the Composition Collection commitment. The Verifier MUST reject a missing digest, an unknown canonicalization profile, a non-canonical field, a digest mismatch, an added, removed, or substituted composition member, a forbidden duplicate composition member, a semantically significant reordering, or a mismatch between the presented context and the committed context. The decision is recorded in the profile-defined request/execution binding as permit or deny or as an equivalent profile-defined value. It records the result for the exact Composition Collection, destination, request, payload, policy, committed inputs, semantic profile, and crossing context bound by the same outer request. A permit MAY appear in an authorizing outer advancement; a deny MUST NOT authorize continuation. A profile MAY record a denial for audit, but MUST NOT introduce a denial artifact that is interpreted as permission to cross the governed boundary. For every non-root ENFORCE advancement, the operation, Composition Collection commitment, and enforcement result are mandatory semantic values; other request fields follow the selected profile's optionality rules. An audit representation of deny is not an execution-authorizing continuation. Unless a future profile explicitly defines denial-state progression, a denial MUST NOT be assumed to consume the predecessor continuation challenge, advance the authorizing outer continuity, or create an executable successor. The interoperable denial-recording format is out of scope for this revision. Evolution across hops. The outer continuity state at position n is bound to the exact inner execution evaluated by guardrail n. The next guardrail receives that authenticated state and MAY continue the same inner execution or evaluate a profile-valid successor Composition Collection.

A successor outer advancement MUST NOT silently mutate the Composition Collection. If the proposed inner execution changes, the successor request MUST bind the complete new Composition Collection, and every changed composition member MUST independently validate as required by its own PIC continuity and the selected profile.

An unchanged composition member may be represented unchanged. A composition member may continue only through its own valid PIC continuity advancement. Removing a composition member is not an attenuation of the outer authority; it is a change to the execution input and MUST be visible in the authenticated request binding. Inner authority is never silently added, removed, replaced, or imported. The recursion is structural, not authority composition:

Originating the Sandboxed Execution Three roles are distinct:

A Sandboxed Execution MUST begin with an ordinary trusted root continuity state, created by an authorized sandbox origin. The proposing executor MAY also be the sandbox origin only when the applicable origination policy explicitly authorizes it to root that outer continuity. Possession of the inner continuities does not authorize creation of the outer root, and the proposed first guardrail MUST NOT create its own outer root. The authorized sandbox origin may be the protected application, policy governance, a deployment authority, or another origin explicitly authorized by the applicable origin policy. No special guardrail key or separate guardrail authority is required. The selected Sandboxed Execution profile MUST define how authorization to create the outer root is represented and verified. A valid root signature identifies who created the root representation; it is not, by itself, proof that the issuer was authorized to originate a Sandboxed Execution under the applicable profile. The authorization evidence MAY be an origin trust policy, an authenticated application or deployment configuration, a signed origination grant, a policy-governance authorization, an attested origin role, or another profile-defined verifiable mechanism; this revision mandates none. AuthorizedSandboxOrigin(root) means the issuer of the outer root is authorized, under the selected Sandboxed Execution profile and receiving deployment policy, to originate an outer continuity with the presented ENFORCE authority and execution contract. The outer root establishes the outer authority and the future guardrail contract; it does not evaluate the inner execution. It is an ordinary PIC root — no predecessor, no PoR, authenticated by its authorized origin. The following is a semantic illustration of the authority and bootstrap requirements of the outer root. It is not the Profile 0.2 logical PCA schema, is not the Profile 0.2 PIC PCA COSE wire representation, and is not the Indexed Authority Map representation.

In a Sandboxed Execution realization using Profile 0.2 artifacts, the outer root is represented by a trusted PIC PCA COSE checkpoint, and the bootstrap challenge is carried in that PIC PCA COSE. The first guardrail decision appears in the first applicable PIC Continuity Transition COSE proposed for the outer continuity. The outer root MAY carry an origin-level commitment identifying the execution proposal, but it MUST NOT contain a guardrail verdict. The first guardrail receives the outer root and the proposed Composition Collection, proves conformance to the root execution contract, validates every composition member, applies the enforcement function, and — on permit — produces the first ordinary outer continuity advancement.

The complete first sequence:

The first outer advancement, not the outer root, is the first outer state attributable to a guardrail decision. Subsequent guardrails produce subsequent ordinary continuity advancements.

Guardrail Prover and Verifier Profile A guardrail performs two nested verification levels over the existing ordinary PIC procedures, then — on permit — produces the next outer continuity advancement. It MUST perform the phases in order. Phase 1 — Outer PIC verification. The guardrail acts as an ordinary PIC Verifier for the outer execution: validate the outer predecessor continuity state; verify the profile-defined predecessor cryptographic reference and PoR; verify freshness or challenge continuity as defined by the selected profile; verify outer non-expansion; verify time, profile, and applicable revocation requirements; verify guardrail executor evidence and execution-contract conformance when required by the selected Sandboxed Execution profile or the underlying continuity profile; verify the materialized outer authority contains ENFORCE; verify the profile-defined outer request/execution binding operation is ENFORCE; recompute and verify the request commitment to the complete Composition Collection; verify the bound enforcement result is permit for an authorizing prior outer advancement. Phase 2 — Inner PIC verification. Only after Phase 1 succeeds, for every composition member: validate the composition member independently using its selected ordinary PIC validation profile; verify its root, immediate predecessor, or equivalent proof as required by that profile; verify artifact authentication, integrity, and PoR as required by that profile; verify predecessor binding where applicable; verify non-expansion; verify request/execution binding when required by that member's selected PIC continuity profile; verify executor evidence and execution-contract conformance when required by that member's selected PIC continuity profile; verify freshness and time as required by that profile; verify revocation coordinates and active revocation state when required or applicable under that profile. Any invalid outer check or composition member produces deny before policy evaluation. Phase 3 — Enforcement function. Over the validated inner execution and the exact crossing context, the guardrail evaluates the profile-defined enforcement function. A PDP is only one possible implementation.

The profile defines the required enforcement result and its signed inputs. It does not require a specific PDP, policy language, vendor, process boundary, or deployment topology.

Every collection-member-describing input used by the enforcement function MUST be cryptographically or operationally bound to the corresponding composition member by a mechanism not under the unilateral control of the proposing executor. This includes, when used, role, semantic scopes, labels, data classifications, tenant or security-domain claims, accountable-party claims, environment claims, application identity, purpose or intent metadata, policy-selection metadata, and translation or semantic-profile identifiers. Accepted binding mechanisms MAY include root-bound signed metadata, signed declarations from an accepted authority, trusted derivation from validated continuity contents, policy-controlled mappings, authenticated deployment configuration, attested execution context, verified external attributes, or profile-defined authenticated manifests. An untrusted executor's claim alone MUST NOT be sufficient as an enforcement input. The enforcement function MUST evaluate only inputs whose source, binding, interpretation profile, and integrity satisfy the selected Sandboxed Execution profile. An input required by policy that is unauthenticated, ambiguously bound, semantically unmapped, inconsistent with the presented continuity state, unavailable, or controlled only by the proposing executor MUST produce deny or indeterminate-deny. Failure, unavailable policy, indeterminate result, inconsistent semantic mapping, or missing committed inputs produce deny. Phase 4 — Outer proving. On permit, the guardrail produces or proposes the next ordinary outer continuity advancement under the standard PIC Prover procedure. It MUST: identify exactly one outer predecessor; produce valid PoR; retain or attenuate ENFORCE; preserve or strengthen the execution contract; bind the exact evaluated Composition Collection; bind its canonical digest in the request; bind the enforcement inputs and permit result; emit the next profile-defined challenge or freshness value when required; authenticate the complete advancement under the selected profile. No additional approval signature is created. The next guardrail repeats the same procedure — and that repetition is the sandbox. In a current Profile 0.2 / PIC-X realization, the guardrail or workload creates a workload-signed PIC Continuity Transition COSE, places it as the single transition in a workload-signed candidate PIC Continuity COSE, carries that candidate in a workload-signed candidate PIC Token JWT, and submits the candidate for settlement validation. The settlement authority validates the outer continuity, ENFORCE authority, Composition Collection commitment, PoR/key binding, predecessor hash over the current PIC PCA COSE checkpoint, challenge continuity, attenuation, revocation, and local/profile policy. On success, it issues the next settled outer PIC Token JWT carrying a settled PIC Continuity COSE with transitions = null. This is ordinary Profile 0.2 continuity advancement, not a sandbox-specific protocol.

Hop-specific result. An enforcement result is hop-specific. A permit in the outer advancement at position n applies only to the exact execution bound by that advancement: its Composition Collection, destination, requests, payload commitments, policy commitment, input commitment, semantic profile, and crossing context. It does not authorize position n+1, a later crossing, a changed destination, a changed payload, a changed policy, a modified Composition Collection, or any physical action not bound by the request.

Every later guardrail MUST verify the received outer continuity state, verify the exact Composition Collection, evaluate the enforcement function applicable to that hop, produce its own authenticated result, and produce a new ordinary outer advancement only on permit.

Operation Profile This revision uses one operation class, ENFORCE: it means: validate the bound Composition Collection, apply the enforcement function, and decide whether the outer execution may continue; it grants none of the authority of the composition members; it is subject to ordinary PIC non-expansion: the outer continuity MAY retain or attenuate it, never add broader operations. Future revisions MAY define additional recursive-control operation classes, using the same ordinary PIC continuity, PoR, and profile-extension model.

Acceptance Two checks are separate: ENFORCE must belong to the outer authority context, and the concrete executed request must be ENFORCE.

For every non-root outer advancement, both MUST hold. A conforming guardrail or receiving outer executor MUST accept the outer continuity only if:

For the outer root, ordinary root validation, the presence of ENFORCE in its root authority context, and the sandbox-origin authorization defined below apply; it has no PoR request. Origin authorization is part of acceptance:

ValidSandboxOrigin(outerRoot) is established according to the selected continuity-validation profile. A full-history Verifier may establish it directly; an incremental Verifier may rely on authenticated validation state, checkpoints, Trust Plane validation, an approved succinct proof, or another mechanism permitted by that profile. Not every incremental receiver carries the complete root representation. A receiving deployment MAY restrict the sandbox origins it accepts and MAY require a minimum outer execution contract. Such restrictions narrow acceptance; they do not create outer authority. ValidCompositionCollection means that the presented Composition Collection contains at least one composition member and every composition member validates independently under its own PIC continuity and the selected validation profile. Validation of one composition member does not validate another. A composition member is never an additional predecessor of the outer continuity. A composition member may itself be a Sandboxed Execution, enabling recursive composition to arbitrary finite depth. An empty collection-member set is invalid under this profile. ExactPresentedExecutionBinding means that the complete presented collection-member set and crossing context are reconstructed from the presented objects, every supplied digest is recomputed, and the result matches the signed outer request commitments under the exactness and canonical-binding rules of this specification.

This predicate covers the authenticated execution presented to the Verifier; detecting inputs hidden before presentation requires the profile-defined authenticated input manifest, observation source, attested context, or equivalent mechanism already described by this specification. The two predicates remain distinct:

The receiving component MUST recompute all digests and MUST reject: a missing Composition Collection binding; an invalid outer continuity; an invalid composition member; an added, removed, or substituted presented composition member; a mismatched request, destination, or payload; an invalid policy or input commitment; a non-permit decision; stale, replayed, or revoked state. This profile adds no second signature system: guardrail approval is the ordinary authentication of the outer continuity advancement, nothing else. Each permit is hop-specific: it authorizes only the exact crossing bound by its own outer advancement, never a later hop or a changed crossing.

Bypass A sender may physically present the inner execution without a valid outer continuation. The next conforming guardrail rejects it because the required Sandboxed Execution continuity is absent or invalid.

next conforming guardrail reject: no valid outer continuation ]]>

The failure is not prevented at the faulty hop; it is blocked at the next conforming one.

Non-PIC-Aware Target A non-PIC-aware target cannot verify the outer Sandboxed Execution. For such a target, the final hop of the Sandboxed Execution is the materializing guardrail — an ordinary executor of the outer continuity that performs the exact physical action permitted by its own bound outer request. It MUST follow the selected ordinary PIC advancement profile for the exact materialized action; it MUST NOT complete or mutate an already-authenticated advancement. The materializing guardrail: verifies its outer predecessor; verifies every composition member; evaluates the enforcement function; constructs the ordinary outer continuity advancement or advancement proposal required by the selected profile; binds the exact physical action, destination, payload, participants, policy inputs, and context; authenticates the complete advancement or proposal as required by the selected profile; follows any profile-required settlement or acceptance rules for treating the continuation as valid; performs exactly the bound physical action according to the selected materialization profile and its ordering rules. For current PIC Profile 0.2, the materializing guardrail or workload validates the outer predecessor, validates every Composition Collection member, evaluates enforcement, constructs and signs the PIC Continuity Transition COSE, constructs and signs the candidate PIC Continuity COSE, carries it in a signed candidate PIC Token JWT, and submits the candidate through the ordinary advancement flow. The settlement authority validates the candidate and transition and, on success, issues the next settled outer PIC Token JWT carrying a settled PIC Continuity COSE with transitions = null. This document does not define the exact temporal ordering between Profile 0.2 settlement and the final irreversible physical side effect against a non-PIC-aware target. That ordering is profile-defined or deployment-defined. After the decision, control of that concrete materialized target operation does not return to the proposing executor; this concerns the materialized operation, not ownership of unrelated application workflow.

The materializing guardrail is not a new trusted authority, a special continuity artifact type, a required service mesh, a universal gateway, or a protocol-level physical sandbox; it remains an ordinary executor of the outer PIC continuity. For a non-PIC-aware target, ensuring that the target cannot also be reached through unrelated credentials, alternate routes, direct network access, or other physical paths remains a deployment responsibility, addressed by the PIC Architecture and Deployment Specification. PIC determines whether an execution may continue as valid PIC state; network infrastructure may prevent ungoverned physical access. These are separate guarantees, and one does not replace the other.

Relationship to Service Meshes and Deployment Infrastructure A Sandboxed Execution does not require a service mesh, sidecar, proxy, gateway, network-interception layer, or physical sandbox. The validity of guardrail traversal derives from the outer PIC continuity: ordinary Proof of Relationship, exactly-one-predecessor continuity, non-expansion, the mandatory outer ENFORCE request/execution binding, profile-required executor evidence or conformance, applicable revocation checks, and verification by the next conforming outer executor. A service mesh MAY transport, route, encrypt, observe, load-balance, or operationally restrict a Sandboxed Execution. It is not the source of the execution's continuity, guardrail authorization, authority separation, or sandboxing property. PIC therefore assumes responsibility for the execution-continuity and guardrail-validity properties that would otherwise have to be trusted to interception infrastructure; the service mesh, when present, remains deployment infrastructure rather than a PIC security primitive.

A service mesh does not make invalid continuity state valid, does not replace PIC verification, and does not create a Sandboxed Execution merely by forcing traffic through a proxy. Conversely, PIC does not replace networking, transport confidentiality, availability engineering, service discovery, or physical path control. It is unnecessary only as the source of the cryptographic and continuity-based sandboxing guarantee.

A service mesh may carry the sandbox, but it is not the sandbox.

Consecutive Collusion A sender colluding with a receiving hop that deliberately ignores the Sandboxed Execution profile is a non-conforming or consecutive-collusion case under the PIC Prover and Verifier Specification. Detection beyond the colluding pair depends on the selected chain-validation profile and the authenticated history available to the later Verifier: a full-chain, Trust Plane, authenticated-checkpoint, or approved succinct-proof profile may detect the invalid prefix according to its guarantees, while an incremental Verifier without authenticated evidence of the earlier prefix has the consecutive-collusion limitation already documented by that specification (Section 6.8). Sandboxed Execution introduces no new failure class.

Recursion The model is recursively closed. No special root guardrail object exists, and no new trust primitive appears at deeper levels.

At every level: the same ordinary PIC continuity semantics are reused; the same PoR semantics are reused; the same non-expansion semantics are reused; validation recursively invokes the appropriate PIC Verifier profile; each level has exactly one predecessor in its own continuity; an inner continuity is never an additional predecessor of the outer continuity; no authority flows upward from inner continuities. At every recursive level the same separation holds: one predecessor in the local continuity, root-bounded authority, ordinary PoR, ordinary non-expansion, exact request binding, and independent revocation.

Nesting adds execution structure. It does not create authority inheritance between recursive levels. The model is recursively composable to arbitrary finite depth — not literal infinite execution. Implementations MUST bound maximum recursion depth, collection-member count, encoded size, and total validation work. Resource limits cause rejection or indeterminate-deny according to the profile; they do not change PIC semantics.

Security Boundary

Model Guarantee Within the accepted model: an outer hop without valid PoR cannot continue; an unauthorized guardrail cannot become a valid continuity advancement; the outer authority cannot expand beyond ENFORCE; an invalid inner continuity causes rejection; a different inner execution cannot be substituted without invalidating the authenticated binding; skipping guardrails cannot produce a valid outer continuation. This specification adds no independent trust primitive. The trusted elements remain those already required by the PIC Prover and Verifier model: Verifier correctness, origin trust boundaries, sandbox-origin authorization, attestation issuers, canonicalization and hash profiles, revocation-state authenticity and freshness, cryptographic primitives, and the physical correctness of any materializing implementation. Sandboxed Execution changes the anchor of enforcement, not the kind of trust assumed: enforcement is represented as an ordinary PIC continuation checked by the next conforming outer executor. Trust is not eliminated; no special trusted sandbox or independently recognized guardrail authority is added.

Implementation Failure The guarantee can fail physically if cryptographic primitives fail, keys or attestation issuers are compromised, a Verifier omits required checks, an executor performs a different physical action from the signed one, or canonicalization or digest construction is implemented incorrectly. These break the implementation or its assumptions, not the model.

Semantic Divergence The enforcement function may be incorrect, dishonest, or semantically divergent. Signing the policy identifier, version, input commitments, semantic profile, and result makes the decision attributable and checkable. PIC proves the continuity and integrity of that decision; it does not prove that a human policy or its interpretation is correct.

Model Summary

The result is recursive execution safety: independently originated authorities may participate in one evaluated transition without becoming one authority state, and the evaluation process itself continues only as valid PIC state. A service mesh may carry, observe, encrypt, or operationally restrict this execution, but it is not the source of its sandboxing property. Physical executor behavior, alternate physical paths, implementation failure, cryptographic compromise, unavailable authenticated history, and policy-semantic error remain at the stated boundaries of the model. Without at least one composition member, there is no inner Composition Collection for this profile to evaluate. This does not make the member continuities authority parents of the outer continuity.

Contributors The editors and contributors of this document are listed in the document header above. Listing is governed by Appendix B.7 of the PIC Legal Appendices.

Acknowledgement The Provenance Identity Continuity (PIC) Model — the theoretical framework this specification expresses in normative form — was created by Nicola Gallo. It first appeared on Zenodo on 1 December 2025 and is developed in full in the Proof-of-Continuity paper: Gallo, N. (2025). PIC Model — Provenance Identity Continuity for Distributed Execution Systems. Zenodo. zenodo.org/records/17777421 (DOI: 10.5281/zenodo.17777421). Gallo, N. (2026). Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents. Zenodo. zenodo.org/records/21285112 (DOI: 10.5281/zenodo.21285112). Authorship of the PIC Model remains with Nicola Gallo; the PIC specifications are published and maintained by Nitro Agility S.r.l. as Specification Steward. Any work that references, implements, or claims conformance with PIC must preserve this attribution, distinguishing the PIC Model (author: Nicola Gallo) from the PIC Specifications (steward: Nitro Agility S.r.l.), as required by the PIC Legal Appendices (Appendix B, Attribution; Appendix D, Acknowledgements), which are incorporated into this specification by reference.

Legal Notices The appendices governing: A. Use of Automated Language Assistance, B. Authorship, Stewardship, Attribution, and Derivative Works, C. Disclaimer and Limitation of Liability, D. Acknowledgements, are maintained in a single canonical document, the PIC Legal Appendices (draft/0.2/pic-legal.md), and are incorporated into this specification by reference as if fully set forth herein. In case of conflict between this document and the PIC Legal Appendices, the PIC Legal Appendices prevail for legal, governance, licensing, and attribution matters. This specification is subordinate to the PIC Specification, which defines the normative semantics of the PIC Model and is the entry point of the specification set. This document does not introduce new conceptual authority, invariants, or authorship claims beyond those defined in the PIC Legal Appendices.

References [1] Gallo, N. (2026). Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents. arXiv:2607.08906 [cs.CR]. arxiv.org/abs/2607.08906 [2] Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels. BCP 14, RFC 2119. rfc-editor.org/rfc/rfc2119 [3] Leiba, B. (2017). Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. BCP 14, RFC 8174. rfc-editor.org/rfc/rfc8174