MCP Scope Enforcement in VPC-Integrated Agentic Systems: Drawing Hard Lines Before Agents Cross Them

1. Tool Scope Manifests: Declaring Boundaries Before the Agent Is Initialized

Treating tool permissions as a manifest that is validated at agent initialization — not at runtime — moves your enforcement boundary to the only place where you can still say no without side effects.

Scope declarations belong at the composition layer, not scattered across individual tool handlers where they're easy to bypass or forget.
VPC-integrated tools create an especially sharp enforcement problem because the blast radius of a misconfigured tool isn't a bad API response — it's an EKS node drain or a security group mutation.
Initialization-time validation lets you reject an agent configuration before it ever receives a task, which is the only truly safe enforcement point in a long-running async pipeline.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

When an agent integrates with real VPC infrastructure — think EKS control plane diagnostics, CloudWatch log access, or RDS parameter reads — each tool is a named capability with an implicit blast radius. The right architectural move is to define a scope manifest at the point where you compose your agent: a typed, versioned structure that declares which tool categories are permitted, what resource ARN patterns are in-scope, and what actions require a human confirmation step before execution. This manifest gets validated when the agent supervisor initializes, not when it's mid-task and already holding a CloudWatch client. Source: [Diagnose Kubernetes Control Plane Performance Issues with AWS DevOps Agent] — AWS Containers Blog (https://aws.amazon.com/blogs/containers/diagnose-kubernetes-control-plane-performance-issues-with-aws-devops-agent/)

AIThe pattern connects directly to how CrewAI frames data-locality agents: the value of putting the agent close to the data is only realized if you've also defined what the agent is allowed to do with that access. A manifest-driven approach gives you a single artifact that can be diffed in code review, attached to a deployment record, and referenced in audit logs — which is exactly what the governance-first shift across this week's content is demanding.

Reference Architecture

// TypeScript: Scope manifest validation at agent init
import { z } from 'zod';

const ToolScopeManifest = z.object({
  allowedToolCategories: z.array(z.enum(['read', 'diagnose', 'mutate', 'delete'])),
  resourceArnPatterns: z.array(z.string()),
  requiresHumanGate: z.array(z.enum(['mutate', 'delete'])),
  manifestVersion: z.string(),
});

type ToolScopeManifest = z.infer<typeof ToolScopeManifest>;

function initializeAgent(config: unknown): AgentSupervisor {
  const manifest = ToolScopeManifest.safeParse(config);
  if (!manifest.success) {
    emitViolationEvent({ reason: 'invalid_manifest', errors: manifest.error.issues });
    throw new Error('Agent initialization rejected: invalid scope manifest');
  }
  return new AgentSupervisor(manifest.data);
}

function isToolPermitted(
  toolCategory: string,
  resourceArn: string,
  manifest: ToolScopeManifest
): { permitted: boolean; requiresGate: boolean } {
  const categoryAllowed = manifest.allowedToolCategories.includes(toolCategory as any);
  const arnMatches = manifest.resourceArnPatterns.some(p => new RegExp(p).test(resourceArn));
  const requiresGate = manifest.requiresHumanGate.includes(toolCategory as any);
  return { permitted: categoryAllowed && arnMatches, requiresGate };
}

State Interaction Chart

flowchart TD A[Agent Config + Scope Manifest] --> B{Manifest Validator} B -->|Valid| C[Agent Supervisor Init] B -->|Invalid| D[Reject + Emit Violation Event] C --> E[Task Received] E --> F{Tool Call Requested} F --> G{In Manifest Scope?} G -->|Yes| H[Execute Tool] G -->|No| I[Block + Log Denial] H --> J[Emit Tool Execution Trace] I --> K[Human Review Queue]

2. Data-Locality Agents and the Scope Enforcement Gap in Enterprise VPCs

Putting your agent inside the VPC next to the data solves the latency and egress problem but creates a harder governance problem: the agent now has ambient network access that no tool manifest can fully enumerate.

Ambient network access inside a VPC means an agent with a misconfigured tool can reach resources that were never in its intended scope, regardless of what the manifest says.
Data-locality architecture is valuable for the right reasons — lower latency, no data leaving the perimeter, direct database access — but those same properties make scope enforcement more consequential, not less.
Sidecar enforcement proxies or VPC endpoint policies are the infrastructure-layer complement to manifest-level enforcement, and you need both layers to have genuine defense in depth.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

