Govyn Cloud Dashboard

The Govyn Cloud Dashboard is the control plane for every AI agent your organization runs. It provides a single interface to monitor costs, manage governance policies, handle approval workflows, configure API keys, and review agent activity. Instead of managing YAML files and CLI commands across multiple proxy instances, the dashboard gives your team a shared, visual environment where every governance decision is trackable and every agent is observable.

The dashboard communicates with your Govyn proxy instances over HTTP. It reads cost data, activity logs, and policy evaluation results from the proxy API, and writes configuration changes back. The proxy remains the enforcement boundary — the dashboard is the management layer on top. This separation means the proxy is fully functional without the dashboard, preserving the open-source promise, while the dashboard adds the team collaboration and visibility that production deployments require.

Every action in the dashboard maps to an API endpoint. There is no hidden state, no client-side-only logic, and no data that exists only in the UI. If you prefer automation, the same API that powers the dashboard is available for scripts, CI/CD pipelines, and custom tooling.

Real-time cost tracking

The cost overview is the first thing you see when you open the dashboard. It shows your organization's total LLM spending across all agents, all providers, and all models. The data is presented in bar charts and line charts that update when you change the period selector between today, 7-day, and 30-day views.

Cost tracking in Govyn works at the request level. Every LLM request that passes through the proxy is recorded with its token counts — prompt tokens, completion tokens, and total tokens. The proxy estimates cost using per-model pricing tables that reflect the latest rates from each provider. These are rough estimates for governance purposes, not billing-grade calculations, but they are accurate enough to catch budget overruns, compare agent efficiency, and identify cost spikes before they become expensive.

The cost dashboard breaks down spending by multiple dimensions. You can view costs per agent to see which agents are consuming the most resources. You can view costs per model to understand which models are driving your bill. The period selector lets you compare today's spending against weekly or monthly trends. If you have smart model routing enabled, the dashboard shows the savings from automatic model downgrades — the difference between what the agent requested and what the proxy actually sent.

Cost data is queryable through the API at GET /api/v1/costs?period=today|7d|30d. The dashboard calls this endpoint and renders the response as interactive charts built with Recharts. The same data powers the budget gauges on the agents page, the cost columns in the activity feed, and the spending alerts system.

Agent management

The agents page shows every AI agent that has made at least one request through your Govyn proxy. Each agent appears as a row in a table with its name, total request count, estimated cost, and a budget gauge showing how much of its allocated budget has been consumed.

Agent identity is determined by the X-Govyn-Agent header that each agent sends with its requests. When a new agent value appears, the proxy automatically registers it and begins tracking its activity. There is no manual agent registration step — agents are discovered through usage. An "active agent" for billing purposes is any unique agent value that made at least one request in the current billing period.

Clicking an agent row opens the agent detail page. This page shows the agent's full activity history: every LLM request it made, the model used, the token count, the estimated cost, the policy evaluation result (allowed, blocked, or queued for approval), and the timestamp. Activity is paginated with cursor-based pagination, so even agents with thousands of requests load efficiently.

The agent detail page also shows budget gauges for daily and monthly spending limits. If the agent has a budget policy configured, the gauge shows current spending against the limit. When an agent approaches its budget threshold, the gauge changes color from green to yellow to red. Budget enforcement happens at the proxy level — the dashboard only displays the current state.

Plan limits control how many active agents you can run. The Starter plan supports 10 active agents per billing period. The Team and Enterprise plans support unlimited agents. The dashboard enforces these limits and shows your current agent count against your plan allowance.

Activity feed

The activity feed is a chronological stream of every event in your organization. It includes LLM requests, policy evaluations, approval decisions, budget threshold alerts, and configuration changes. The feed updates automatically every 10 seconds through polling, so you can leave it open and watch agent activity in near real-time.

Each activity entry shows the agent name, the action taken, the policy evaluation result, the cost, and the timestamp. Entries are color-coded by result: green for allowed requests, red for blocked requests, and yellow for requests queued for approval. You can filter the feed by agent name or by policy result to focus on specific types of events.

The feed uses cursor-based pagination. The initial load shows the most recent events, and you can scroll backward through history by loading more pages. This approach scales to organizations with millions of events because it never needs to count total rows or compute page offsets. The API endpoint is GET /api/v1/activity?limit=&cursor=&agent=&policyResult=.

For teams that need deeper analysis, the activity feed data is also available through the API for export to external monitoring tools, SIEM systems, or data warehouses. The same cursor pagination that powers the UI works for bulk export scripts.

Policy editor

The policy editor lets you create, modify, and manage governance policies through the dashboard instead of editing YAML files. Each policy has a name, a type, a priority level, and a set of configuration parameters that depend on the policy type.

Supported policy types include budget limits, rate limits, model allowlists and denylists, loop detection, content filtering, schedule restrictions, and smart model routing. The editor provides form fields appropriate to each type — numeric inputs for budgets and rates, multi-select for model lists, text fields for content patterns, and time pickers for schedules.

Policies are evaluated in priority order. The editor shows each policy's priority and lets you reorder them. When multiple policies apply to a request, the highest-priority policy that matches wins. This is the same evaluation order used by the YAML configuration in self-hosted deployments.

The dry-run feature lets you test a policy against sample requests before enabling it. Enter a sample request payload, select the policy to test, and the editor shows what would happen: allowed, blocked, or queued for approval, along with the specific rule that matched. This prevents surprises when activating new policies in production.

Each policy has a toggle switch for quick enable/disable. Toggling a policy off does not delete it — the configuration is preserved, and you can re-enable it at any time. This is useful for temporarily relaxing restrictions during development or incident response without losing the policy definition.

Approval queue

