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.
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.
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.
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.
Most actions start as drafts. Execution is explicit and can be time-bounded, with safeguards for higher-impact tools.
Stable envelopes and machine-actionable agent.* reason codes make retries, backoff, and escalation deterministic—especially when the safe answer is “no.”
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.
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.
OPP is designed around a simple idea: make safe behavior the easiest behavior. Reads are straightforward. Writes are structured as intent → review → effect.
GET /api/agent/v1/manifest › tools + schemas + governance metadata
{
"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"
}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.
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.
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.
OpenPort is a continuing research project. The foundational paper specifies governed effect control; follow-up work adds intent-bound authorization and server-verified action claims upstream.
A claim-carrying mediation layer that converts decision-relevant rationale content into typed action claims and verifies them against current server-held facts before governed execution.
→A server-side authorization layer that binds tool visibility and proposed effects to the user’s current expressed intent—narrowing, never expanding, existing authority.
→A governance-first specification for exposing application tools to AI agents through server-side authorization, reviewable writes, predictable failure semantics, and audit.
→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.