N. Gallo Nitro Agility S.r.l. 20 July 2026 PIC Sandboxed Execution pic-sandboxed-execution-02 Abstract This document is the *PIC Sandboxed Execution Specification*, a subordinate specification of the PIC Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- spec.md). It retains its historical repository filename (pic- lineage-guardrail-spec.md). A *Composition Collection* carries one or more independent PIC continuities together for one proposed transition. When such a transition must be validated and controlled by configured policy, that control is itself an execution, and PIC governs it the way it governs any other execution: as a continuity. A *Sandboxed Execution* places the Composition Collection inside an ordinary outer PIC continuity. Each *guardrail* is a normal executor of that outer continuity: it verifies the outer continuity state, verifies every member continuity, applies the enforcement function, and — on permit — produces the next ordinary continuity advancement. No new continuity primitive is introduced, no trusted sandbox, and no external guardrail authority. The outer continuity is identified by the operation ENFORCE and by a profile-defined authenticated binding to the exact Composition Collection being evaluated. The construction is recursive: a member continuity may itself be a Sandboxed Execution. A Sandboxed Execution is PIC applied recursively: an outer PIC execution carries and governs an inner PIC execution. Guardrails build on the continuity semantics of the PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md) and are consistent with the PIC Revocation Specification (https://github.com/ pic-protocol/pic-spec/blob/main/draft/0.2/pic-revocation-spec.md); they do not alter Proof of Relationship, non-expansion, or the rule that every non-root continuity advancement continues exactly one predecessor. In case of conflict, the *PIC Specification* is authoritative. Gallo Informational [Page 1] PIC Sandboxed Execution July 2026 Document Status *Project:* PIC Protocol *Project Website:* www.pic-protocol.org (https://www.pic-protocol.org/) *Document:* pic-sandboxed- execution-02 *Version:* 0.2 (Draft) *Document Status:* Public Draft *Intended Use:* Informational and Experimental *Published:* 2026-07-20 *Editor(s):* Nicola Gallo (Nitro Agility S.r.l.) *Steward:* Nitro Agility S.r.l. *Source:* github.com/pic-protocol/ pic-spec/draft/0.2/pic-lineage-guardrail-spec.md (https://github.com/ pic-protocol/pic-spec/blob/main/draft/0.2/pic-lineage-guardrail- spec.md) This revision defines the *Sandboxed Execution*: PIC applied recursively — an outer PIC continuity that carries and governs an inner Composition Collection. It introduces no new continuity artifact type and no trusted sandbox. About This Document *Public Draft — Not a Standard* This document is an independently developed specification published as part of the PIC Protocol and maintained by Nitro Agility S.r.l. in its role as Specification Steward. It has not been adopted, endorsed, approved, or published by the IETF, IRTF, IAB, RFC Editor, ISO, IEC, W3C, CNCF, OpenID Foundation, or any other standards-development organization, unless a later version explicitly states otherwise. It is not an RFC, an Internet Standard, or an official work item of any working group or standards body. This document is published for public review, research, experimentation, implementation feedback, and possible future standardization work. It may be revised, replaced, or withdrawn at any time. Implementers use this draft at their own risk. Any implementation, interoperability statement, or conformance claim applies only to the exact document version identified above. Publication of this draft does not constitute certification, endorsement, security approval, interoperability assurance, regulatory approval, or standards-body recognition. Current project information and published specifications are available at https://www.pic-protocol.org/. Gallo Informational [Page 2] PIC Sandboxed Execution July 2026 Work In Progress This note is to be removed before publishing as an RFC. *Work in Progress — Experimental Design* The Sandboxed Execution and Composition Collection model described in this document is under active development. This model may change substantially before a later stable revision. Implementers MUST NOT assume wire compatibility, semantic compatibility, or backward compatibility with future revisions. Future drafts may introduce breaking changes to terminology, data structures, processing rules, profile bindings, and interoperability requirements. The current text is published for design review, experimentation, and implementation feedback. Editors * *Nicola Gallo* (Nitro Agility S.r.l.) Lead Editor * _Add your name via pull request (individual or organization) — listing is subject to editor approval (see Section 8)._ Contributors * _Add your name via pull request (individual or organization) — listing is subject to editor approval (see Section 8)._ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. PIC Continuity . . . . . . . . . . . . . . . . . . . . . 5 1.2. Composition Collection . . . . . . . . . . . . . . . . . 5 1.3. Sandboxed Execution . . . . . . . . . . . . . . . . . . . 7 1.4. Requirements Notation . . . . . . . . . . . . . . . . . . 9 2. Recursive Execution Model . . . . . . . . . . . . . . . . . . 9 2.1. Outer and Inner Execution . . . . . . . . . . . . . . . . 9 2.2. PIC Carrying PIC (PIC of PIC) . . . . . . . . . . . . . . 10 2.3. Recursive Composition Collection Safety . . . . . . . . . 10 2.4. Composition Collection Binding . . . . . . . . . . . . . 11 2.5. Originating the Sandboxed Execution . . . . . . . . . . . 15 2.6. Guardrail Prover and Verifier Profile . . . . . . . . . . 18 2.7. Operation Profile . . . . . . . . . . . . . . . . . . . . 22 Gallo Informational [Page 3] PIC Sandboxed Execution July 2026 3. Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Non-PIC-Aware Target . . . . . . . . . . . . . . . . . . 25 4.2. Relationship to Service Meshes and Deployment Infrastructure . . . . . . . . . . . . . . . . . . . . . 28 4.3. Consecutive Collusion . . . . . . . . . . . . . . . . . . 29 5. Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Security Boundary . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Model Guarantee . . . . . . . . . . . . . . . . . . . . . 30 6.2. Implementation Failure . . . . . . . . . . . . . . . . . 31 6.3. Semantic Divergence . . . . . . . . . . . . . . . . . . . 31 7. Model Summary . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 33 10. Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 1. 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. PIC CONTINUITY -------------- one root; one predecessor per non-root advancement; non-expansion COMPOSITION COLLECTION ---------------------- n >= 1 independent PIC continuities evaluated together SANDBOXED EXECUTION ------------------- an outer PIC continuity carrying a Composition Collection The whole construction reduces to one picture: Sandboxed Execution = outer PIC continuity carrying inner Composition Collection The outer continuity applies PIC recursively to the execution that validates and controls the inner execution. Gallo Informational [Page 4] PIC Sandboxed Execution July 2026 1.1. 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. root-A { READ, BACKUP } | | PoR + non-expansion v transition-A[1] { BACKUP } | v NEXT EXECUTOR One root. One predecessor per advancement. Authority only narrows. The construction — root representation, continuity advancement, Prover, and Verifier — is defined by the PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md); revocation by the PIC Revocation Specification (https://github.com/pic-protocol/ pic-spec/blob/main/draft/0.2/pic-revocation-spec.md); the formal model and proofs by the PIC Model [1] (Section 11). This document restates none of them. 1.2. 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; Gallo Informational [Page 5] PIC Sandboxed Execution July 2026 * it has no combined authority of its own; * it is the execution input bound to the outer ENFORCE advancement (Section 2.4). +========================================+ | COMPOSITION COLLECTION | | | | member continuity A: { BACKUP } | | member continuity B: { WRITE-S3 } | | | | authorities remain separate | +========================================+ Distinct continuities, one proposed transition. 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. Gallo Informational [Page 6] PIC Sandboxed Execution July 2026 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 }. collection members constitute the inner Composition Collection Composition Collection constitutes the execution subject evaluated by the sandbox authorized sandbox origin independently roots the outer continuity outer continuity authority remains only { 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. 1.3. 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: Gallo Informational [Page 7] PIC Sandboxed Execution July 2026 OUTER SANDBOXED EXECUTION Guardrail n-1 produces outer continuity state n-1 | | state n-1 is presented as predecessor | and verified by Guardrail n v Guardrail n verifies the outer predecessor verifies the bound Composition Collection applies the enforcement function produces outer continuity advancement n | | state n is presented as predecessor | and verified by Guardrail n+1 v Guardrail n+1 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: 1. receives an ordinary outer continuity state bound to a Composition Collection; 2. verifies the outer PIC continuation; 3. verifies every composition member; 4. applies the enforcement function; 5. on permit, produces the next ordinary outer continuity advancement; 6. 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. Gallo Informational [Page 8] PIC Sandboxed Execution July 2026 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. 1.4. 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] (Section 11) [3] (Section 11) 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. 2. Recursive Execution Model 2.1. Outer and Inner Execution outer execution = Sandboxed Execution inner execution = Composition Collection bound to an ENFORCE advancement 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. Outer authority = ENFORCE Composition members = execution inputs provided for evaluation Outer authority != union of inner authorities Gallo Informational [Page 9] PIC Sandboxed Execution July 2026 2.2. 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. OUTER PIC CONTINUITY STATE position n | +-- materialized authority: [ENFORCE] +-- executionContract: required next-guardrail properties +-- authenticated Composition Collection binding | +-- member PIC continuity A +-- member PIC continuity B +-- ... state n-1 --> 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. 2.3. 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. Gallo Informational [Page 10] PIC Sandboxed Execution July 2026 OUTER SANDBOXED EXECUTION authority: { ENFORCE } | +-- Composition Collection | +-- COMPOSITION MEMBER A | root: A | authority: { READ-ALL } | +-- COMPOSITION MEMBER B root: B authority: { BACKUP } No authority union is created. 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: invalid outer authority: { ENFORCE, READ-ALL, BACKUP } invalid composition member B advancement: { BACKUP, READ-ALL } 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. 2.4. 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 Gallo Informational [Page 11] PIC Sandboxed Execution July 2026 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: Composition Collection members: - continuity: 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. Gallo Informational [Page 12] PIC Sandboxed Execution July 2026 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: Composition Collection carries the complete inner execution request/execution binding binds the concrete ENFORCE action to the exact Composition Collection 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: operation target securityDomain (when applicable) Composition Collection commitment policyCommitment inputsCommitment semanticProfile (when applicable) enforcementResult requestDigest payloadDigest Gallo Informational [Page 13] PIC Sandboxed Execution July 2026 This profile does not redefine the base request format (PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md), 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: commitment == H( domainSeparator || canonical(Composition Collection) ) 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. Gallo Informational [Page 14] PIC Sandboxed Execution July 2026 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: outer continuity +-- Composition Collection +-- member continuity +-- member continuity +-- member continuity +-- nested Composition Collection +-- ... 2.5. Originating the Sandboxed Execution Three roles are distinct: Gallo Informational [Page 15] PIC Sandboxed Execution July 2026 proposing executor proposes the inner Composition Collection authorized sandbox origin roots the outer Sandboxed Execution first guardrail creates the first non-root outer advancement 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. Gallo Informational [Page 16] PIC Sandboxed Execution July 2026 { "authority": { "operations": ["ENFORCE"], "executionContract": { "...": "properties required of future guardrail executors" } }, "challenge": { "...": "bootstrap challenge for the first guardrail, when used by the selected profile" } } 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. outer root establishes ENFORCE authority establishes future guardrail contract carries the bootstrap challenge when used by the profile outer advancement 1 is produced by the first guardrail binds the evaluated Composition Collection binds the concrete ENFORCE request records the permit result The complete first sequence: Gallo Informational [Page 17] PIC Sandboxed Execution July 2026 INNER EXECUTION PROPOSAL Composition Collection [ composition member A | composition member B | ... ] | v AUTHORIZED SANDBOX ORIGIN outer root operations: [ENFORCE] executionContract: required guardrail properties challenge: bootstrap challenge for first guardrail | | PoR v FIRST GUARDRAIL verify outer root verify every composition member apply enforcement function | permit | v workload-signed candidate PIC Token JWT carries candidate PIC Continuity COSE whose transitions array contains exactly one PIC Continuity Transition COSE proposed operation: ENFORCE binds the Composition Collection commitment binds enforcementResult: permit | | trusted settlement validates candidate and transition v settled outer PIC Token JWT 1 carries settled PIC Continuity COSE whose transitions = null 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. 2.6. 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: 1. validate the outer predecessor continuity state; Gallo Informational [Page 18] PIC Sandboxed Execution July 2026 2. verify the profile-defined predecessor cryptographic reference and PoR; 3. verify freshness or challenge continuity as defined by the selected profile; 4. verify outer non-expansion; 5. verify time, profile, and applicable revocation requirements; 6. verify guardrail executor evidence and execution-contract conformance when required by the selected Sandboxed Execution profile or the underlying continuity profile; 7. verify the materialized outer authority contains ENFORCE; 8. verify the profile-defined outer request/execution binding operation is ENFORCE; 9. recompute and verify the request commitment to the complete Composition Collection; 10. 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: 1. validate the composition member independently using its selected ordinary PIC validation profile; 2. verify its root, immediate predecessor, or equivalent proof as required by that profile; 3. verify artifact authentication, integrity, and PoR as required by that profile; 4. verify predecessor binding where applicable; 5. verify non-expansion; 6. verify request/execution binding when required by that member's selected PIC continuity profile; 7. verify executor evidence and execution-contract conformance when required by that member's selected PIC continuity profile; 8. verify freshness and time as required by that profile; Gallo Informational [Page 19] PIC Sandboxed Execution July 2026 9. 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: 1. identify exactly one outer predecessor; Gallo Informational [Page 20] PIC Sandboxed Execution July 2026 2. produce valid PoR; 3. retain or attenuate ENFORCE; 4. preserve or strengthen the execution contract; 5. bind the exact evaluated Composition Collection; 6. bind its canonical digest in the request; 7. bind the enforcement inputs and permit result; 8. emit the next profile-defined challenge or freshness value when required; 9. 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. receive outer continuity state | Phase 1: validate outer PIC continuation | Phase 2: validate every composition member | Phase 3: apply enforcement function | permit? / \ no yes X Phase 4: build candidate and obtain next settled outer continuity Gallo Informational [Page 21] PIC Sandboxed Execution July 2026 *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. outer advancement n permit for exact crossing X | v does not imply | v outer advancement n+1 permit for crossing Y 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. 2.7. 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. 3. Acceptance Two checks are separate: ENFORCE must belong to the outer authority context, and the concrete executed request must be ENFORCE. Gallo Informational [Page 22] PIC Sandboxed Execution July 2026 ENFORCE in materialized outer authority (authority) bound request/execution operation == ENFORCE (executed action) For every non-root outer advancement, both MUST hold. A conforming guardrail or receiving outer executor MUST accept the outer continuity only if: ValidOuterContinuity(predecessorState, currentAdvancement) AND ValidSandboxOrigin(outerRoot) AND ENFORCE in materialized outer authority AND bound request/execution operation == ENFORCE AND bound Composition Collection commitment matches the presented Composition Collection AND ValidCompositionCollection(presented Composition Collection) AND ExactPresentedExecutionBinding AND bound enforcementResult == permit AND Fresh AND NotRevoked 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) = ValidOrdinaryRoot(outerRoot) AND AuthorizedSandboxOrigin(outerRoot) 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. Gallo Informational [Page 23] PIC Sandboxed Execution July 2026 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. ExactPresentedExecutionBinding = PresentedCollectionMemberSetMatchesCommitment AND PresentedContextMatchesCommitment AND RecomputedCompositionCollectionCommitmentMatches AND RecomputedRequestAndPayloadCommitmentsMatch AND NoHiddenSubstitutionWithinPresentedObjects 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: ValidCompositionCollection validates every composition member independently ExactPresentedExecutionBinding validates completeness and exact binding of the presented composition-collection execution and its crossing context 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; Gallo Informational [Page 24] PIC Sandboxed Execution July 2026 * 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. 4. 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. BYPASS ATTEMPT sender ---- inner Composition Collection only ----> 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. 4.1. 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: 1. verifies its outer predecessor; 2. verifies every composition member; 3. evaluates the enforcement function; Gallo Informational [Page 25] PIC Sandboxed Execution July 2026 4. constructs the ordinary outer continuity advancement or advancement proposal required by the selected profile; 5. binds the exact physical action, destination, payload, participants, policy inputs, and context; 6. authenticates the complete advancement or proposal as required by the selected profile; 7. follows any profile-required settlement or acceptance rules for treating the continuation as valid; 8. 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. Gallo Informational [Page 26] PIC Sandboxed Execution July 2026 proposing executor | | proposed Composition Collection v materializing guardrail | | validates outer PIC | validates composition members | evaluates enforcement | builds Profile 0.2 candidate | binds exact target operation v +-------- settlement authority validates candidate and transition | and issues settled outer continuity | +-------- non-PIC-aware target receives only the exact bound permitted action The timing between Profile 0.2 settlement and irreversible physical action is profile-defined. 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 (https://github.com/ pic-protocol/pic-spec/blob/main/draft/0.2/pic-architecture- deployment-spec.md). 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. PIC validity boundary: Is this a valid recursive PIC continuation? Deployment path boundary: Can the target be reached through an alternate physical route? Gallo Informational [Page 27] PIC Sandboxed Execution July 2026 4.2. 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. PIC SANDBOXED EXECUTION OPTIONAL SERVICE MESH provides: may provide: - outer execution continuity; - transport encryption; - guardrail-to-guardrail PoR; - service discovery; - exact request binding; - routing; - authority non-expansion; - observability; - independent continuity checks; - load balancing; - recursive validation; - rate limiting; - rejection of an invalid - network policy; outer continuation. - operational path restriction; - resilience and availability. 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. Gallo Informational [Page 28] PIC Sandboxed Execution July 2026 4.3. 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 (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- prover-verifier-spec.md). 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. 5. Recursion The model is recursively closed. No special root guardrail object exists, and no new trust primitive appears at deeper levels. outer continuity +-- Composition Collection +-- inner continuity A +-- inner continuity B +-- nested Composition Collection +-- deeper PIC execution 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. Gallo Informational [Page 29] PIC Sandboxed Execution July 2026 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. LEVEL 0 outer continuity { ENFORCE } | +-- Composition Collection | +-- LEVEL 1 / Composition Member A | continuity { READ } | +-- LEVEL 1 / Composition Member B continuity { ENFORCE } | +-- Composition Collection | +-- LEVEL 2 / Composition Member C continuity { WRITE } 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. 6. Security Boundary 6.1. 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; Gallo Informational [Page 30] PIC Sandboxed Execution July 2026 * 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. 6.2. 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. 6.3. 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. 7. Model Summary Gallo Informational [Page 31] PIC Sandboxed Execution July 2026 PIC CONTINUITY one root; one predecessor per non-root advancement; authority never expands. COMPOSITION COLLECTION one or more composition members constitute the inner execution being evaluated; each remains independently rooted and verified; their authorities are never merged. SANDBOXED EXECUTION an outer ENFORCE continuity carries the Composition Collection; each guardrail verifies and advances that outer continuity. PIC CARRYING PIC — PIC OF PIC the execution that validates PIC execution is itself represented and protected by PIC. 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. 8. 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 (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md). Gallo Informational [Page 32] PIC Sandboxed Execution July 2026 9. 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 (https://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 (https://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 (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md)* (Appendix B, Attribution; Appendix D, Acknowledgements), which are incorporated into this specification by reference. 10. 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 (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md)* (draft/0.2/pic-legal.md), and are *incorporated into this specification by reference* as if fully set forth herein. Gallo Informational [Page 33] PIC Sandboxed Execution July 2026 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 (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- spec.md), 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. 11. 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 (https://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 (https://www.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 (https://www.rfc-editor.org/rfc/rfc8174) Author's Address Nicola Gallo Nitro Agility S.r.l. Email: nicola.gallo@nitroagility.com Gallo Informational [Page 34]