Governance Framework

Enterprise controls for AI agent management at scale

MeetLoyd provides a comprehensive governance framework designed for enterprises that need to maintain control, visibility, and compliance over their AI agent deployments.

Overview

The governance framework operates at four hierarchical levels:

TENANT (Organization)
  └─ APP (Environment)
      └─ TEAM (Department/Function)
          └─ AGENT (Individual AI)

This hierarchy enables precise control—from organization-wide policies down to individual agent behavior.

Kill Switch Hierarchy

Emergency Controls

When something goes wrong, you need the ability to stop it immediately. MeetLoyd's kill switch system provides cascading emergency controls at every level.

Status States

Status	Description	Can Execute?
active	Normal operation	Yes
paused	Temporary suspension, can self-resume	No
suspended	Admin suspension, requires manual review	No
maintenance	Scheduled maintenance window	No

Cascade Behavior

When you pause a higher level, all children are blocked:

• Pause Tenant → All apps, teams, and agents stop
• Pause App → All teams and agents in that app stop
• Pause Team → All agents in that team stop
• Pause Agent → Only that agent stops

API Endpoints

# Check if execution is allowed
GET /api/governance/kill-switch/check?agentId=xxx

# Execute emergency action
POST /api/governance/kill-switch/action
{
  "targetType": "team",
  "targetId": "team_abc123",
  "action": "pause",
  "reason": "Investigating unusual behavior",
  "cascade": true,
  "expiresAt": "2026-01-08T12:00:00Z"
}

# View emergency action history
GET /api/governance/kill-switch/history

Available Actions

Action	Result	Use Case
pause	Temporary stop	Investigating an issue
suspend	Full stop, needs review	Security concern
resume	Return to active	Issue resolved
maintenance_start	Planned downtime	Scheduled maintenance
maintenance_end	End maintenance	Maintenance complete
emergency_stop	Immediate full stop	Critical incident

Timed Actions

Emergency actions can have an expiration time. When expired, the system automatically resumes the entity:

{
  "action": "pause",
  "expiresAt": "2026-01-07T18:00:00Z",
  "reason": "Paused for 2 hours during investigation"
}

---

Prompt Versioning

Why Version Prompts?

System prompts are the "soul" of your agents. In regulated industries, you need:

• Audit trail: Who changed what, when, and why
• Rollback: Restore previous versions instantly
• Review workflow: Approve changes before production
• A/B testing: Validate improvements with real traffic

Version Lifecycle

DRAFT → PENDING_REVIEW → APPROVED → STAGING → PRODUCTION
                ↓
            REJECTED (back to draft)

Status	Description
draft	Work in progress, not visible to users
pending_review	Submitted for approval
approved	Approved, ready for staging
staging	Deployed to staging environment
production	Live in production
deprecated	Replaced by newer version
rejected	Review rejected, needs changes

Creating a Version

POST /api/governance/versions
{
  "agentId": "agent_xyz",
  "systemPrompt": "You are a helpful assistant...",
  "contextPrompt": "The user is in the finance department...",
  "versionLabel": "q1-2026-update",
  "changeSummary": "Added compliance guidelines",
  "changeType": "update"
}

Review Workflow

# Submit for review
POST /api/governance/versions/{id}/submit-review
{
  "notes": "Please review the new compliance section"
}

# Review (approve/reject)
POST /api/governance/versions/{id}/review
{
  "decision": "approved",
  "notes": "Looks good, approved for staging"
}

# Promote to environment
POST /api/governance/versions/{id}/promote
{
  "environment": "staging"
}

# Later, promote to production
POST /api/governance/versions/{id}/promote
{
  "environment": "production"
}

Rollback

If a new prompt causes issues, instantly rollback:

POST /api/governance/agents/{agentId}/rollback
{
  "targetVersionId": "version_abc123"
}

This creates a new version (for audit trail) based on the target version and immediately promotes it to production.

Diff Tracking

Each version tracks changes from its parent:

{
  "versionNumber": 5,
  "parentVersionId": "version_xyz",
  "diffAdditions": 12,
  "diffDeletions": 3,
  "changeSummary": "Added error handling instructions"
}

---

AI-Generated Suggestions

Auto-Discovery Integration

When Auto-Discovery detects optimization opportunities, it creates prompt suggestions:

