IA × IA / PLAYBOOK
PLAYBOOK · No. 07

Agent supervisor

More intelligence in the operator. Less power in whoever authorizes.
An operator agent investigates with broad context and proposes an action. A deliberately limited supervisor evaluates the request. A Policy Engine applies the objective rules before anything executes.
3 layersinvestigate, authorize and execute
AgentsGovernanceAutonomyPolicy Engine
Updated Oct 6, 2026
Download as MarkdownBuild your playbook from this caseJSON

The problem

An autonomous agent can query SIEM, EDR, IAM, WAF and cloud, correlate signals, and arrive at a solid hypothesis. The risk shows up when the same entity that investigates also decides, on its own, how far it can act.

The proposal is to separate roles and authority. The operator stays powerful for investigation. Authorization goes through a layer with a much narrower objective, less context, fewer tools and less authority.

Architecture

Operator agentThe more capable model. Investigates, correlates, builds a hypothesis, gathers evidence and requests an action.
Supervisor agentReceives only the context needed for one specific decision. Approves, denies or escalates.
Policy EngineApplies deterministic rules: allow and deny lists, authority, asset, identity, reversibility, TTL, schema and kill switch.
ActionExecutes only within the delegated authority. Outside it, a human is required.
The supervisor doesn't need to investigate better than the operator. It needs to decide something much narrower.

The contract between operator and supervisor

The operator doesn't hand the supervisor an entire conversation. It hands over a structured request with action, target, evidence, confidence and reversibility.

{
  "action": "revoke_session",
  "target": "user_8271",
  "evidence": {
    "credential_leak": "confirmed",
    "impossible_travel": true,
    "active_sessions": 3
  },
  "operator_confidence": 94,
  "reversible": true
}

The response is a contract too

{
  "decision": "APPROVE",
  "policy": "IAM-07",
  "scope": "user_8271",
  "ttl": "15m",
  "requires_human": false
}
Free text can explain. The authorization that moves on to the next layer has to respect a verifiable schema.

Same incident. Different authority.

Operational example
Request 1Block a malicious IP for 30 minutes
SupervisorAPPROVE
Policy EngineTemporary, reversible action within the delegated authority
OutcomeExecutes automatically
Request 2Disable the CFO's account
SupervisorMay consider the evidence sufficient
Policy EnginePrivileged identity and a high-impact action
OutcomeHUMAN APPROVAL REQUIRED

The authority matrix

Can be automated

  • Enrich and correlate alerts.
  • Build a timeline and gather evidence.
  • Temporarily block an IP within policy.
  • Revoke a session when identity, scope and reversibility are within the rule.

Escalates to a supervisor

  • Disabling a privileged account.
  • Changing a critical configuration.
  • Any action with a large blast radius.
  • Any irreversible or critical action.

Authority that is earned and lost

The authority to act without approval isn't a single level for the agent, and it isn't permanent. It is granted per action class, after the agent's decisions in that class have been compared against human review on a defined sample. The agent doesn't measure its own accuracy.

When verdicts start diverging from independent review beyond a threshold, the class drops back to its previous mode. The threshold, the observation window and who reviews are part of the contract, not left implicit.

Granted per classEnriching, blocking an IP for a limited time and revoking a session are separate classes. Each one levels up on its own, on its own evidence.
Independent evaluationThe sample of decisions is reviewed by someone who is neither the operator nor the supervisor. The agent doesn't grade its own exam.
Demotion triggerDivergence beyond the threshold demotes the class automatically. The demotion is executed by the platform, outside the model.
Actions in flightThe contract spells out what happens to what was already executed when a class drops a level: rollback, compensation, or just a record. Expiring the authorization doesn't undo what's already done.

The agent badge

What the badge declares

  • The agent's identity and its human owner.
  • The context it can query and the access it holds.
  • Authorized actions, per class, with each one's current level.
  • Required supervision, required evidence, and validity with an expiration.

What stays off the badge

  • The kill switch. The agent doesn't control its own shutdown.
  • Class demotion. The platform executes it.
  • The accuracy measurement. It comes from independent review.
  • An agent without an identity and bounded authority is a service account with too much power.

What actually reduces the risk

Narrow roleThe supervisor doesn't get an open-ended mission to investigate the whole incident. It evaluates one specific request.
Minimal contextIt receives only the data needed to decide, which shrinks the surface for interpretation.
Less authorityIt doesn't get free access to the environment and doesn't execute the requested action directly.
IndependenceObjective, context and contract should keep it from simply replaying the operator's chain of reasoning.
Deterministic controlObjective policies stay outside the LLM whenever they can be expressed as a rule.
Human by impactThe human comes in by exception, by policy or by impact. Anything irreversible or critical requires human approval.

A smaller model doesn't mean a safer model

A smaller model can work well as a supervisor because the task is narrow, but size is no guarantee of safety. The control comes from the architecture: limited role, minimal context, strict contract, less authority, independence and deterministic validation.

A second identical instance doesn't solve the problem on its own either. If the operator and the supervisor share the same assumptions, context and way of deciding, the second layer can repeat the same failure.

How to implement it

1. Catalog the actionsList what your agents can request: query, block, revoke, isolate, change or delete.
2. Classify impactDefine reversibility, criticality, blast radius, and protected identities or assets.
3. Define authorityMap each action to automatic, supervisor, or human approval.
4. Create contractsStandardize request and response with a verifiable schema and required evidence.
5. Pull rules out of the LLMAllow list, limits, TTL, scope, privileged identities and kill switch live in code or in a policy engine.
6. Log everythingRequest, evidence, decision, policy applied, execution, outcome, and any human intervention.
Takeaway: We're not setting up one AI to trust another AI. We're separating authority.
Take this playbook with you

In Markdown to paste into your AI, or as the starting point for your own playbook.

Download as MarkdownBuild your playbook from this playbookFull guide as .md
Open this playbook in your AIChatGPTClaudePerplexityCopilotGrok