protocol

Verifiable provisioning records for agent-driven infrastructure

When agents provision infrastructure, the proof should outlive the session that made the change.
Originary Team11 min read
Who this is for. Platform engineers, infrastructure leads, security reviewers, and agent-tool builders whose workflows let an agent or CLI provision production-adjacent resources (cloud projects, databases, API keys, auth, environment variables) and who need verifiable records of those changes that survive the session that produced them.

The point is not to make PEAC a provisioning system. The point is to make provisioning observable as a portable record when a resource, credential, domain, budget, or deployment target changes across systems.

Provisioning used to be a human workflow.

A developer created an account, opened a dashboard, copied keys into .env, configured a database, wired auth, added analytics, and deployed the app. Some of that work lived in Git. Some lived in provider dashboards. Some lived in shell history. A lot lived nowhere durable at all.

That model is changing.

Coding agents can now set up more of the application stack directly. They can initialize projects, provision databases, attach auth, create analytics projects, rotate credentials, and sync environment variables. Stripe Projects is one visible example of this shift: a CLI workflow for adding third-party services, managing credentials, handling upgrades, and giving coding agents the same command path humans use.

That is useful. It is also a new audit problem.

When an agent provisions infrastructure, teams need to answer simple questions later:

  • What changed?
  • Which service was added?
  • Which credential flow happened?
  • Which local project state changed?
  • What did the CLI report?
  • What can be verified without reopening every provider dashboard?

Logs help, but logs usually stay where they were produced. They are often local, partial, mutable, or tied to a specific vendor's system.

Provisioning needs a portable record layer.

What PEAC does not do

  • PEAC does not store credentials, secrets, or runtime tokens.
  • PEAC does not run vendor accounts, replace cloud control planes, or take over CLIs.
  • PEAC does not orchestrate provisioning, retry failed operations, or roll back changes.
  • PEAC does not assert that a provisioning action was authorized, only that it was observed.
  • PEAC does not replace your provider's audit log; it produces a portable signed record alongside it.

What PEAC adds

PEAC is the open standard for verifiable interaction records across agent, tool, API, and cross-runtime systems.

For provisioning workflows, PEAC does one narrow thing: it records what was observed.

A PEAC provisioning record can bind to the local artifacts around a workflow: command output, project state, environment sync metadata, credential rotation events, generated LLM context, or other sanitized evidence. The record can then be signed, exported, and verified later without depending on the original runtime.

That distinction matters.

  • PEAC does not provision resources.
  • PEAC does not store credentials.
  • PEAC does not become a vault.
  • PEAC does not approve actions.
  • PEAC does not decide whether a provider state is legally or operationally final.

It records what the issuer observed in a provisioning flow, and makes that record portable.

Govern locally. Prove across boundaries.

The first concrete example: Stripe Projects

We added a PEAC example and integration kit for Stripe Projects provisioning records.

The example is intentionally small. It does not wrap Stripe Projects. It does not claim a Stripe partnership. It does not introduce a new PEAC package or a new protocol surface.

It shows a pattern:

  1. run a provisioning workflow through Stripe Projects
  2. capture sanitized local artifacts
  3. issue signed PEAC records for the observed steps
  4. verify those records offline
  5. reconstruct a small audit trail from portable artifacts

The fixture-backed example covers four observed events:

  • project initialization
  • service addition
  • credential rotation
  • LLM context generation

Each record binds to observed artifacts from the workflow. The example uses experimental, illustrative type names. They are not registry commitments. That is deliberate. The goal is to show the shape of the record, not freeze a vendor-specific vocabulary too early.

Why this matters for agents

Agent-driven provisioning creates a boundary problem.

  • The agent may run locally.
  • The CLI may talk to Stripe.
  • Stripe may coordinate with a provider.
  • The provider may create a resource.
  • Credentials may be synced into local files.
  • The app may later run somewhere else.

No single system naturally owns the full story.

That is exactly where signed records are useful. They let each boundary emit or preserve a verifiable statement about what it observed, without forcing one platform to become the control plane for everything.

