OSP
An open protocol that lets an agent discover, provision, and pay for a service in one HTTP call, then rotate the credentials it gets back.
What it is
OSP, the Open Service Protocol, lets an AI agent find a service from a .well-known/osp.json manifest, request provisioning in a single HTTP call, and receive encrypted credentials it can rotate or revoke. It treats service onboarding as a protocol operation instead of a per vendor flow.
The problem it solves
Agents are becoming the operators of developer infrastructure: they need to spin up databases, deploy apps, and rotate keys. Today every service has its own onboarding. Manual signups force browsers, CAPTCHAs, and email verification that agents cannot do, and ad hoc API wrapping makes every agent to provider integration custom and fragile. There is no open way for an agent to ask what is available, provision it, and pay through any rail.
How it works
Providers publish a manifest describing their services and pricing. An agent reads it, sends a provision request, and gets back credentials encrypted to its Ed25519 key, which it can later rotate or deprovision through standard endpoints. Payment is rail agnostic (Sardis wallet, Stripe, x402, or free). The implementation is a Rust core with TypeScript, Python, and Go SDKs, JSON schemas, a registry server, an MCP server, and adapters for Supabase, Neon, Vercel, Clerk, and others.
Where it fits
OSP is the provisioning layer of the agent stack. Where OAPS describes authority and Sardis governs payment, OSP is how an agent actually acquires and manages the services it pays for.
Status
Specification complete (v1.0 with a v1.1 draft). The Rust core compiles, all three SDKs ship working clients with tests, eight provider adapters exist, and a conformance suite and website are in place. Provider adapters need real credentials to exercise end to end.