Platform Administration and Governance

Level

Advanced

Format

Live and instructor-led, remote or on-site

Length

Four live half-day sessions (3.5 hours each)

Audience

Workspace administrators, platform owners and security and compliance teams

Cost

Free for customers and partners; quoted for other teams

Certificate

VDF AI Certified Administrator

Reply to applications

Within 2 business days

Labs

One after every module

6 modules and a capstone

The modules run across the four sessions. Each one ends with a lab in VDF AI.

1. Roles, workspaces and access

   Who holds which powers, how workspaces keep teams apart and how access is granted and withdrawn.

   • Workspace administrators and platform-wide administrators, and what each one controls
   • How separate workspaces keep sources, indexes and datasets apart
   • Company and workspace details that only owners or approved administrators may edit
   • Integrations an administrator registers or consents to before users can connect them
   • Revoking connected apps and access when people leave or accounts change

   Lab

   Map the roles in your lab workspace, confirm who can change workspace details, then remove a departed user’s access and the connected apps they authorised.

   Outcome

   An access map showing who can administer, build and use each part of the workspace.

2. Sharing rules and publishing controls

   Deciding how far agents, networks, templates and sources can travel, and who approves each step.

   • Default sharing scope for new agents and default visibility for new sources
   • Open or approval-based publishing to the agent library and the template library
   • Restricting embedding to agents an administrator has reviewed and approved
   • Edit rights, forking and co-editing on shared networks
   • Deciding which people and agents may attach sensitive knowledge sources

   Lab

   Set approval-based publishing and a personal default sharing scope, then take one agent from personal use to an approved library entry and find each change in the audit trail.

   Outcome

   Sharing and publishing rules that match your risk posture, with the exception paths written down.

3. Tools, models and external services

   The controls that decide what agents and networks may call and which models they may run on.

   • Default tool sets, and sensitive tools such as external email send held back for explicit grants
   • Allowed-model lists that network owners can narrow but never broaden
   • Allowed external services: web access, integrations, tools and destinations
   • Regulated routing mode, and why the allowed-models list is the actual enforcement
   • Why Skills never widen access, and which controls are enforceable

   Lab

   Set a workspace allowed-models list and an internal-only services policy, switch one network to regulated routing and read in its run which model each step used and why.

   Outcome

   Tool, model and service limits that apply to every new agent and network by default.

4. Policies and budgets

   Placing cost ceilings where runs are unattended, and confirming they stop runs when they should.

   • Per-run, daily and monthly caps matched to manual, scheduled and webhook-triggered networks
   • What happens at a cap: a clean stop, a notification and a preserved partial run
   • Workspace budget defaults for new scheduled networks and approval for large increases
   • Notification routing for budget thresholds, failures and policy violations
   • Recording why each guardrail exists and reviewing guardrails every quarter

   Lab

   Put a daily cap on a scheduled network, run a deliberate over-the-cap test and confirm the run stops cleanly and the alert reaches the right person.

   Outcome

   Budget caps that have been tested as well as configured.

5. Audit trail, run history and usage

   Turning logs into answers when something surprises you or a reviewer asks for evidence.

   • Audit trails in Agents, Networks and Data, filtered by action, user, item and time range
   • Run history and usage: status, trigger, failure modes, budget burn and idle items
   • The platform-wide error log, and when to escalate to the platform team
   • Library agents that draft repository compliance summaries, model cards and transparency notices
   • Weekly, monthly and quarterly review habits

   Lab

   Investigate a planted change, such as an agent newly attached to a sensitive index or a raised budget cap, using only the audit trail and run history, and write up who changed what and when.

   Outcome

   A review routine and an investigation method that rest on logged evidence.

6. Privacy, security and separating live work

   Who can see what, how connection credentials are protected and how to keep experiments apart from live work.

   • Checking what each role can see in run history, monitoring and logs before a wider release
   • Encrypted connection credentials, read-only database accounts and secret references
   • Reviewing connected-app permissions and revoking access that is no longer needed
   • Deleting files, conversations and runs, and where data-protection requests go
   • Keeping experiments apart from live work: workspace isolation, maturity tags and promoted versions

   Lab

   Draft the privacy and access statement for your workspace, covering what each role can see, how credentials are held, how access is revoked and where experimental work stays until it is promoted.

   Outcome

   A privacy and separation statement a security reviewer can check against the platform.