For developers, this helps answer:

  • "Did the agent actually add the database?"
  • "What changed after that command?"
  • "Which project state was the app built against?"
  • "Can another teammate verify the same setup trail?"
  • "Can we review the workflow without exposing secrets?"

For teams, it creates a cleaner audit habit: keep logs local, but let signed records travel.

What the kit does not claim

This is important enough to say plainly.

The Stripe Projects kit records provisioning and credential workflow observations. It does not infer settlement, legal acceptance, provider-side finality, or production deployment state from CLI artifacts.

For example, a local state change can show what the CLI observed. It does not, by itself, prove every downstream provider system completed exactly as intended. A billing or upgrade flow can show delegation-related evidence. It does not automatically become payment settlement evidence.

That conservative boundary is the point.

PEAC is more useful when it says less, precisely.

Why not just use logs?

Logs are necessary. They are not enough.

A log is usually tied to the system that produced it. A signed interaction record is designed to leave that system.

That makes a difference when work crosses teams, vendors, agents, and runtimes. A provisioning trail may begin in a local CLI session, pass through provider APIs, affect environment files, and later become relevant during security review, incident response, onboarding, or compliance work.

The useful question is not "can we log this?"

The useful question is:

Can we verify what happened after the original system is gone, unavailable, or not trusted as the only source?

That is the gap PEAC is built for.

A pattern, not a one-off

Stripe Projects is the first concrete example here because it is a clear, current provisioning workflow with agent support, local project state, credential sync, and provider coordination.

But the category is broader.

The same pattern applies to:

  • cloud project creation
  • API token issuance
  • database provisioning
  • auth setup
  • sandbox creation
  • environment sync
  • managed runtime setup
  • agent tool installation
  • provider dashboard changes exported into local workflows

The protocol category is not "Stripe Projects records."

The category is verifiable provisioning records.

Stripe Projects is simply a good place to show the pattern. The Stripe Projects providers directory already shows the shape of a broader app-stack provisioning surface, not just a Stripe-internal tool.

Where provisioning records apply

Stripe Projects shows the shape of a broader category: agents and CLIs increasingly provision services across app stacks. PEAC does not replace those providers. It gives teams portable signed records of what changed, which tool observed it, and what another party can verify later.

