# OpenPort Protocol: A Security Governance Specification for AI Agent Tool Access

arXiv: https://arxiv.org/abs/2602.20196 · HTML: https://mlsanity.com/paper/2602.20196/

## Key facts

- Cited by 4 papers in the map (data through 14 Oct 2026).
- Builds on 0 of its 23 references that are in the map.
- First posted on arXiv 22 Feb 2026.

## Built on by (most cited first, 4 of 4)

- [Intent-Governed Tool Authorization for AI Agents](https://mlsanity.com/paper/2606.22916/) (2026)
- [Versioned Transitive Dependency-Closure Binding and Operation-Time Effect Governance for Agent Skills: ClosureBound](https://mlsanity.com/paper/2609.05920/) (2026)
- [Beyond Training: A Feasibility Taxonomy for Inference-Time AI Governance](https://mlsanity.com/paper/2609.10105/) (2026)
- [Fault-Tolerant Budget Conservation in Distributed Multi-Agent Delegation](https://mlsanity.com/paper/2610.00349/) (2026)

## Abstract (arXiv)

AI agents increasingly require direct, structured access to application data and actions, but production deployments still struggle to express and verify the governance properties that matter in practice: least-privilege authorization, controlled write execution, predictable failure handling, abuse resistance, and auditability. This paper introduces OpenPort Protocol (OPP), a governance-first specification for exposing application tools through a secure server-side gateway that is model- and runtime-neutral and can bind to existing tool ecosystems. OpenPort defines authorization-dependent discovery, stable response envelopes with machine-actionable textttagent.* reason codes, and an authorization model combining integration credentials, scoped permissions, and ABAC-style policy constraints. For write operations, OpenPort specifies a risk-gated lifecycle that defaults to draft creation and human review, supports time-bounded auto-execution under explicit policy, and enforces high-risk safeguards including preflight impact binding and idempotency. To address time-of-check/time-of-use drift in delayed approval flows, OpenPort also specifies an optional State Witness profile that revalidates execution-time preconditions and fails closed on state mismatch. Operationally, the protocol requires admission control (rate limits/quotas) with stable 429 semantics and structured audit events across allow/deny/fail paths so that client recovery and incident analysis are deterministic. We present a reference runtime and an executable governance toolchain (layered conformance profiles, negative security tests, fuzz/abuse regression, and release-gate scans) and evaluate the core profile at a pinned release tag using artifact-based, externally reproducible validation.