provisioning records
Verify who provisioned what, when, and under which policy.
Agents and pipelines now create accounts, rotate credentials, set budgets, and ship deployments. Each console keeps its own log. Originary issues a signed record per provisioning event, so a customer, auditor, or platform team can verify the change without access to your consoles.
provisioning-eventverified offline
- Issuer
- https://platform.vendor.example
- Event
- created - deployment
- Resource
- prj_4fd2 - production
- Actor
- deploy-agent-v2
- Signature
- Ed25519 91bc44a0...
sample record - demo signature
Provisioning eventsCredential lifecycleBudgets and subscriptionsVerifies offline
The problem
Provisioning happens everywhere. The audit trail does not travel.
Deployments, provider setup, and credential changes are spread across consoles, CLIs, and CI. Each log is internal. A signed record answers the questions that cross the boundary:
- Who or what created the account, resource, or deployment?
- Which policy, budget, or subscription applied at that moment?
- Was the credential issued, rotated, or revoked, and when?
- Which agent or workflow made the change?
- Can any of this be verified later, without console access?
The specimen
One provisioning event. One signed record.
provisioning-eventverified offline
- Issuer
- https://platform.vendor.example
- Event
- created - deployment
- Resource
- prj_4fd2 - production
- Actor
- deploy-agent-v2
- Policy
- budget:v4 sha256:2ce1a9...
- Time
- 2026-07-02T08:41:19Z
- Signature
- Ed25519 91bc44a0...
sample record - demo signature
Verify on any machine, later
$ npx -y @peac/cli verify ./provisioning-event.jws --public-key ./jwks.json
Signature valid (offline)
issuer https://platform.vendor.example
event created - deployment - prj_4fd2
Tamper case
Change the resource, the actor, or one character of the signature and verification fails with E_INVALID_SIGNATURE.
What it covers
Lifecycle events across the stack you already run.
Vercel deploymentsGitHub Actions runsTerraform appliesProvider setupAccount creationCredential issuance and rotationBudgetsSubscriptionsDomainsDeploymentsResource lifecycle: created, updated, removed
Examples are composition surfaces, not partnership claims. The record format is the same everywhere: facts, policy, result, time, issuer, signature.
Boundaries
What Originary does not do here.
- It does not provision or deprovision anything.
- It does not manage credentials or secrets.
- It does not replace your infrastructure-as-code, CI, or CD.
- It does not gate or approve deployments.
- It records what happened, so another party can verify it.
Add records to one provisioning workflow this week.
npx -y @peac/cli verify ./provisioning-event.jws --public-key ./jwks.json
Logs stay local. Signed records travel.