Arbiter

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Arbiter existed before Build Week, but during the event we significantly extended it with the MCP Permission Gateway, discovery-first onboarding, SDK and CLI improvements, documentation synchronization, production readiness work, and a streamlined design-partner experience using Codex and GPT-5.6.

Inspiration

AI agents are quickly moving beyond chat. They’re sending payments, modifying infrastructure, accessing customer data, and interacting with production systems autonomously.

The problem is that enterprises still govern software as if humans are clicking buttons. Existing IAM systems were designed for people—not autonomous agents that can invoke tools, APIs, and MCP servers on their own.

We repeatedly saw the same gap: teams can build AI agents anywhere, but they have no centralized way to control what those agents are actually allowed to do.

Prompt instructions can be ignored. Logging after execution isn’t prevention. Framework-specific guardrails don’t scale across different agent stacks.

We built Arbiter because AI agents need a dedicated control plane that governs actions before execution, not after an incident.

⸻

What it does

Arbiter is the Control Plane for AI Agents.

Developers build agents using any framework—LangGraph, OpenAI Agents SDK, custom runtimes, MCP servers, or their own architecture.

Arbiter sits between an agent and sensitive operations and answers three questions before every action:

• Who is this agent?
• Does it have permission to perform this action?
• Should this action proceed, require human approval, or be denied?

Every request follows the same deterministic governance pipeline:

Identity ↓ Permission Registry ↓ Permission Grant ↓ Permission Scope ↓ Runtime Limits ↓ Policy Engine ↓ Approval (if required) ↓ Execution Release ↓ Immutable Audit

If a policy requires human approval, Arbiter pauses execution and creates an approval request. Once approved, the agent consumes a single-use execution release, which is revalidated before execution to prevent replay or stale approvals.

Every decision generates an immutable audit record and a cryptographically verifiable decision receipt.

Today Arbiter includes:

• Runtime Governance API
• AI Agent Discovery
• MCP Permission Gateway
• Operator Dashboard
• TypeScript SDK
• CLI
• Manifest-based governance (arbiter.yaml)
• Authority Map
• Approval workflows
• Audit ledger

Arbiter is not an agent framework, workflow engine, orchestration platform, chatbot platform, or observability tool. It governs AI agents built elsewhere.

⸻

How we built it

Arbiter consists of three production components:

Backend

A Node.js/Express runtime governance engine backed by PostgreSQL and Prisma that performs synchronous policy evaluation. Human operators authenticate with Firebase, while agents use dedicated Arbiter credentials.

Dashboard

A Next.js workspace where operators discover agents, review permissions, manage approvals, inspect audit trails, and monitor runtime governance.

SDK & CLI

A TypeScript SDK and CLI that allow developers to connect agents, observe tool usage, generate manifests, synchronize permissions, and evaluate actions through Arbiter.

One of our primary engineering principles was keeping runtime governance deterministic. Authority always originates from explicit permission grants, while policies determine whether those permissions may be exercised under current runtime conditions.

⸻

How we used Codex and GPT-5.6

During OpenAI Build Week, Codex and GPT-5.6 became our primary engineering collaborators.

We used them to accelerate implementation across the entire platform, including:

• MCP Gateway improvements
• Discovery and Authority Map workflows
• SDK and CLI enhancements
• Runtime governance implementation
• Documentation synchronization
• README modernization
• Architecture validation
• Production readiness reviews
• Test generation and refactoring

Human decisions remained responsible for product vision, runtime architecture, governance model, security boundaries, and release validation.

⸻

Challenges we ran into

Building governance for autonomous agents introduced several unique challenges.

The first was separating discovery from authority. Arbiter can automatically discover new agents and tools, but discovery never grants permission. Operators must explicitly adopt capabilities before they become authorized.

Another challenge was ensuring that approval is not execution. Conditions may change after an approval is granted, so execution releases are single-use and revalidated immediately before execution.

We also wanted MCP governance without inventing an entirely separate policy system. MCP tools flow through the exact same permission, policy, approval, and audit pipeline as every other runtime action.

Finally, we invested heavily in documentation because onboarding friction proved to be just as damaging as software bugs for early design partners.

⸻

Accomplishments that we’re proud of

• Built a production-ready runtime governance platform for AI agents.
• Unified permissions, approvals, policies, releases, and audit into a single deterministic runtime pipeline.
• Built an MCP Permission Gateway that automatically discovers tools before operators explicitly authorize them.
• Created a CLI and manifest-based workflow for Infrastructure-as-Code style governance.
• Implemented cryptographically verifiable decision receipts.
• Established a process that continuously synchronizes architecture documentation with the production codebase to prevent documentation drift.

⸻

What we learned

The biggest lesson was that enterprises don’t simply need better AI agents.

They need trustworthy infrastructure that allows those agents to operate safely in production.

We also learned that deterministic runtime governance builds more enterprise trust than opaque AI-based enforcement, and that developers care most about getting from installation to their first governed action as quickly as possible.

⸻

What’s next for Arbiter

Our immediate focus is validating Arbiter with design partners operating real AI agents in production.

We’re specifically focused on:

• Expanding adoption of the MCP Permission Gateway.
• Making agent onboarding dramatically simpler.
• Continuing to improve the developer experience for SDK and CLI integration.
• Strengthening enterprise security and operational tooling.
• Learning from real-world deployments before expanding the platform.

Our long-term vision is straightforward:

Developers should be able to build AI agents anywhere—and govern them from one control plane.

Built With

• agent-discovery
• api-key-management
• approval-workflows
• audit-ledger
• chatgpt
• cli
• express.js
• frontend:-next.js
• gemini-developer-platform:-node.js-sdk
• google-gemini-2.5-flash-ai-coding-tools:-cursor
• governance
• manifest-based-configuration
• prisma-database:-postgresql-(neon)-authentication:-firebase-authentication-infrastructure:-vercel-(frontend)
• railway-(backend)-ai-models:-openai-gpt-5.5-(primary)
• react
• rest-api-core-infrastructure:-runtime-policy-evaluation-engine
• tailwind-css-backend:-node.js
• typescript