Governance and admin

A short guide for workspace admins

For workspace admins, VDF AI Agents introduces a different set of questions than the people building agents care about. You’re not building this week’s specialist — you’re keeping the whole library of agents your team uses safe, useful, and well-governed.

This page is the tour.

Who has admin powers

Permissions scope at the workspace:

• Workspace admin — full control over publishing, sharing rules, and team membership.
• Superadmin — platform-wide control, usually held by a small platform or IT team.

What you can see and adjust

Workspace settings

The settings area is where workspace defaults live. Common groups:

• Publishing rules. Can any agent owner publish to the workspace library, or does publishing require admin approval?
• Default sharing scope. New agents default to personal, team, or workspace.
• Default tool set. Which tools are available to new agents by default. Admins can lock down certain tools (e.g., external email send) and require explicit grant for sensitive cases.
• Default model preference. Auto routing, a pinned model, or a permitted list.
• Notification routing. Who gets pinged when a published agent fails repeatedly, or when usage spikes.

A useful first-month posture: conservative defaults, with clear exception paths. Owners who need more can ask. Owners who don’t ask are protected automatically.

Audit trail

Every meaningful action — agent created, published, edited, deleted; sharing scope changed; conversation started — is logged. The audit screen filters by:

• Action type. Create, publish, share, edit, run.
• User. Who took the action.
• Agent. Which agent it affected.
• Time range. Day, week, month, custom.

Three things audit is good for:

• Investigating a surprise. “Who attached this agent to the customer-billing index?”
• Compliance reporting. “Show me every agent run that used a regulated model.”
• Spotting drift. “Which agents have had their tool set expanded since publishing?”

Usage analytics

Across all agents in the workspace, the usage view shows volume, common refinement patterns, common knowledge sources, and aggregate sentiment.

This is useful for:

• Recognizing the load-bearing agents. The ones with high usage and high satisfaction deserve extra attention to stability.
• Spotting abandoned agents. Library entries with no recent use are candidates to archive.
• Identifying missing capabilities. When a lot of agents get refined to do the same thing, that’s a hint a new agent is needed.

Error logs (superadmin)

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

Sharing and publishing controls

A few specific levers you have:

Who can publish

The default is usually “any agent owner can publish to the workspace library.” Some workspaces require admin approval. Either is fine — pick the one that fits your team’s culture.

Who can embed

Embedding (placing an agent into another app or page) reaches a broader audience than internal library publishing. Most workspaces restrict embedding to admin-approved agents. This is the right default — a customer-facing embed needs deliberate review of scope, tools, and knowledge.

Who can attach which knowledge

Agents can attach knowledge sources from VDF AI Data — folders, vector indexes, connected apps. Sensitive sources can be restricted: only specific people can attach them to agents, and only specific agents can be attached to them.

For sensitive knowledge, this is the lever that matters most.

Who can use which tools

Tools like web search, email send, and external API calls can be restricted at the workspace level. An agent that’s allowed to send email is doing something with real-world consequence; the workspace should be explicit about who can build one.

Compliance-oriented agents

A few of the pre-built library agents are specifically designed to help with compliance work. They deserve mention here because they often become part of admin workflows.

GitHub Repo Scanner (EU AI Act)

Reads a repository and produces a compliance-oriented summary. What AI is in the code, how it’s used, what risks it carries. Useful as an upstream input to formal compliance documentation.

Model Card Writer

Drafts a model card — the structured document describing what an AI model is, how it was trained, what it’s good at, and where it can go wrong. Useful for internal model registries and for responding to customer compliance questions.

Transparency Notice Writer

Drafts a transparency notice — the user-facing document explaining how AI is used in a product. Required by several emerging regulations.

A pattern that works for organizations operating under the EU AI Act:

1. Run GitHub Repo Scanner on the production codebase.

   The output tells you where AI lives in your product.

2. Run Model Card Writer on each material model.

   Build a registry of internal model cards.

3. Run Transparency Notice Writer for each user-facing AI feature.

   Produce the public-facing notices.

4. Capture the outputs in your compliance workflow.

   The agents don't replace your compliance team — they accelerate the documentation step.

These outputs are drafts. Compliance teams refine them. But the time from “we need this documentation” to “we have a draft we can refine” drops from weeks to hours.

What stays private, what’s shared

A common question: what can an admin see?

The honest answer: admins see metadata and usage patterns, not conversation content.

• An admin can see that a user ran an agent. They cannot read the conversation.
• An admin can see which knowledge sources an agent is attached to. They cannot see what the agent retrieved from them in a specific run.
• An admin can see which tools an agent has. They cannot see the tool’s results in a specific conversation.

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

For the full picture, see Privacy & Security.

Habits that keep Agents healthy

Weekly

• Glance at the audit log. New agents published? Any sharing-scope changes worth noting?
• Glance at usage. Anything spiking or dropping unexpectedly?

Monthly

• Review the library. Any agents that haven’t been used in a quarter? Archive. Any agents that have become essential? Make sure they have an owner.
• Review embeds. Are the embedded agents still appropriate for their audiences?
• Talk to one power user. A 15-minute conversation reveals more than a hundred dashboard reviews.

Quarterly

• Audit publishing rights. People who left, teams that shifted — make sure access matches.
• Audit sensitive knowledge attachments. Confirm the agents attached to sensitive sources are still the right ones.
• Run a compliance check. For regulated use cases, confirm the audit trail tells the story you’d want to tell.

When to escalate

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

• An agent is failing repeatedly. Once or twice is noise. Five times in a week is a pattern.
• A spike in tool errors. Often a sign an external service changed.
• An embedded agent is being misused. Either the embed needs different scoping or the audience needs different framing.
• A regulation changed. New compliance requirements often need adjustments at the workspace level.

Where to go next

• Sharing and publishing — what agent owners do; what you administer.
• Tools and knowledge — the levers you set defaults on.
• Agent library — the compliance-oriented agents in detail.
• VDF AI Networks: Governance and admin — the parallel guide for Networks.
• VDF AI Data: Governance and admin — the parallel guide for Data.