The examples below are compatibility examples based on the public Stripe Projects provider directory. They are not customer, partner, endorsement, or integration claims.
  • AgentMail
    Agent messaging
    Example provisioning event
    create inbox, route, or API key for an agent mail surface
    PEAC record value
    signed record of which agent provisioned which mail surface and key
  • Algolia
    Search
    Example provisioning event
    create application, index, or API key
    PEAC record value
    signed record of search-index provisioning by an agent
  • Amplitude
    Product analytics
    Example provisioning event
    create project, API key, or event source
    PEAC record value
    signed record of analytics workspace setup tied to an agent session
  • Auth0 / Okta
    Identity
    Example provisioning event
    create tenant, application, or admin grant
    PEAC record value
    signed record of identity-provider configuration by an agent or operator
  • Browserbase
    Browser automation
    Example provisioning event
    create project, session pool, or API key
    PEAC record value
    signed record of browser-runtime provisioning tied to an agent workflow
  • Chroma
    Vector database
    Example provisioning event
    create database, collection, or token
    PEAC record value
    signed record of vector-store provisioning tied to an agent session
  • Clerk
    Identity
    Example provisioning event
    create application, configure social connection, issue API keys
    PEAC record value
    signed record of auth setup, including which agent configured which app
  • Cloudflare
    Edge and DNS
    Example provisioning event
    create Worker, KV namespace, R2 bucket, or DNS record
    PEAC record value
    signed record of edge resource provisioning, including which tool ran the change
  • Daytona
    Dev environments
    Example provisioning event
    create workspace, runtime, or access token
    PEAC record value
    signed record of remote dev-environment provisioning by an agent
  • ElevenLabs
    Voice and audio
    Example provisioning event
    create project, voice, or API key
    PEAC record value
    signed record of voice-platform setup events
  • Firecrawl
    Web data
    Example provisioning event
    create project, crawler job, or API key
    PEAC record value
    signed record of crawl-platform provisioning by an agent or operator
  • Fly.io
    Hosting
    Example provisioning event
    create app, allocate machine, set secret
    PEAC record value
    signed record of app + region provisioning by an agent session
  • GitLab
    Source and CI
    Example provisioning event
    create project, runner, or deploy token
    PEAC record value
    signed record of which agent provisioned which CI surface
  • Hugging Face
    Model hosting
    Example provisioning event
    create space, model repo, or access token
    PEAC record value
    signed record of model-repo and token provisioning
  • Inngest
    Background jobs
    Example provisioning event
    create environment, function, or signing key
    PEAC record value
    signed record of background-job platform setup by an agent
  • Mixpanel
    Product analytics
    Example provisioning event
    create project, service account, or token
    PEAC record value
    signed record of analytics-platform provisioning events
  • Neon
    Database
    Example provisioning event
    create project, branch, role, or API key
    PEAC record value
    signed record of agent-driven Postgres branch and credential setup
  • Netlify
    Hosting
    Example provisioning event
    create site, environment variable, or deploy hook
    PEAC record value
    signed record of site + environment setup tied to an agent or developer session
  • OpenRouter
    Model routing
    Example provisioning event
    create workspace, API key, or routing rule
    PEAC record value
    signed record of model-routing provisioning tied to an agent workflow
  • PlanetScale
    Database
    Example provisioning event
    create database, branch, or service token
    PEAC record value
    signed record of branch lifecycle and token issuance
  • PostHog
    Product analytics
    Example provisioning event
    create project, API key, or feature flag
    PEAC record value
    signed record of analytics workspace setup by an agent
  • Privy
    Auth and wallets
    Example provisioning event
    create app, configure login methods, issue API keys
    PEAC record value
    signed record of auth and wallet-surface setup by an agent or operator
  • Railway
    Hosting
    Example provisioning event
    create project, service, or environment variable
    PEAC record value
    signed record of project bootstrap and environment wiring
  • Render
    Hosting
    Example provisioning event
    create service, environment, or deploy hook
    PEAC record value
    signed record of which agent provisioned which service tier
  • Runloop
    Agent runtimes
    Example provisioning event
    create devbox, snapshot, or runtime token
    PEAC record value
    signed record of agent-runtime provisioning tied to an agent session
  • Sentry
    Error tracking
    Example provisioning event
    create organization, project, or DSN
    PEAC record value
    signed record of error-tracking surface provisioning by an agent
  • Squarespace
    Domains and sites
    Example provisioning event
    register or connect a domain, configure DNS, issue API access
    PEAC record value
    signed record of domain-surface provisioning attributable to an agent session
  • Supabase
    Database and auth
    Example provisioning event
    create project, schema, RLS policy, or API key
    PEAC record value
    signed record of agent-driven project setup and key issuance
  • Turso
    Database
    Example provisioning event
    create database, group, or auth token
    PEAC record value
    signed record of edge-SQLite provisioning by an agent or CLI
  • Twilio
    Messaging and voice
    Example provisioning event
    provision phone number, messaging service, or API key
    PEAC record value
    signed record of which agent allocated which number for which app
  • Upstash
    Database
    Example provisioning event
    create Redis or Kafka, set credentials, configure region
    PEAC record value
    signed record of serverless data-surface provisioning by an agent
  • Vercel
    Hosting
    Example provisioning event
    create project, deploy preview, set environment variable
    PEAC record value
    signed record of project and environment setup tied to an agent or developer session
  • WorkOS
    Identity and SSO
    Example provisioning event
    create organization, configure SSO connection, issue API key
    PEAC record value
    signed record of identity-platform setup actions by an agent or operator

Provider names are included to explain where provisioning records can apply. This does not imply that any listed provider uses, endorses, or integrates PEAC.

Try it

The PEAC repo now includes:

  • a runnable Stripe Projects provisioning records example
  • sanitized fixtures
  • offline verification
  • an integration kit for teams that want to adapt the pattern

Start with the example. Read the kit. Then adapt the observer pattern to your own provisioning workflow.

The goal is not to replace your CLI, cloud provider, agent framework, or deployment system.

The goal is simpler:

When agents change infrastructure, the proof should outlive the session that made the change.

References

related