Attestation evidence

CI/lock turns observed work into a signed, timestamped statement about exact subjects.

flowchart TB
    S[Statement subject[].digest] --> I[in-toto Statement]
    R[predicateType + predicate] --> I
    I --> D[DSSE Envelope]
    O[OIDC principal] --> F[Short-lived Fulcio certificate] --> D
    T[RFC 3161 timestamp] --> D
    D --> G[gitoid of exact envelope bytes]

Wire contract

Policy evidence is a DSSE envelope whose payload is an in-toto Statement. The signed payload carries subjects and a typed predicate. The envelope carries the signature material and timestamp needed to verify it. This implements NIST SP 800-204D’s model of standard evidence structures whose provenance is authenticated and then used in policy decisions.

The current in-toto Attestation Framework v1.2 defines four independent layers. The Envelope specification defines authenticated transport, with DSSE as its recommended format. The Statement specification binds immutable subjects to a predicate type URI and predicate body. CI/lock uses that subject/predicate layering; the statement _type remains part of the signed payload and is verified as emitted.

Tenant binding

Tenant membership comes from the authenticated, tenant-scoped evidence lookup. It is not inferred from an arbitrary field inside a generic in-toto envelope. Pushgate also binds the policy decision to the connected repository route and immutable repository ID.

ALPS 0.1 remote attestation

CI/lock emits bounded observational ALPS evidence for the exact subjects, observed command and result, process ancestry, tool identity, and boundary measurements. Observation alone never assigns an ALPS level or authenticates the producer as an assessed agent.

Consumers can verify the signed envelope, signer, trusted timestamp, repository and commit bindings, evidence policy, and observer coverage. The resulting facts remain observational and non-enforcing: they do not authenticate the observed agent, assign a level, or authorize an action. A separate assessor may issue an ALPS assessment only after binding the evidence to an independently authenticated stable principal and the exact requested action. Until that contract is independently implemented and verified, the level remains Unknown.

CI/lock as an open witness

CI/lock is an open-source, in-toto-compatible witness designed for agent workflows. Its tool and attestor catalogs are machine-readable, and its attestor interfaces accept new command and output formats without changing the evidence envelope. Compatible distributions can extend that catalog while preserving the signed data model and policy constraints Pushgate verifies.

Evidence acceptance

Evidence is usable only when its envelope, certificate chain, timestamp, required subject, predicate schema, content identifier, and tenant-scoped lookup all agree. Command output or a caller-provided passed: true value is not a substitute for that verification path.

What the push receipt’s provenance records mean

Each row on the Pushes ledger folds two records behind its provenance disclosure. They are opposite assurance classes, and the page deliberately never presents them alike.

Coding agent — reported, not verified

The agent record is observed agent context: the process, tool, and model the alps-evidence attestor could see in the evidence-collecting process’s own parent process tree. A process can be named anything and controls what it says about itself, so this is the agent’s account of the agent — observational and non-enforcing. It does not authenticate the agent, and nothing at the gate can make it. The attestation carrying it was signed and bound to the commit, and the platform read it out of that verified evidence, which establishes that the record reached the ledger intact — not that what it says is true. The model field is usually the weakest claim of all: a model id is typically read out of an environment the agent controls, so it carries its own source and assurance markers.

Client — observed by the gate

The client record is measured at the edge from the server side of the connection that made the push. The client does not send these values and cannot choose them — the peer address, negotiated TLS, transport, and edge location — which makes them a stronger record than anything a push says about itself. What they establish is where the connection came from, not who was behind it: the address is the peer that connected, so behind a corporate proxy, a VPN, or carrier-grade NAT it is the intermediary’s address rather than the developer’s machine, and it identifies neither a person nor a device. The one client-asserted field in the record, the User-Agent, is labeled as such: the client can set it to any value.

The client record is signed as its own standalone attestation rather than merged into the build and test evidence, so erasing it on request — it contains a full client IP — leaves the supply-chain evidence for the same commit intact.