Session 209 — Vitto Governance Hardening & User Tier Hierarchy Fix

Overview

This document covers the foundational security and governance changes made to the GoGrab platform in Session 209. These changes ensure that the right people have the right level of control over Vitto (our AI super-assistant) and the platform at large.

What Was Wrong (The Problem)

1. Anyone could change Vitto's behavior

Vitto has "executive instructions" — strategic directives that shape how the AI behaves for an entire workspace. Think of these as the "company policy" for AI behavior. Any logged-in user could create, modify, or delete these directives. There were no permission checks.

2. The user hierarchy was upside down

Our platform has different levels of users, from founders (executives) down to end customers. The code incorrectly placed developers and admins at the top (L0), when in reality executives (founders/C-suite) should be at the top. This matters because whoever is "at the top" gets to control things like Vitto's core values, personality defaults, and strategic directives.

3. The "executive" role existed in the backend but was invisible to the frontend

The backend added an executive role at the right hierarchy level (90 out of 100), but the frontend UI didn't know it existed. The frontend UserRole type didn't include executive. This meant the UI couldn't show executive-only features or restrict access for executives.

4. A security guard had no teeth

The Vitto backend had its own local "roles guard" (the code that checks if you're allowed to access something). But this guard used simple text matching instead of understanding the hierarchy. So an executive wouldn't automatically pass an "admin required" check — it would only pass if the code explicitly listed "executive" as an allowed role.

What We Fixed (The Changes)

The Corrected User Hierarchy

What Was Changed (8 files across 3 layers)

Layer 1: Shared Type Definitions

• auth.types.ts — Fixed the tier hierarchy documentation (was L0=developer, now L0=executive). Added executive to the UserRole type so the frontend can recognize and use it.

Layer 2: Backend Security

• roles.guard.ts (shared) — Updated documentation to show the full hierarchy including executive at level 90.
• roles.guard.ts (Vitto-local) — Replaced the broken flat-matching guard with the shared hierarchy-aware guard. Now an executive automatically passes any check that requires admin or below.
• vitto.controller.ts — Added permission gates to 6 previously unprotected endpoints:
  • Creating/updating/deleting executive instructions → Executive only
  • Setting a default persona for all users → Executive only
  • Publishing a persona to the marketplace → Executive only
  • Creating/updating personas → Admin or above
• vitto-config.service.ts — Fixed which roles get which settings access. Previously, admins had the same access as developers. Now admins are correctly placed in the "platform builder" tier with appropriate (but not full) settings access.

Layer 3: Frontend UI

• brain-context.service.ts — Added isExecutive signal. Updated isAdmin to include executives.
• vitto-settings.component.ts — Fixed role-to-tier mapping. Added isExecutive for future executive-only UI sections.
• theme-dashboard.component.ts — Added executive to the admin check so executives can access theme management.

What This Means For Users

For Executives (You)

• You now have a distinct role (executive) that gives you the highest level of human access.
• Only you can set directives that shape Vitto's behavior across a workspace.
• Only you can publish personas to the marketplace or set default personas.
• All developer and admin features are automatically available to you (the hierarchy handles this).

For Developers & Admins

• They can still create and edit personas, manage technical settings, and access developer tools.
• They cannot modify executive instructions, publish personas, or set workspace defaults.
• Admins now have appropriate settings access (workspace events, autonomy preferences) without seeing engine-level controls.

For Regular Users

• No change to their experience. They still see their assigned features.
• They are now properly protected from accidentally accessing admin or executive features.

What's Next

Immediate (This Session)

• User Management Module Modernization — Update the core user-management module to use real backend APIs instead of mock data, incorporating the corrected tier hierarchy.

Upcoming

• Space-level Core Values — Allow executives to define custom core values per space (currently hardcoded as "helpful, honest, safe").
• Core Values Editor UI — Transform the read-only core values viewer into an editor for executives.
• Cross-space Learning Isolation — Ensure memories don't leak between spaces.

Technical Details (For Engineering Reference)

Files Modified

MCP Intelligence Logged

• 4 architectural decisions with calibrated confidence (0.93-0.97)
• 2 conventions added (security + architecture)
• 4 outcomes reported
• Decision IDs: dev_1773339083867_uy3tzq1, dev_1773339093192_dic0kif, dev_1773339102249_nxwkony, dev_1773339111511_l40lg1a

Risk Assessment

• Low risk: All changes are additive (new guards, new type values). No existing behavior is removed.
• Edge case: If any user currently has role: 'editor' in their JWT and was relying on developer-level settings access (due to the old wrong mapping), they will now see fewer settings. This is correct behavior — editors should never have had developer access.
• Migration: No database migration needed. The executive role just needs to be assigned to the correct users via the database or an admin endpoint.