OpenPort Protocol (OPP)
An open protocol for reliable AI tool access—authorization-aware discovery, draft-first writes, and stable responses that hold up in real workflows.
A protocol for turning AI intent into accountable action.
When AI systems move beyond chat and into workflows, they stop being “just models.” They start reading data, proposing changes, and triggering operations—often under uncertainty, partial context, and messy human inputs. The fragile part isn’t the tool list. It’s the moment an intention becomes an effect.
OpenPort Protocol (OPP) makes that moment explicit. It defines a small, stable surface for tool discovery and tool calls, and it keeps governance server-side: permissions, boundaries, reviewable writes, and predictable failure modes that a runtime can recover from safely.
We designed OPP to be model- and runtime-neutral, so different ecosystems can adopt it through optional bindings—without moving enforcement into every client.
arXiv and SSRN listings are under review. We’ll add links as soon as they’re available.
At a glance
OpenPort is intentionally small. The protocol surface is not the goal; it’s the leverage point that lets different runtimes behave safely in the same environment.
A gateway, not a plugin
Tool access is mediated by a server-side gateway so boundaries and policies are enforced consistently—no matter which model, agent framework, or SDK is on the other side.
Discovery that reflects reality
The manifest is an authorization-aware view of what a credential can do right now. If something isn’t allowed, it shouldn’t appear as an option.
Writes are reviewable by default
Most actions start as drafts. Execution is explicit and can be time-bounded, with safeguards for higher-impact tools.
Predictable failures
Stable envelopes and machine-actionable agent.* reason codes make retries, backoff, and escalation deterministic—especially when the safe answer is “no.”
Architecture
OPP separates two concerns: domain logic (what your product does) and governance semantics (how tool access is controlled, reviewed, and made operable). Adapters stay private. The gateway stays consistent.
Structured tool calls from any model or agent framework.
Auth, boundaries, write controls, rate limits, and stable responses.
Domain reads/writes and translation into internal systems.
Your systems stay private. OpenPort standardizes the interface, not your schema.
Issue/revoke keys, review drafts, and set execution windows.
Agent runtimes are probabilistic. OpenPort limits the blast radius by keeping governance decisions on the server—where policies, review, and incident response can be enforced consistently.
Protocol surface (core)
The core profile is intentionally minimal. Reads can be extended per domain, but write behavior is funneled through a small set of governance-aware endpoints.
GET /api/agent/v1/manifest
GET /api/agent/v1/ledgers
GET /api/agent/v1/transactions
POST /api/agent/v1/preflight
POST /api/agent/v1/actions
GET /api/agent/v1/drafts/{id}// success
{ "ok": true, "code": "...", "data": { ... } }
// error
{ "ok": false, "code": "agent.*", "message": "...", "details": { ... } }This structure is the contract: clients can always parse responses, and reason codes can drive safe recovery strategies.
How it works
OPP is designed around a simple idea: make safe behavior the easiest behavior. Reads are straightforward. Writes are structured as intent → review → effect.
Reads
- Fetch the manifest to learn which tools exist under this credential, including schemas and constraints: GET /manifest.
- Call a domain read endpoint (or a read tool) that the manifest allows.
- Parse the stable envelope and handle denials explicitly—without guessing.
GET /api/agent/v1/manifest → tools + schemas + governance metadata
Writes
- (Optional) Run preflight to compute an impact summary and bind intent with a hash.
- Submit the action request. The server returns a draft by default, or executes only when policy explicitly permits it.
- An operator approves or rejects drafts in the admin control plane.
- On execution, OpenPort enforces safeguards (for example, idempotency and preflight binding) and records an outcome.
{
"action": "transaction.hard_delete",
"payload": { "...": "..." },
"execute": true,
"forceDraft": false,
"requestId": "req_...",
"idempotencyKey": "idem_...",
"preflightId": "pfl_...",
"preflightHash": "sha256(...)",
"stateWitnessHash": "sha256(...optional...)",
"justification": "operator intent for high-risk execution"
}Draft lifecycle
Drafts separate intent from effect. This keeps the write path safe under retries, ambiguous prompts, and delayed approvals—without asking every client to reinvent the same safeguards.
`draft.status` is governance state, not a substitute for an execution record. On success, OpenPort records an execution outcome alongside the draft for traceability.
Bindings and profiles
OpenPort stays conservative about core semantics and flexible about adoption. Bindings let ecosystems map their tool formats to OPP without shifting enforcement into clients.
MCP clients, web bindings, custom SDKs, and agent frameworks.
Discovery, stable envelopes, draft-first writes, and predictable controls.
Gateway + admin plane + adapters—integrated into your systems.
Minimal endpoints + stable envelopes + draft-first writes. Designed to be domain-neutral and easy to adopt.
A stronger profile for delayed approvals: revalidates execution-time preconditions and fails closed if the underlying state has drifted.
How we validate
A protocol only helps if it doesn’t drift. OpenPort pairs the specification with executable artifacts: black-box conformance profiles, negative-path regressions, and release gates that keep behavior stable across versions.
Get involved
OpenPort is open source and designed to be implemented by many runtimes and many applications. If you’re exploring tool access, approvals, or safe automation, we’d love to compare notes.