The approval queue is where human-in-the-loop governance happens. When an agent triggers a policy that requires approval, the request is held in the queue until a human approver reviews it and makes a decision. The queue has two tabs: pending items awaiting review and a history of past decisions.

Each pending item shows the agent name, the request details, the policy that triggered the approval requirement, and the timestamp. Approvers can expand any item to see the full request payload, then approve or deny it. Both actions support an optional notes field where the approver can explain their reasoning. These notes are stored permanently as part of the audit trail.

The pending tab polls every 5 seconds for new items. When an agent triggers an approval-required policy, the item appears in the queue within seconds. The agent's request is held asynchronously — the proxy returns a polling URL to the agent, and the agent waits for the decision. Once the approver acts, the proxy forwards the request (if approved) or returns a denial response to the agent.

The history tab shows every approval decision ever made, with filters for approved, denied, and expired items. This history is critical for compliance audits, incident investigations, and understanding how agents interact with human oversight over time. Each history entry includes the original request, the decision, the approver identity, the notes, and the exact timestamp.

API key management

The API keys section of the settings page lets you generate and manage the proxy authentication tokens that your agents use to connect to Govyn. These are the gvn_-prefixed tokens that agents send in their authorization headers when making requests through the proxy.

When you generate a new key, the dashboard displays the full token exactly once. Copy it immediately — the dashboard stores only a bcrypt hash of the key, so it cannot be retrieved later. The key list shows a preview of the first and last few characters (e.g., gvn_a3f...x9k) so you can identify keys without exposing them.

Revoking a key is immediate and permanent. Any agent using that key will receive authentication errors on its next request. This is the correct response when a key is compromised, when an agent is decommissioned, or when you need to rotate keys as part of a security policy. Generate the replacement key before revoking the old one to avoid downtime.

The key management API is available at POST /api/v1/keys (create), GET /api/v1/keys (list), and DELETE /api/v1/keys (revoke). All endpoints require Clerk authentication and are scoped to your organization. Keys from one organization cannot authenticate against another organization's proxy.

BYOK provider keys

BYOK — Bring Your Own Key — lets you use your own LLM provider API keys with Govyn instead of shared infrastructure keys. This is essential for organizations that need billing separation, custom rate limits from their provider, or access to specific model versions tied to their provider account.

The API targets section in settings lets you add provider keys for OpenAI, Anthropic, Azure OpenAI, Google Gemini, Mistral, Cohere, and any OpenAI-compatible endpoint. For each provider, you enter the API key and optionally a custom base URL (required for Azure OpenAI and self-hosted endpoints).

Provider keys are encrypted with AES-256-GCM before storage. The encryption key is a 256-bit key derived from the ENCRYPTION_KEY environment variable, which never leaves the server. When the proxy needs to forward a request to a provider, it decrypts the key in memory, uses it for the upstream request, and discards it. The plaintext key is never written to disk, never logged, and never returned by any API endpoint.

The key list shows a preview of each stored key (e.g., sk-...abc) and the provider it belongs to. This preview is stored at write time as a separate column — the system never decrypts stored keys just to display them. You can delete and re-add provider keys at any time. Deleting a provider key means the proxy can no longer forward requests to that provider until a new key is added.

Alerts and notifications

The alert system lets you configure webhook notifications for governance events. You define alert rules with conditions — such as "budget exceeds 80%" or "agent blocked by policy" — and a webhook URL where notifications should be sent. When the condition is met, Govyn sends a POST request to your webhook with the event details.

Alert rules are created in the settings page. Each rule has a name, a condition type, threshold parameters, and a destination webhook URL. The webhook URL is validated against SSRF protections — private IP ranges, localhost addresses, and cloud metadata endpoints are blocked to prevent server-side request forgery.

The notification history tab shows every alert that has been fired, including the timestamp, the rule that triggered it, the webhook URL it was sent to, and whether the delivery succeeded or failed. This history helps you verify that your alerting pipeline is working and diagnose delivery failures.

Common alert configurations include budget threshold warnings (fire when any agent exceeds 80% of its daily budget), policy block notifications (fire whenever an agent request is blocked), approval queue alerts (fire when a new item enters the approval queue), and anomaly detection alerts (fire when an agent's behavior deviates from its baseline). Alert rules can be combined with webhook integrations to send notifications to Slack, PagerDuty, email, or any HTTP endpoint.

Onboarding wizard

New users see a three-step onboarding wizard when they first access the dashboard. The wizard walks you through the minimum configuration needed to start governing agents:

1. Connect a provider — add at least one LLM provider API key (OpenAI, Anthropic, etc.) using the BYOK interface. This gives the proxy a key to forward requests with.
2. Provision your proxy — the dashboard generates a unique proxy slug for your organization and provisions a hosted proxy endpoint. This is the URL your agents will send requests to.
3. Start using your proxy — the wizard displays your proxy URL and a sample configuration snippet. Point your agents at the proxy URL, set the authentication header, and you are live.

The wizard is designed to get you from zero to a working proxy in under five minutes. Each step validates its inputs before allowing you to proceed. If you prefer to skip the wizard and configure everything manually through the settings page, you can dismiss it at any time.

After completing the wizard, the dashboard redirects you to the main cost overview where you will see your first agent requests appear as they flow through the proxy.

Dashboard vs self-hosted CLI

Govyn's open-source CLI and the Cloud Dashboard serve the same proxy, but they provide different management experiences. The CLI is configuration-file-driven, scriptable, and works in air-gapped environments. The dashboard is visual, collaborative, and designed for teams. Here is how they compare:

The CLI and dashboard are not mutually exclusive. You can self-host the proxy and connect it to the Cloud Dashboard for monitoring and management. You can also start with the CLI and migrate to the dashboard later without changing your agents — only the management interface changes, not the proxy behavior.

Frequently asked questions