> For the complete documentation index, see [llms.txt](https://docs.visdom.virtuslab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.visdom.virtuslab.com/visdom-orchestrator/user-guide/governance-cost-policy-egress-identity.md).

# Governance: cost, policy, egress, identity

Cost, policy, egress, identity.

Governance in the Orchestrator is not one feature but six surfaces, all workspace-scoped, all visible under **Govern** and **Operate** in the UI. They exist because an agent with a model key, a git token and network access is, from a security team's point of view, an unattended process with credentials.

## Cost ledger and quotas

Every agent run writes cost entries, which roll up per project and per workspace. Quotas are set against those rollups, and the flow engine consults a **quota gate** before dispatching: a workspace over a blocking quota has its triggers refused rather than being allowed to start and fail later.

A warning quota raises an alert and lets the work continue. A blocking quota is what it says.

## Approval policies and classifiers

Approval policies are **versioned**, and the engine reads the active version at dispatch time. That is the one place in the platform where policy is version-pinned to a decision.

Classifiers run over model output when the runtime reports it, and write to a findings ledger. A regex PII detector ships; the registry is designed to take more. High-confidence findings raise governance alerts.

## Egress

Host-pattern allow and deny rules per workspace, resolved **deny-wins**. Runtime pods consult the resolver before making a non-LLM HTTP call, so an agent cannot quietly reach an internal service that nobody granted it.

Two caveats worth stating out loud. The resolver is unit-tested, but end-to-end enforcement only exists with a real cluster and a real pod making a real call. And the per-agent allow-list actually in force comes from the agent's `egress_allow_list` column, not from the catalog manifest's `permissions` block.

## Service identities

Ed25519 keypairs minted, rotated and revoked per workspace. The controller signs JWTs with them, and adapter target handlers use those tokens when calling external systems. This is what lets an outbound integration be attributed and revoked without rotating a shared secret across every installation.

## Key management and the audit chain

Secrets are AES-256-GCM encrypted under a master key ring, with a pluggable KMS adapter per workspace. The no-op adapter ships; GCP and Vault adapters are operator-side work. The audit log itself is **hash-chained**, so tampering is detectable rather than merely unlikely: the same property AI Tracing provides for the developer's own machine, applied here to the platform's own actions.

## Alerts

Cost over-cap, high-confidence classifier findings and egress denials all raise into one governance alerts inbox, which pushes to the UI as it happens rather than on refresh. It is the only place where all three failure kinds land together.

{% hint style="success" %}
**RBAC is a static permission table, not a rules engine.** Roles map to actions on resources through a fixed policy, with grants scoped to workspace or project. It is easy to reason about and easy to audit; it is not expressive enough for per-repository or per-branch rules.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.visdom.virtuslab.com/visdom-orchestrator/user-guide/governance-cost-policy-egress-identity.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.