Vendor Registry
The vendor registry is the canonical list of third-party AI services known to the organization. Every vendor entry captures the information operators need to make informed governance decisions:| Field | Purpose |
|---|---|
| Vendor name | Human-readable identifier (e.g., “Anthropic”, “OpenAI”, “Cohere”) |
| Category | Service type — LLM provider, embedding service, tool host, code runtime |
| Data classification | What data sensitivity levels this vendor is approved for |
| Contract status | Active, under review, expired, or terminated |
| Review status | Whether due diligence has been completed and when it was last refreshed |
| Contact / Owner | Internal owner responsible for the vendor relationship |
The Forge Console exposes the vendor registry at Trust Fabric > Vendors > Registry. The page currently displays the registry table with vendor metadata. Backend storage and CRUD operations are being built.
Vendor Review Process
Before a vendor can be marked as approved, it should go through a due diligence review. The review process is designed to answer three questions:- Data safety — Can this vendor handle the data classification levels your agents will send to it? What are the data retention and processing terms?
- Reliability — What are the vendor’s uptime SLAs? How do they handle incidents and communicate outages?
- Compliance — Does the vendor meet the regulatory and internal compliance requirements for your organization (SOC 2, GDPR, HIPAA, etc.)?
- Review requester — Who initiated the due diligence review
- Review status — Pending, in progress, approved, rejected, or expired
- SLA tracking — Time elapsed since review was requested vs. target review completion time
- Documentation checklist — Which required documents have been collected (DPA, security questionnaire, SOC 2 report, etc.)
- Review decision — Final disposition with reviewer notes and any conditions
Vendor Blocklist
The blocklist is the enforcement mechanism. When a vendor is blocked, it means the organization has made a deliberate decision that agents should not use that vendor’s services. Reasons for blocking include:- Failed due diligence — The vendor did not meet security, compliance, or data handling requirements
- Contract expiration — A previously approved vendor whose contract has lapsed without renewal
- Incident response — A vendor involved in a security incident or data breach, blocked pending investigation
- Policy violation — The vendor’s terms changed in ways that conflict with organizational policy
- Regulatory requirement — A jurisdiction-specific restriction on using certain providers
| Field | Purpose |
|---|---|
| Vendor | Reference to the vendor registry entry |
| Block reason | Structured reason category + free-text explanation |
| Blocked by | The operator who added the block |
| Blocked at | Timestamp of the block action |
| Remediation status | Whether the vendor is working to resolve the issue |
| Review date | When the block should be re-evaluated |
Gateway Integration
The real power of vendor governance comes from connecting it to the gateway routing system. Gateways in Forge are the execution runtimes that agents dispatch work through — each gateway maps to a specific vendor’s infrastructure. The planned integration points: Vendor-to-gateway mapping. Each gateway registration will optionally reference a vendor registry entry. This creates a link between “OpenClaw gateway running on Anthropic” and the “Anthropic” vendor record, allowing governance decisions to factor in vendor status. Vendor status as a safety gate. A future safety gate in the dispatch pipeline could check the vendor’s registry status before allowing dispatch. If the vendor behind a gateway is blocked or has an expired review, the gate blocks dispatch — the same way the existing gateway health gate blocks dispatch to offline gateways. Policy conditions on vendor fields. The policy engine could be extended with vendor-scoped conditions (e.g.,vendor.reviewStatus != 'approved' triggers a block), giving operators declarative control over vendor enforcement without code changes.
Routing preferences. The capability-based routing system could incorporate vendor governance signals — preferring gateways backed by approved vendors with current reviews and active contracts.
See Gateway Model for how gateways self-register, report health, and declare capabilities. Vendor governance will layer on top of this existing infrastructure rather than replacing it.
Roadmap
Vendor governance is at an early stage. Here is an honest assessment of what exists today and what is planned.What exists now
Console Pages
Three Forge Console pages are live: Registry, Reviews, and Blocked. They render the page structure with tab navigation but display placeholder content while the backend is built.
Navigation Structure
Vendor pages are integrated into the Trust Fabric section of the Forge Console navigation with proper tab groups, icons, and keyword search support.
What is being built
Vendor Schema
Convex table definitions for vendor records, review tracking, and blocklist entries. Follows existing schema patterns in convex/schema/.
CRUD Operations
Convex mutations and queries for registry management, review lifecycle, and blocklist operations. Includes RLS and audit logging.
What is planned
Gateway-Vendor Linking
Connect gateway registry entries to vendor records so governance decisions can factor in vendor status during dispatch.
Vendor Safety Gate
A new gate in the dispatch pipeline that checks vendor approval status before allowing dispatch to a vendor-backed gateway.
Policy Engine Extension
Add vendor fields to the policy condition language so operators can write declarative rules against vendor attributes.
Review Automation
Scheduled reminders for review expiration, automated status transitions, and notification integration for review SLA breaches.
Next Steps
Governance Overview
The Trust Fabric: safety gates, policies, budgets, and approval controls.
Safety Gates
The dispatch pipeline that vendor governance will integrate with.
Gateway Model
Gateway registration, health monitoring, and capability-based routing.
Policies
Declarative policy engine that will be extended with vendor-scoped conditions.