{
  "triggerType": "auto_discovery",
  "triggerSource": "tool_added:stripe",
  "suggestedPrompt": "...",
  "changeRationale": "New Stripe integration available. Suggest adding payment handling instructions.",
  "confidenceScore": 0.87,
  "riskLevel": "low"
}

Reviewing Suggestions

# View pending suggestions
GET /api/governance/suggestions

# Apply a suggestion (creates a draft version)
POST /api/governance/suggestions/{id}/apply

# Reject a suggestion
POST /api/governance/suggestions/{id}/reject
{
  "notes": "Not relevant to our use case"
}

---

A/B Testing for Prompts

Validating Changes

Before rolling out a prompt change to all users, test it with a subset:

POST /api/governance/ab-tests
{
  "agentId": "agent_xyz",
  "controlVersionId": "version_current",
  "treatmentVersionId": "version_new",
  "trafficSplit": 0.10,
  "minSampleSize": 100,
  "maxDurationHours": 168
}

Metrics Tracked

Metric	Description
executions	Number of runs per variant
successRate	Task completion rate
avgLatencyMs	Response time
userScore	User satisfaction rating

Completing a Test

POST /api/governance/ab-tests/{id}/complete
{
  "winner": "treatment"
}

---

Audit Trail

Every governance action is logged:

GET /api/governance/agents/{agentId}/audit-log

Returns:

{
  "entries": [
    {
      "action": "promote_production",
      "actorId": "user_abc",
      "actorName": "Jane Smith",
      "versionId": "version_xyz",
      "previousStatus": "staging",
      "newStatus": "production",
      "createdAt": "2026-01-07T10:30:00Z"
    }
  ]
}

Audit Actions

Action	Description
create_draft	New version created
submit_review	Submitted for approval
approve	Approved by reviewer
reject	Rejected by reviewer
request_changes	Changes requested
promote_staging	Deployed to staging
promote_production	Deployed to production
rollback	Rolled back to previous version
apply_suggestion	AI suggestion applied

---

Integration with Watchdog

The governance framework integrates with MeetLoyd's Watchdog system:

• Watchdog detects issue → Can trigger auto-pause via kill switch
• Emergency action executed → Logged in Watchdog alerts
• Automatic recovery → Timed pauses auto-resume

---

Budget Controls

Token & Cost Limits

Set spending limits at any level of the hierarchy to prevent runaway costs:

POST /api/budgets/configs
{
  "agentId": "agent_xyz",
  "maxTokensPerDay": 100000,
  "maxTokensPerMonth": 2000000,
  "maxCostPerDayCents": 5000,
  "maxCostPerMonthCents": 50000,
  "alertThresholdPercent": 80,
  "actionOnExceed": "block"
}

Budget Hierarchy

Budgets cascade like kill switches:

Level	Scope	Use Case
Tenant	All usage in organization	Company-wide spending cap
App	Environment-level limits	Dev vs Production budgets
Team	Department budgets	Marketing team limit
Agent	Per-agent limits	Limit experimental agents

Actions When Exceeded

Action	Behavior
block	Stop execution, return error
warn	Allow execution, send alert
throttle	Reduce request rate
queue	Queue requests for later

Checking Budget Before Execution

POST /api/budgets/check
{
  "agentId": "agent_xyz",
  "estimatedTokens": 5000,
  "estimatedCostCents": 50
}

Response:

{
  "allowed": true,
  "budgetRemaining": {
    "tokensToday": 45000,
    "costTodayCents": 2500
  },
  "warnings": ["Approaching 80% of daily token limit"]
}

Budget Summary

GET /api/budgets/summary?agentId=agent_xyz

Returns current usage vs limits:

{
  "tokensUsedToday": 55000,
  "tokensLimitToday": 100000,
  "costUsedTodayCents": 2500,
  "costLimitTodayCents": 5000,
  "utilizationPercent": 55,
  "projectedEndOfDay": {
    "tokens": 132000,
    "costCents": 6000
  }
}

---

Data Loss Prevention (DLP)

Overview

DLP prevents sensitive data from being exposed through AI agent responses. Configure rules to detect, redact, or block sensitive information.

Enabling DLP

PUT /api/dlp/config
{
  "enabled": true,
  "defaultAction": "redact",
  "scanInputs": false,
  "scanToolOutputs": true,
  "alertOnViolation": true,
  "alertThreshold": 5
}

Built-in Classifications

MeetLoyd includes pre-configured patterns for common sensitive data:

