Generative Governance

Natural language job descriptions compiled to RBAC manifests — LLM-assisted policy authoring with simulation and human approval.

Overview

Generative Governance is planned for Phase 3 of BrainstormRouter's governance roadmap. This page describes the design and intended behavior. Features marked Coming Soon are not yet available in production.

Writing RBAC policies for AI agents is tedious and error-prone. Permission matrices grow exponentially with the number of agents, models, and actions. Most teams either over-provision (dangerous) or under-provision (broken) because getting the policy right requires understanding both the agent's job and the platform's permission model.

Generative Governance inverts the process: describe what the agent should do in natural language, and let BrainstormRouter compile it into a precise RBAC manifest. A human reviews and approves the compiled policy before it takes effect.

Natural language to RBAC Coming Soon

Write a job description. Get a policy.

"This agent handles customer support tickets. It should use
Claude Sonnet for responses and Gemini Flash for summarization.
Budget: $2/day. It can read customer memory but not write to it.
It should never access billing or admin endpoints."

Output (compiled RBAC manifest):
{
  "role": "customer-support",
  "permissions": [
    "completions",
    "memory.read"
  ],
  "denied_permissions": [
    "memory.write",
    "billing.*",
    "admin.*"
  ],
  "model_allowlist": [
    "anthropic/claude-sonnet-4",
    "google/gemini-2.0-flash"
  ],
  "budget": {
    "daily_usd": 2.00,
    "per_request_max_usd": 0.10
  },
  "routing_strategy": "price"
}

The compilation step uses an LLM to interpret the job description, but the output is a deterministic, machine-readable policy — no ambiguity, no interpretation at runtime.

Human approval gate

Generative Governance never applies a policy without human review. The workflow has three stages:

Job Description → LLM Compilation → Human Review → Active Policy
                                         │
                                         ├─ Approve → policy goes live
                                         ├─ Modify → edit and re-review
                                         └─ Reject → discard

The review interface shows a diff between the proposed policy and the current policy (if one exists), highlighting permission changes, budget adjustments, and model access modifications. Reviewers can edit the compiled policy before approval — the LLM's output is a starting point, not a final answer.

Simulation engine Coming Soon

Before a policy goes live, simulate it against historical traffic to understand its impact:

const simulation = await client.governance.simulate({
  policy: compiledPolicy,
  since: "2025-06-01T00:00:00Z",
  until: "2025-06-30T23:59:59Z",
});

console.log(`Requests affected: ${simulation.total_requests}`);
console.log(`Would have blocked: ${simulation.blocked_count}`);
console.log(`Would have degraded: ${simulation.degraded_count}`);
console.log(`Cost difference: $${simulation.cost_delta.toFixed(2)}`);

// Breakdown by rule
for (const rule of simulation.rule_impacts) {
  console.log(`  ${rule.name}: ${rule.affected_requests} requests`);
}

The simulation engine replays historical requests through the proposed policy without affecting production traffic. It answers concrete questions:

How many requests would this policy have blocked last month?
Would any legitimate workflows have been disrupted?
What would the cost difference have been?

Template library Coming Soon

Common agent roles ship as pre-built templates that can be customized:

Template	Description	Default budget	Permissions
`customer-support`	Handles user-facing queries	$5/day	completions, memory.read
`researcher`	Gathers and synthesizes information	$2/day	completions, memory.read, memory.write
`coder`	Generates and reviews code	$10/day	completions
`orchestrator`	Coordinates sub-agents	$20/day	completions, delegate, memory.\*
`auditor`	Read-only access for compliance	$1/day	memory.read, evidence.read, governance.read

Templates are starting points. Each can be customized with additional constraints, model allowlists, or budget overrides before deployment.

const policy = await client.governance.fromTemplate({
  template: "customer-support",
  overrides: {
    budget: { daily_usd: 3.0 },
    model_allowlist: ["anthropic/claude-sonnet-4"],
  },
});

// Review and approve
await client.governance.approve({ policy_id: policy.id });

Design principles

Compilation, not generation. The LLM translates intent into structure. The resulting policy is deterministic — the same manifest always produces the same enforcement behavior, regardless of which LLM compiled it.

Human-in-the-loop, always. No policy reaches production without explicit human approval. The LLM reduces toil, it doesn't replace judgment.

Simulate before enforce. Every policy change can be dry-run against real historical data before it affects production agents.

Auditable. Every policy change records who wrote the job description, which LLM compiled it, who approved it, and when. The full lineage is available in the Evidence Ledger.

See Governance for the current governance capabilities available today.