Your AI Agent Needs Role Boundaries Before It Gets Tools

One agent should not plan the work, use the tools, approve the result, and save the memory.

That is not a multi-agent architecture question. It is a control question.

Most teams decide between one agent and many agents by asking what the model can handle. Can it reason through the task? Can it call the tool? Can it recover if something fails?

Those are useful questions. They are not enough.

The better question is simpler: where does authority change hands?

The Role Boundary Is The Control Boundary

An agent workflow has at least three jobs.

The planner decides what should happen.

The executor uses tools to make something happen.

The reviewer decides whether the proposed or completed action is acceptable.

Those jobs can live in one interface. They should not always live in one authority model.

If the task is low risk, reversible, and contained to drafting or analysis, one agent may be fine. If the agent can write files, send messages, call APIs, update records, deploy code, save memory, or touch private data, the workflow needs a boundary before tool access expands.

Current Frameworks Are Already Moving This Way

OpenAI's Agents guidance separates agent definitions, orchestration, handoffs, guardrails, results, state, and observability as workflows get more complex. Its guardrails and human review docs frame review as a decision point where a run can continue, pause, or stop.

The OpenAI Agents SDK also supports handoffs, where one agent delegates to another specialized agent. The security detail is easy to miss: handoffs are represented as tools to the model. A handoff is not just a clean design pattern. It is a routed action that can change who is acting and what authority is being used.

OpenAI's guardrails documentation adds another important detail. Tool guardrails apply to function tools, while handoffs use the handoff pipeline. Do not assume one generic tool guardrail automatically covers every transition between agents.

LangChain's human-in-the-loop middleware takes the same idea into tool execution. Teams can interrupt selected tool calls, such as file writes or SQL execution, before they run. Its deep agents guidance also supports conditional interrupts based on the tool call.

Microsoft Agent Framework exposes approval-required tools and workflow-level request-response patterns for human review before execution continues. The tool approval docs show approval-required functions. The workflow HITL docs show executors waiting for outside review before moving forward.

These are not only developer conveniences. They are workflow controls.

Excessive Agency Is What Happens When The Boundary Disappears

OWASP's Excessive Agency guidance names three root causes: too much functionality, too many permissions, and too much autonomy.

That maps directly to agent role design.

A planner with broad reasoning but no side-effect tools is safer than a planner that can also write to production systems.

An executor with one approved task and narrow tool access is safer than an executor that can reinterpret the plan mid-run.

A reviewer with the proposed action, source evidence, tool trace, and rollback path is safer than a human asked to approve a vague summary.

This does not make prompt injection go away. Guardrails are not magic. But it reduces blast radius when the model misunderstands the request, trusts the wrong source, or follows an instruction embedded in untrusted content.

A Practical Split

Use this pattern when a workflow can create side effects.

Planner:

• Reads approved context.
• Produces a plan, assumptions, source labels, proposed tool calls, and stop conditions.
• Has no write, send, deploy, purchase, or memory-update tools.

Executor:

• Runs one approved action at a time.
• Uses only the tools needed for that action.
• Returns raw tool results, source labels, and evidence.
• Cannot expand scope without review.

Reviewer:

• Approves, rejects, edits, or escalates.
• Compares the action against the plan, policy, source evidence, and trace.
• Decides whether state should be saved, discarded, or quarantined.

The point is not to make every workflow heavy. The point is to make authority visible.

When To Split Roles

Split planner, executor, and reviewer responsibilities when any of these are true:

• The agent can write, send, buy, deploy, delete, or update records.
• The workflow touches private, regulated, credential, customer, or production data.
• The agent can call MCP servers, browser tools, shell tools, databases, ticketing systems, email, or external APIs.
• The agent can persist memory or update an eval, log, ticket, or knowledge base.
• The same agent is planning the work, using the tools, and judging whether the result is acceptable.

For VibeSec Advisory's field-guide model, this fits inside governed AI workflows: map the process, name the owner, define the data boundary, assign the action limit, and make the approval point visible before the agent gets more authority.

The operating rule is direct.

Let agents think broadly when the cost is low. Let them act narrowly when the cost is real. Make a separate role responsible for saying no.

Sources

• OpenAI Agents SDK overview
• OpenAI guardrails and human review
• OpenAI Agents SDK handoffs
• OpenAI Agents SDK guardrails
• LangChain human-in-the-loop middleware
• LangChain deep agents human-in-the-loop conditional interrupts
• Microsoft Agent Framework overview
• Microsoft Agent Framework workflow HITL
• Microsoft Agent Framework tool approval
• NIST AI Risk Management Framework
• NIST AI RMF Generative AI Profile
• OWASP Excessive Agency
• Microsoft Human-AI Interaction Guidelines
• Microsoft Research Human-AI Interaction Guidelines