Category	Examples	Default Action
PII	SSN, passport numbers	Redact
Financial	Credit cards, bank accounts	Block
Credentials	API keys, passwords	Block
Health	PHI, medical records	Redact
Infrastructure	IP addresses, hostnames	Warn

Custom Classifications

Create your own detection patterns:

POST /api/dlp/classifications
{
  "name": "Internal Project Codes",
  "description": "Redact internal project identifiers",
  "category": "custom",
  "detectionPatterns": ["PRJ-[A-Z]{3}-\\d{4}"],
  "keywords": ["project-alpha", "initiative-x"],
  "action": "redact",
  "redactionText": "[PROJECT_CODE]",
  "severity": "medium",
  "enabled": true
}

DLP Actions

Action	Behavior
block	Stop response, return error
redact	Replace sensitive data with placeholder
warn	Allow but log violation
log	Silent logging only

Agent/Team Permissions

Grant specific agents permission to access sensitive data:

POST /api/dlp/permissions
{
  "agentId": "agent_hr_assistant",
  "classificationId": "class_employee_ssn",
  "permission": "allow",
  "reason": "HR agent needs SSN access for onboarding",
  "expiresInDays": 90
}

Violation Statistics

GET /api/dlp/violations?startDate=2026-01-01

Returns:

{
  "totalViolations": 127,
  "byClassification": [
    { "name": "Credit Card", "count": 45 },
    { "name": "SSN", "count": 32 }
  ],
  "byAgent": [
    { "agentId": "agent_support", "count": 67 }
  ],
  "byAction": {
    "blocked": 23,
    "redacted": 89,
    "warned": 15
  }
}

Testing Patterns

Test your DLP configuration without affecting real traffic:

POST /api/dlp/test
{
  "text": "Customer SSN is 123-45-6789 and card is 4111111111111111"
}

Response:

{
  "safe": false,
  "action": "redact",
  "totalMatches": 2,
  "violations": [
    {
      "classification": "SSN",
      "severity": "high",
      "matchCount": 1,
      "redactedMatches": ["[SSN]"]
    },
    {
      "classification": "Credit Card",
      "severity": "critical",
      "matchCount": 1,
      "redactedMatches": ["[CREDIT_CARD]"]
    }
  ],
  "processedContent": "Customer SSN is [SSN] and card is [CREDIT_CARD]"
}

---

Chain of Thought (CoT) Logging

Why Capture Reasoning?

For compliance and debugging, you may need to understand why an agent made a decision:

• Audit requirements: Regulators may require explainability
• Debugging: Understand failures in complex workflows
• Training: Improve prompts based on reasoning patterns
• Legal: Demonstrate non-discriminatory decision making

Capture Levels

Level	What's Captured	Storage Impact
none	Nothing	None
metadata	Decision type, outcome, timing	Low
summary	Condensed reasoning	Medium
full	Complete thinking process	High

Enabling CoT Capture

PUT /api/cot/config
{
  "enabled": true,
  "defaultCaptureLevel": "metadata",
  "captureOnHighCost": true,
  "highCostThresholdCents": 100,
  "captureOnError": true,
  "captureOnToolUse": false,
  "captureOnVerificationFail": true,
  "captureOnDlpViolation": true,
  "captureOnBudgetWarning": true,
  "sampleRate": 5,
  "retentionDaysMetadata": 90,
  "retentionDaysSummary": 30,
  "retentionDaysFull": 7,
  "maxCoTSizeBytes": 1048576
}

Agent-Specific Overrides

Force full capture for sensitive agents:

PUT /api/cot/agents/{agentId}/config
{
  "captureLevel": "full",
  "alwaysCaptureFull": true,
  "neverCapture": false
}

Capture Triggers

CoT is captured when:

Trigger	Description
high_cost	Execution exceeded cost threshold
error	Agent encountered an error
tool_use	Agent used external tools
verification_fail	Output verification failed
dlp_violation	DLP detected sensitive data
budget_warning	Approaching budget limit
random_sample	Random sampling for QA
manual	Explicitly requested

Querying CoT Records

GET /api/cot/records?agentId=agent_xyz&hadError=true&limit=50

Response:

{
  "records": [
    {
      "id": "cot_abc123",
      "agentId": "agent_xyz",
      "captureLevel": "full",
      "captureTrigger": "error",
      "summary": "Agent attempted to process invalid date format",
      "inputTokens": 1500,
      "outputTokens": 800,
      "hadError": true,
      "errorType": "ValidationError",
      "createdAt": "2026-01-07T10:30:00Z"
    }
  ]
}

