Governance and admin

A short guide for workspace admins

If you’re a workspace admin, what you care about is slightly different from what an individual network owner cares about. You’re not building this week’s workflow — you’re keeping the whole library of workflows your team depends on safe, observable, and well-run.

This page is the tour of what’s available to you.

Who has admin powers

Permissions scope at the workspace. Two roles are most common:

• Workspace admin — full control over network publishing, sharing, settings, and team membership for one workspace.
• Superadmin — platform-wide control across workspaces, usually held by a small platform or IT team.

Most of this page applies to workspace admins; superadmin-only features are flagged.

What you can see and adjust

Workspace settings

The settings area is where workspace defaults live. You’ll find groups for:

• Defaults for new networks. Default routing mode, default budget cap, default visibility.
• Allowed model lists. The maximum permitted set; network owners can narrow but not broaden.
• Allowed external services. Which integrations and destinations a new network may use by default.
• Template publishing rules. Who can publish to the workspace’s shared library.
• Notification routing. Who gets pinged on budget threshold, on failure, on policy violations.

A useful first-month posture: conservative defaults, with explicit exception paths. Network owners who need more get it on request. Owners who don’t ask are protected automatically.

Audit trail

Every meaningful action — network created, published, run, edited, deleted; policy changed; budget overridden — is logged. The audit screen lets you filter by:

• Action type. Run, edit, publish, delete, policy change.
• User. Who took the action.
• Network. Which network it affected.
• Time range. Day, week, month, custom.

Three things audit is good for:

• Investigating a surprise. “Who changed this network’s allowed-models list?”
• Compliance reporting. “Show me every regulated-mode run for the past quarter.”
• Spotting drift. “Which networks have had their budgets raised more than once?”

A weekly skim is enough for most teams.

Run history and usage

Across all networks in the workspace, the run history view shows volume, success rate, common failure modes, average duration, and budget burn.

This isn’t just about cost. It’s about understanding:

• Which networks are load-bearing. The ones with high run counts and low failure rates are your team’s actual workflows. They deserve extra attention to stability.
• Which networks are abandoned. Templates with zero recent runs are candidates to archive.
• Which networks fail often. Repeated failures point to brittle workflows or unstable sources.

Error logs (superadmin)

Beyond audit, superadmins can see a platform-wide error log with severity, source, and keyword filters. Most days, quiet. The days it isn’t, you’ll be glad it’s there.

Access and permissions

A few concepts to know:

Who can run what

By default, anyone in the workspace can run a workspace-published network. Network owners can also share narrower scopes — to a specific team, to specific people, or kept personal.

Who can publish

Publishing to the workspace library is an admin decision. Some workspaces let any network owner publish; some require admin approval. Either model is fine — pick the one that matches your team’s culture.

Who can edit shared networks

The original owner has full edit rights. They can grant edit rights to specific teammates. Forking is always available — anyone can copy a network and edit their copy without affecting the original.

Who can change policies and budgets

Workspace defaults for policies and budgets are admin-only. Per-network policies can be set by the network owner within the workspace’s permitted bounds. Raising a budget cap above the workspace default may need admin approval — that’s a setting you control.

What stays private, what’s shared

A common question: what can an admin see?

The honest answer: admins see metadata and policy posture, not content. That distinction matters.

• An admin can see that a network ran. They cannot see the conversation a step had with a model.
• An admin can see that a network produced an artifact. They cannot read the artifact unless explicitly granted access.
• An admin can see which network used which tool. They cannot see what the tool returned to that specific run.

For governance, that’s the right level. Admins control the rails; owners and operators control the contents.

For the full data-handling picture, see Privacy & Security.

Compliance and the EU AI Act

For organizations operating under the EU AI Act and similar frameworks, three Network capabilities matter most:

• Regulated routing mode — confine networks to a permitted model list.
• Allowed models and services — make the permitted list explicit at the workspace and network level.
• Audit trail — the record of which network ran which model on which input.

Together, these capabilities produce the kind of evidence trail compliance teams actually need: not just “we tried to do the right thing,” but a queryable record of every decision and every run.

For agents and assistants used in regulated workflows, see also Agents: Governance and admin — the same principles apply, with a few agent-specific notes.

Habits that keep Networks healthy

Weekly

• Glance at the audit log. Surprises? Anything new since last week worth noting?
• Glance at budget burn. Anything above an expected baseline?

Monthly

• Review the templates library. Any templates that haven’t been used? Archive. Any new networks that should be promoted to templates?
• Review the policies on top networks. Still aligned with how the team is using them?
• Talk to one power user. A 15-minute conversation reveals more than a hundred dashboard reviews.

Quarterly

• Audit who has publishing rights. People who left, teams that shifted — make sure access matches.
• Audit the workspace’s allowed-models list. Has anything been deprecated? Anything new worth permitting?
• Run a compliance check. For regulated workflows, confirm the audit trail tells the story you’d want to tell a regulator.

When to escalate

A few signals worth a ticket to whoever runs your VDF AI platform:

• A scheduled network is failing repeatedly. Once or twice is noise. Five times in a week is a pattern.
• Budgets are blowing through unexpectedly. Either the workload changed or routing is picking heavier models than it should.
• A policy change you didn’t expect. Audit shows a policy was raised; you don’t remember approving it.
• A regulation changed. New compliance requirements often need adjustments at the workspace level.

Where to go next

• Policies and budgets — the guardrails you administer.
• Smart model routing — the routing layer your policies constrain.
• Runs and monitoring — the operational view of what’s happening.
• VDF AI Data: Governance and admin — the parallel guide for Data.
• VDF AI Agents: Governance and admin — the parallel guide for Agents.