The CrewAI post on building agents where data already lives frames the core insight correctly: the reason enterprise agents fail to ship isn't capability, it's the integration tax. But the integration tax has two sides — the cost of wiring an agent to your data, and the cost of ensuring that once wired, it can't reach more than it should. When you deploy an agent into a VPC subnet with a database connection pool, that agent has network-level access to everything reachable from that subnet unless you've also configured security groups, VPC endpoint policies, and IAM conditions as a second enforcement layer beneath your application-level manifest. Source: [How to build Agents Where Data Already Lives] — CrewAI Blog (https://blog.crewai.com/how-to-build-agents-where-data-already-lives/)

AIThe practical architecture here is a three-layer stack: the tool scope manifest at the agent composition layer, an authorization middleware that enforces manifest rules at each tool invocation, and VPC/IAM policy that enforces the same constraints at the network and API level independently. Any two of the three layers can be correct and you're still exposed if the third is missing. This is the agentic equivalent of defense-in-depth for distributed systems — the difference is that here a misconfiguration doesn't just cause a bug, it causes an autonomous system to take an action you didn't intend against real infrastructure.

Reference Architecture

// TypeScript: Tool invocation middleware with dual-layer enforcement
async function invokeToolWithEnforcement(
  toolName: string,
  toolCategory: 'read' | 'diagnose' | 'mutate' | 'delete',
  resourceArn: string,
  toolFn: () => Promise<unknown>,
  manifest: ToolScopeManifest,
  humanGateCallback: (context: GateContext) => Promise<boolean>
): Promise<ToolResult> {
  const { permitted, requiresGate } = isToolPermitted(toolCategory, resourceArn, manifest);

  if (!permitted) {
    await emitAuditEvent({ type: 'TOOL_DENIED', toolName, resourceArn, reason: 'manifest_violation' });
    return { success: false, denied: true, reason: 'out_of_scope' };
  }

  if (requiresGate) {
    const approved = await humanGateCallback({ toolName, resourceArn, toolCategory });
    if (!approved) {
      await emitAuditEvent({ type: 'GATE_REJECTED', toolName, resourceArn });
      return { success: false, denied: true, reason: 'human_gate_rejected' };
    }
  }

  const result = await toolFn();
  await emitAuditEvent({ type: 'TOOL_EXECUTED', toolName, resourceArn, toolCategory });
  return { success: true, data: result };
}

State Interaction Chart

flowchart TD subgraph VPC A[Agent Runtime] --> B[Tool Invocation Middleware] B --> C{Manifest Check} C -->|Permitted| D[Authorization Proxy] C -->|Denied| E[Block + Audit Log] D --> F{IAM + VPC Policy Check} F -->|Allowed| G[Target Resource] F -->|Denied| H[Network Deny + Alert] G --> I[Structured Response] end J[Scope Manifest] --> B K[IAM Role Policy] --> D

3. Infrastructure Agents in the Wild: EKS Diagnosis as a Scope Enforcement Case Study

The AWS DevOps Agent's EKS diagnosis workflow is a concrete example of what production-grade agentic scope enforcement actually needs to look like — and the places where it still leaves governance gaps for you to fill.

Autonomous correlation across CloudWatch audit logs and EKS throttling events is genuinely useful, but it also means the agent is touching multiple AWS service APIs that each carry their own blast radius.
Read-then-recommend patterns — where the agent diagnoses and suggests rather than diagnoses and acts — are the safest default posture for infrastructure agents, and worth encoding as a manifest-level constraint.
Remediation steps that an agent recommends but a human approves and executes represent the right human-in-the-loop boundary for EKS control plane operations, at least until you've accumulated enough supervised history to safely expand autonomous scope.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

The AWS DevOps Agent post describes an agent that autonomously identifies a misbehaving controller flooding the EKS API server, correlates CloudWatch audit logs with throttling patterns, and produces targeted remediation recommendations. That's a well-scoped agentic workflow — notice it stays in the read-and-diagnose category rather than executing the remediation. That boundary is meaningful. An agent with CloudWatch read access and EKS describe permissions has a manageable blast radius. An agent that also holds permissions to patch deployments, modify APF configurations, or evict pods is operating in fundamentally different territory, and the scope manifest enforcing that distinction is what separates a useful diagnostic agent from a liability. Source: [Diagnose Kubernetes Control Plane Performance Issues with AWS DevOps Agent] — AWS Containers Blog (https://aws.amazon.com/blogs/containers/diagnose-kubernetes-control-plane-performance-issues-with-aws-devops-agent/)

AIThis maps directly onto the loops debate at AI Engineer World's Fair — the question isn't whether autonomous agents can identify and fix EKS throttling issues, it's whether the engineering discipline to govern that autonomy safely is in place. Starting with read-only tool scope and a human gate on remediation is not a limitation to overcome; it's the responsible way to build supervised history before expanding autonomous boundaries.

Reference Architecture

// TypeScript: Read-then-recommend scope profile for EKS diagnostic agent
const eksDiagnosticManifest: ToolScopeManifest = {
  manifestVersion: '1.0.0',
  allowedToolCategories: ['read', 'diagnose'],
  resourceArnPatterns: [
    'arn:aws:logs:us-east-1:123456789:log-group:/aws/eks/*',
    'arn:aws:eks:us-east-1:123456789:cluster/prod-*',
  ],
  requiresHumanGate: ['mutate', 'delete'],
};

// Remediation stays in recommend-only mode until explicitly promoted
const eksRemediationManifest: ToolScopeManifest = {
  manifestVersion: '1.1.0',
  allowedToolCategories: ['read', 'diagnose', 'mutate'],
  resourceArnPatterns: [
    'arn:aws:logs:us-east-1:123456789:log-group:/aws/eks/*',
    'arn:aws:eks:us-east-1:123456789:cluster/prod-*',
  ],
  requiresHumanGate: ['mutate', 'delete'], // mutate always gated
};

State Interaction Chart

sequenceDiagram participant Agent participant CloudWatch participant EKS participant ManifestGuard participant HumanReviewer Agent->>ManifestGuard: Request: read CloudWatch logs ManifestGuard-->>Agent: Permitted (read scope) Agent->>CloudWatch: Fetch audit logs CloudWatch-->>Agent: Log data Agent->>ManifestGuard: Request: describe EKS workloads ManifestGuard-->>Agent: Permitted (diagnose scope) Agent->>EKS: Describe pods and controllers EKS-->>Agent: Workload data Agent->>Agent: Correlate throttling with offending controller Agent->>ManifestGuard: Request: patch deployment ManifestGuard-->>Agent: Requires human gate Agent->>HumanReviewer: Emit diagnosis + remediation recommendation HumanReviewer-->>Agent: Approved Agent->>EKS: Apply remediation

4. The Loops Debate as a Governance Signal: Autonomy Expands Faster Than Oversight

The core disagreement at AI Engineer World's Fair wasn't about whether autonomous agents work — it was about whether the engineering discipline to govern them safely exists yet, which is exactly the question that scope enforcement is designed to answer.

Autonomous software factories are viable in narrow, well-defined domains with tight tool scopes; they're fragile in broad, loosely constrained domains where tool boundaries are fuzzy.
The hype-practice delta that conference moderators flagged maps directly to the gap between what an agent is technically capable of and what your governance infrastructure can safely supervise.
Scope enforcement mechanisms don't constrain what agents can eventually do — they define the incremental path by which you earn the right to expand their autonomy based on supervised operational history.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

The debate framing from AI Engineer World's Fair — are loops viable now, or is the engineering discipline lagging — is precisely the tension that MCP scope enforcement is meant to resolve. Loops work when the action space is bounded, observable, and reversible. They fail when the agent has ambient access to tools with wide blast radii and no enforcement layer gates what it can reach. The pro-loop case is strong for well-scoped pipelines; the skeptical case is strong for any pipeline where tool permissions were granted permissively because tightening them felt like friction. Source: [AIEWF Daily Dispatch: The great loops debate and the state of AI engineering] — Latent Space (https://www.latent.space/p/aiewf-daily-dispatch-locomotives)

AIThis connects the loops debate to last week's governance signals around structured evidence emission and governed async processing. The teams shipping durable value from agents aren't the ones running the most autonomous loops — they're the ones who've defined the smallest viable action space, instrumented every tool invocation, and built incremental expansion paths with documented gate criteria. That's not a philosophical stance; it's an engineering methodology.

Reference Architecture

// TypeScript: Scope width classifier — determines gate requirement before loop iteration
type ScopeWidth = 'narrow' | 'wide';

interface ToolAction {
  category: 'read' | 'diagnose' | 'mutate' | 'delete';
  resourceArn: string;
  reversible: boolean;
}

function classifyScopeWidth(actions: ToolAction[]): ScopeWidth {
  const hasMutation = actions.some(a => a.category === 'mutate' || a.category === 'delete');
  const hasIrreversible = actions.some(a => !a.reversible);
  return hasMutation || hasIrreversible ? 'wide' : 'narrow';
}

async function runAgentLoop(
  actions: ToolAction[],
  humanGate: (actions: ToolAction[]) => Promise<boolean>
): Promise<void> {
  const scopeWidth = classifyScopeWidth(actions);
  if (scopeWidth === 'wide') {
    const approved = await humanGate(actions);
    if (!approved) {
      await emitAuditEvent({ type: 'LOOP_GATED', actions, reason: 'wide_scope' });
      return;
    }
  }
  for (const action of actions) {
    await executeAction(action);
    await emitStructuredTrace({ action, timestamp: Date.now() });
  }
}

State Interaction Chart

flowchart TD A[Agent Loop Initiated] --> B{Scope Width Assessment} B -->|Narrow + Observable| C[Autonomous Execution Permitted] B -->|Wide or Irreversible| D[Human Gate Required] C --> E[Tool Execution] E --> F[Emit Structured Trace] F --> G{Anomaly Detected?} G -->|Yes| H[Pause Loop + Alert] G -->|No| I[Continue Loop] D --> J[Human Reviews Action] J -->|Approved| E J -->|Rejected| K[Log + Update Scope Policy]

5. Vibe Coding Risk as an Agentic Governance Pattern: Unreviewed Tool Calls Are the New Unreviewed Code

The same psychological trap that produces unreviewed AI-generated code — accepting outputs without genuinely engaging with what they do — is actively reproduced in agentic systems where tool calls fly past without structured review.

Unchecked tool execution is structurally identical to vibe coding: the agent produces an action, the action gets applied, and no human genuinely evaluated whether it was the right action in that context.
AI-free zone classification — marking specific infrastructure surfaces or data domains as explicitly off-limits for autonomous action — is the agentic equivalent of requiring human review for high-risk code paths.
Review fatigue compounds the problem: if every tool call surfaces in an audit log but nothing is structured to direct attention to the high-risk ones, engineers stop reading the logs entirely.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

Fast.ai's framing of vibe coding as a flow-state trap — where the speed of generation outpaces the speed of genuine review — applies with equal force to agentic tool execution. The risk isn't that the agent is malicious; it's that it's fluent and fast enough that its actions feel reviewed even when they aren't. An agent that calls a mutating tool every thirty seconds inside a loop can accumulate significant infrastructure state changes before anyone notices a pattern. The governance response is to make the high-risk tool calls structurally impossible to ignore: emit them as distinct event types, route them to a separate review queue, and build alerting that fires when mutation rate exceeds a threshold. Source: [Breaking the Spell of Vibe Coding] — Fast.ai (https://www.fast.ai/posts/2026-01-28-dark-flow/)

AIThis connects directly to the AI-free zone classification signal emerging this week. Some infrastructure domains — production database schema changes, security group modifications, IAM policy updates — should be classified as zones where no autonomous agent action is permitted regardless of what the manifest says. That's not a technical limitation; it's an explicit governance decision that gets encoded in the manifest and enforced at the tool layer. The discipline of drawing those lines intentionally, before the agent is deployed, is what separates a governed agentic system from an accidentally permissive one.

Reference Architecture

// TypeScript: AI-free zone enforcement with mutation rate gating
type ZoneClassification = 'green' | 'yellow' | 'red';

const AI_FREE_ZONES: RegExp[] = [
  /arn:aws:iam:.*:policy\/.*/, // IAM policy mutations
  /arn:aws:ec2:.*:security-group\/.*/, // Security group changes
  /arn:aws:rds:.*:db:prod-.*/, // Prod RDS schema ops
];

function classifyZone(resourceArn: string, category: string): ZoneClassification {
  if (AI_FREE_ZONES.some(pattern => pattern.test(resourceArn))) return 'red';
  if (category === 'mutate' || category === 'delete') return 'yellow';
  return 'green';
}

const mutationCounter = new Map<string, number>();
const MUTATION_RATE_LIMIT = 10; // per 5-minute window

function checkMutationRate(agentId: string): boolean {
  const count = mutationCounter.get(agentId) ?? 0;
  mutationCounter.set(agentId, count + 1);
  return count < MUTATION_RATE_LIMIT;
}

async function enforceZonePolicy(
  agentId: string,
  resourceArn: string,
  category: string
): Promise<'permit' | 'gate' | 'block'> {
  const zone = classifyZone(resourceArn, category);
  if (zone === 'red') {
    await emitAuditEvent({ type: 'AI_FREE_ZONE_BLOCK', agentId, resourceArn });
    return 'block';
  }
  if (zone === 'yellow' && !checkMutationRate(agentId)) {
    await emitAuditEvent({ type: 'MUTATION_RATE_EXCEEDED', agentId, resourceArn });
    return 'gate';
  }
  return 'permit';
}

State Interaction Chart

flowchart TD A[Agent Proposes Tool Call] --> B{Zone Classification Check} B -->|Green Zone: Read-only| C[Auto-Permit + Trace] B -->|Yellow Zone: Low-risk Mutate| D[Permit with Structured Audit] B -->|Red Zone: AI-Free| E[Hard Block + Alert] D --> F{Mutation Rate Threshold} F -->|Under Threshold| G[Execute + Log] F -->|Over Threshold| H[Pause + Human Review] E --> I[Emit Violation Event] I --> J[Notify On-Call Engineer]

6. Agentic Code Review as a Scope Enforcement Discipline: Trust Is Earned, Not Configured

The same judgment that a senior engineer applies when reviewing AI-generated code — interrogating it rather than accepting it — needs to be formalized as a structural property of any agent that generates or modifies code inside your system.

Review is now the leverage point in AI-assisted engineering, and the same principle applies to agentic tool calls: the value isn't in the generation, it's in the evaluation of what was generated.
Trust tiers for agent outputs — where low-risk read-only operations auto-advance and code generation or mutation operations require a structured review step — mirror how senior engineers calibrate attention when reviewing AI-assisted PRs.
Coding agents with filesystem access are a special scope enforcement case: they can modify source files, add dependencies, and change build configs, all of which have downstream blast radii that a tool manifest must explicitly enumerate.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

Addy Osmani's framing of review as the most leveraged skill in software right now applies with particular sharpness to coding agents. Simon Willison's llm-coding-agent experiment demonstrates how quickly you can bootstrap a capable coding agent — which means the speed of generation has effectively been solved. The unsolved problem is building the review discipline into the agent's architecture, not just into the human reviewing its outputs. That means coding agents need scope manifests just like infrastructure agents: explicit declarations of which filesystem paths are in scope, which package registries are permitted, and which operations require a human checkpoint before being applied. Source: [Agentic Code Review] — Addy Osmani (https://addyosmani.com/blog/agentic-code-review/) and Source: [llm-coding-agent 0.1a0] — Simon Willison (https://simonwillison.net/2026/Jul/2/llm-coding-agent/#atom-everything)

AIThe through-line from vibe coding risk to agentic code review to tool scope enforcement is a single governance principle: speed of action without structure of review produces systems that are technically capable but operationally untrustworthy. Whether the agent is modifying Kubernetes workloads or editing TypeScript source files, the enforcement pattern is the same — declare what it's allowed to touch, gate what requires human judgment, and emit structured evidence of everything it did so the review that does happen is informed rather than performative.

Reference Architecture

// TypeScript: Coding agent scope manifest with filesystem path constraints
interface CodingAgentManifest {
  permittedPaths: RegExp[];
  blockedPaths: RegExp[];
  requiresGate: RegExp[];
  permittedPackageRegistries: string[];
  maxFilesPerOperation: number;
}

const codingAgentManifest: CodingAgentManifest = {
  permittedPaths: [
    /^src\/agents\//,
    /^src\/tools\//,
    /^tests\//,
  ],
  blockedPaths: [
    /^\.github\/workflows\//,    // CI config — AI-free zone
    /^infrastructure\/terraform/, // IaC — AI-free zone
    /^src\/auth\//,              // Auth logic — AI-free zone
  ],
  requiresGate: [
    /^package\.json$/,           // Dependency changes gated
    /^tsconfig.*\.json$/,        // Build config gated
  ],
  permittedPackageRegistries: ['https://registry.npmjs.org'],
  maxFilesPerOperation: 5,
};

function validateFileOperation(
  filePath: string,
  manifest: CodingAgentManifest
): 'permit' | 'gate' | 'block' {
  if (manifest.blockedPaths.some(p => p.test(filePath))) return 'block';
  if (manifest.requiresGate.some(p => p.test(filePath))) return 'gate';
  if (manifest.permittedPaths.some(p => p.test(filePath))) return 'permit';
  return 'block'; // default-deny for anything not explicitly permitted
}

State Interaction Chart

flowchart TD A[Coding Agent Proposes Change] --> B{Change Classification} B -->|Read or Test File| C[Auto-Apply + Trace] B -->|Source File Edit| D[Structured Diff Review] B -->|Dependency Add| E[Security Scan + Human Gate] B -->|Build Config Change| F[Hard Human Gate] D --> G{Review Outcome} G -->|Approved| H[Apply + Commit Trace] G -->|Rejected| I[Log Rejection + Update Agent Context] E --> J{Scan Result} J -->|Clean| D J -->|Flagged| K[Block + Alert]

7. Smart Model Routing as a Scope-Aware Trust Tier: Matching Model Capability to Action Risk

Routing cheaper models to low-risk tools and frontier models to high-risk decisions isn't just a cost optimization — it's a governance mechanism that encodes your trust hierarchy into the infrastructure layer.

Model routing and scope enforcement are naturally co-designed: the same manifest that classifies tools by risk category can drive the routing decision about which model is permitted to invoke which tool class.
Cheaper models for read-only operations reduces cost while also limiting the capability level that has ambient access to low-stakes tools — a constraint with mild but real governance value.
Frontier model access should be gated behind the same human-in-the-loop checkpoints you'd apply to high-risk tool categories, not because frontier models are less trustworthy, but because their outputs have higher downstream impact.

TECHNICAL DEEP DIVE & CODE ARTIFACTS Expand [+]

The smart model routing trend surfaced by Pragmatic Engineer is framed primarily as cost management, but the governance implications are worth pulling forward. If you're already maintaining a tool scope manifest that classifies tool categories by risk level, you have the primitives to add a model tier assignment to each category: read operations route to a smaller, faster model; mutate or delete operations route to a frontier model with a structured output schema and a human review checkpoint. This isn't a radical new architecture — it's a natural extension of the manifest-driven scope enforcement pattern into the model selection layer. Source: [The Pulse: a new trend, smart model routing] — Pragmatic Engineer (https://blog.pragmaticengineer.com/the-pulse-a-new-trend-smart-model-routing/)

AIThe convergence of model routing and scope enforcement creates a clean separation of concerns: the manifest defines what is permitted, the routing layer defines who is trusted to do it, and the audit trail captures both decisions. For a senior engineer building multi-agent systems where different agents may have different trust levels and different model assignments, this pattern gives you a single declarative structure that governs both dimensions simultaneously — which is exactly the kind of governance primitive that makes complex agentic systems auditable at scale.

Reference Architecture

// TypeScript: Scope-aware model router integrated with tool manifest
type ModelTier = 'fast' | 'frontier';

interface ModelRoutingPolicy {
  toolCategory: string;
  modelTier: ModelTier;
  requiresStructuredOutput: boolean;
  requiresHumanGate: boolean;
}

const routingPolicies: ModelRoutingPolicy[] = [
  { toolCategory: 'read',     modelTier: 'fast',     requiresStructuredOutput: false, requiresHumanGate: false },
  { toolCategory: 'diagnose', modelTier: 'fast',     requiresStructuredOutput: true,  requiresHumanGate: false },
  { toolCategory: 'mutate',   modelTier: 'frontier', requiresStructuredOutput: true,  requiresHumanGate: true  },
  { toolCategory: 'delete',   modelTier: 'frontier', requiresStructuredOutput: true,  requiresHumanGate: true  },
];

function resolveModelAndPolicy(toolCategory: string): ModelRoutingPolicy {
  const policy = routingPolicies.find(p => p.toolCategory === toolCategory);
  if (!policy) throw new Error(`No routing policy for tool category: ${toolCategory}`);
  return policy;
}

async function routeAndExecute(
  toolCategory: string,
  toolFn: (model: ModelTier) => Promise<unknown>,
  humanGate: () => Promise<boolean>
): Promise<unknown> {
  const policy = resolveModelAndPolicy(toolCategory);
  if (policy.requiresHumanGate) {
    const approved = await humanGate();
    if (!approved) throw new Error('Human gate rejected execution');
  }
  return toolFn(policy.modelTier);
}

State Interaction Chart

flowchart TD A[Tool Call Request] --> B{Scope Manifest Lookup} B --> C{Risk Category} C -->|Read / Diagnose| D[Route to Fast Model] C -->|Mutate| E[Route to Frontier Model] C -->|Delete| F[Route to Frontier Model + Human Gate] D --> G[Execute Tool] E --> H{Structured Output Valid?} H -->|Yes| I[Human Review Checkpoint] H -->|No| J[Reject + Retry with Validation] I -->|Approved| G F --> K[Human Approval Required] K -->|Approved| G