Full CoT Content

GET /api/cot/records/{id}

Returns the complete captured reasoning (if full level):

{
  "id": "cot_abc123",
  "fullContent": "Let me analyze this request step by step...",
  "thinkingSteps": [
    { "step": 1, "content": "First, I need to validate the input..." },
    { "step": 2, "content": "The date format appears incorrect..." }
  ]
}

Annotations

Add human notes to CoT records for training:

POST /api/cot/records/{id}/annotations
{
  "note": "This is expected behavior - customer provided invalid format",
  "sentiment": "correct_behavior"
}

---

Governance Integrations

Overview

Connect MeetLoyd governance events to your existing incident management systems.

Supported Platforms

Platform	Type	Features
PagerDuty	Alerting	Incidents, escalations
ServiceNow	ITSM	Tickets, workflows, CMDB

Creating an Integration

POST /api/governance-integrations
{
  "integrationType": "pagerduty",
  "name": "Production Alerts",
  "enabled": true,
  "credentials": {
    "apiKey": "your-pagerduty-api-key",
    "serviceId": "PXXXXXX"
  },
  "config": {
    "defaultSeverity": "warning",
    "autoResolve": true,
    "includeCoT": false
  },
  "syncEnabled": true,
  "syncDirection": "bidirectional"
}

Sync Directions

Direction	Behavior
to_external	MeetLoyd → PagerDuty/ServiceNow only
from_external	External → MeetLoyd only
bidirectional	Full two-way sync

PagerDuty Integration

Features

• Create PagerDuty incidents from kill switch actions
• Escalate based on severity
• Auto-resolve when issues clear
• Link CoT records to incidents

Configuration

PUT /api/governance-integrations/{id}
{
  "config": {
    "defaultSeverity": "warning",
    "severityMapping": {
      "emergency_stop": "critical",
      "suspend": "error",
      "pause": "warning"
    },
    "escalationPolicyId": "PXXXXXX",
    "autoResolve": true
  }
}

List Services

GET /api/governance-integrations/{id}/pagerduty/services

ServiceNow Integration

Features

• Create ServiceNow incidents from governance events
• Map to CMDB configuration items
• Route to assignment groups
• Track in ITSM workflows

Configuration

PUT /api/governance-integrations/{id}
{
  "config": {
    "instanceUrl": "https://yourcompany.service-now.com",
    "defaultPriority": 3,
    "assignmentGroupId": "group_id",
    "categoryId": "category_id",
    "cmdbCiId": "ci_id"
  }
}

List Assignment Groups

GET /api/governance-integrations/{id}/servicenow/assignment-groups

Webhooks

Configure external webhooks to receive governance events:

GET /api/governance-integrations/{id}/webhook

Returns:

{
  "webhookUrl": "https://api.meetloyd.com/api/v1/governance-integrations/webhook/{id}",
  "webhookSecret": "whsec_xxxxx",
  "instructions": "Configure this URL in PagerDuty > Settings > Webhooks"
}

Sync History

GET /api/governance-integrations/{id}/sync/history

View synchronization status and any failures.

---

Best Practices

For Kill Switch

1. Use timed pauses for investigations (auto-resumes)
2. Document reasons for audit trail
3. Start at lowest level (agent) before escalating
4. Test cascade behavior in staging first

For Prompt Versioning

1. Always use meaningful labels (e.g., "q1-compliance-update")
2. Write clear change summaries for audit
3. Use staging environment before production
4. A/B test significant changes
5. Review AI suggestions weekly

---

Owner Briefing & Context Propagation

The V2MOM-like Approach

Inspired by Salesforce's V2MOM (Vision, Values, Methods, Obstacles, Measures), MeetLoyd supports cascading context from organization leadership to all AI teams.

TENANT (Owner Briefing)
    ↓ Team manager reads and extracts
TEAM MANAGER (Proposes summary)
    ↓ Human approves
TEAM MEMORY (Stored context)
    ↓ RAG access
TEAM AGENTS (Use in conversations)

Why Owner Briefing?

Public information (website, docs) gives the marketing perspective. But AI teams need insider context:

• Strategic priorities and their why
• Internal processes and workflows
• Key relationships and decision-makers
• Cultural norms and unwritten rules
• Budget context and constraints

