Trust architecture

No single signature proves the whole delivery. Pushgate composes narrow proofs across explicit trust boundaries.

flowchart LR
    subgraph Sandbox[Restricted agent sandbox]
      A[Coding agent]
    end
    subgraph Policy[Command policy boundary]
      B[Tool broker]
      C[Pinned CI/lock child]
    end
    subgraph Platform
      F[Fulcio + TSA]
      S[Tenant evidence store]
      V[Policy evaluator]
    end
    subgraph Edge
      P[Pushgate verifier]
    end
    A -->|invokes cilock run| B -->|exact executable| C
    C -->|short-lived scoped identity| F --> S --> V --> P --> G[GitHub]

One proof establishes one act

A signature proves who signed exact bytes. It does not automatically prove why those bytes were created, that a policy was activated, or that GitHub applied a ref update. Pushgate keeps those acts separate and joins them only through explicit identifiers.

• The coding agent is the session parent and invokes the reviewed CI/lock binary.
• ALPS 2 requires a command broker outside the agent to resolve that exact binary into a fresh child-tool sandbox, so the agent cannot grant itself signing authority. That is the level's requirement, not an automatic property of running CI/lock.
• CI/lock records the result as an in-toto Statement inside a signed DSSE envelope.
• The TestifySec platform authenticates the tenant, stores evidence by exact content identifier, and evaluates the selected policy.
• Pushgate runs on Cloudflare’s edge and verifies the platform decision against the repository, commit, policy, and push nonce before using it.
• GitHub’s terminal response is a delivery result. It is distinct from the policy decision that authorized delivery.

Measure the boundary

Give the coding agent only its repository, a synthetic home, the required toolchain, and an allowlisted environment. Do not mount or inherit the TestifySec session, a human key, SSH_AUTH_SOCK, signer caches, infrastructure credentials, Keychain access, Docker sockets, or a generic signer socket.

A producer never proves its own isolation level. CI/lock emits bounded observational evidence for ALPS 0.1; consumers can verify its signature, trusted time, repository and commit bindings, and stated observer coverage. Those observations remain non-authoritative context and do not authenticate the observed agent, assign an ALPS level, or satisfy policy. Any assessed identity must instead bind to an independently authenticated stable principal. Missing observer coverage remains unknown.

Assurance vocabulary

UI labels and API consumers use these words narrowly:

Trust roots and time

The TestifySec platform publishes its Fulcio certificate chain and RFC 3161 timestamp-authority chain through its discovery document. CI/lock and Pushgate validate chains to those anchors. A matching certificate name is not enough: the key, issuer, identity constraints, signed bytes, and timestamp all have to verify.

GET https://platform.testifysec.com/.well-known/judge-configuration

Edge-to-platform identity

For a connected repository, Pushgate uses short-lived service assertions scoped to the repository and one platform audience. Policy evaluation and GitHub delivery are different grants. A credential issued for one audience or scope is rejected at the other.

Standards alignment

Pushgate applies established software-supply-chain principles to the Git push boundary. This mapping explains design intent; it is not a certification claim.