Setting Up Owner Briefing

# Set the owner briefing
PUT /api/tenants/{tenantId}/briefing
{
  "content": "# Company Insider Briefing\n\nOur strategic priorities for Q1 2026:\n1. Customer retention over acquisition\n2. Focus on enterprise segment\n..."
}

Propagation Flow

Phase A: First Start (Automatic)

When a team first starts, the system checks for an owner briefing and initiates propagation.

Phase B: Manager Proposes Summary

The team's manager agent reads the full briefing and extracts what's relevant:

# View propagation status
GET /api/tenants/{tenantId}/briefing/propagation

# Response
{
  "pending": [
    {
      "teamId": "team_xyz",
      "teamName": "Sales Team",
      "status": "proposed",
      "proposedSummary": "Focus on enterprise deals over $50k...",
      "proposedAt": "2026-01-16T10:00:00Z"
    }
  ]
}

Phase C: Human Approval

Approve or reject the proposed summary:

# Approve
POST /api/tenants/{tenantId}/briefing/propagation/{teamId}/approve

# Or reject with feedback
POST /api/tenants/{tenantId}/briefing/propagation/{teamId}/reject
{
  "reason": "Missing key information about budget constraints"
}

Re-Propagation

When the owner briefing changes, trigger re-propagation to all teams:

POST /api/tenants/{tenantId}/briefing/propagate

# Response
{
  "triggered": 5,
  "teams": ["team_a", "team_b", "team_c", "team_d", "team_e"],
  "message": "Re-propagation triggered for 5 team(s)"
}

Best Practices

1. Write for AI consumption: Clear, structured content works best
2. Update regularly: Keep the briefing current with strategy changes
3. Review summaries carefully: The boss's extraction becomes team context
4. Cover insider knowledge: Focus on what can't be discovered publicly

---

Cascading Governance Policy

Overview

Governance policies cascade through a 4-level hierarchy, giving you precise control from organization-wide defaults down to individual agent behavior.

Tenant (organization-wide defaults)
  └── App (workspace overrides)
        └── Team (team-level overrides)
              └── Agent (agent-specific overrides)

Each level inherits from its parent. You only need to configure overrides where behavior should differ.

Autonomy Levels

Level	Behavior	Use Case
autonomous	Agents act freely, no approval needed	Fully automated deployments, startup teams
proactive	Agents propose, humans approve	Most production teams
reactive	Agents wait for human instruction	Testing, debugging, sensitive operations
locked	All agent actions blocked	Highly regulated scenarios, maintenance

Discovery Controls

Control what agents can automatically discover from connected integrations:

Capability	Description
Tool discovery	Discover new tools from connected integrations
Data discovery	Introspect schemas and data structures
Memory creation	Store discovery results in agent memory
Skill suggestion	Suggest skills based on discoveries
Auto tool sync	Automatically assign discovered tools to agents

Per-Artifact Governance

Control governance independently for each artifact type (schedules, workflows, triggers, prompts, interaction rules, memory, bootstrap tasks, continuous watch, tasks). Each supports its own autonomy level override and optional approval role.

Dashboard Configuration

Configure governance policies in Governance > Autonomy & Discovery (Growth+ tier):

• Tenant level: Set organization-wide defaults for autonomy, discovery, and artifact governance
• Team level: Override specific fields for individual teams
• Agent level: Override for specific agents (Enterprise tier)

The UI clearly shows which values are inherited vs overridden, and lets you reset individual fields to inherit from the parent level.

Best Practices

1. Start with restrictive defaults — Set restrictive autonomy at tenant level, then grant more freedom to specific teams
2. Disable auto-sync by default — Turn off auto tool sync organization-wide and enable it only for teams that need it
3. Lock sensitive artifacts — Set prompts and interaction rules to locked at tenant level for compliance
4. Override at the right level — Prefer team-level overrides over agent-level for easier management

---

Transparency Principle

No Black Box

MeetLoyd operates on a core governance principle: full transparency.

• All system prompts are visible and editable
• No hidden instructions or protected templates
• Every change is tracked and auditable

This replaces the legacy systemPromptProtected feature, ensuring:

• Compliance with emerging AI regulations
• Trust through visibility
• Easy debugging and improvement

---

Related Documentation

• Security Overview
• Approvals System
• Audit Logs
• Incident Management
• Auto-Discovery