How Do You Set Boundaries for AI Agents?

The most reliable way to escape shadow AI is to treat agents not as browser tabs, but as entities bound by a corporate contract. As we saw in How Many AI Agents Are Running in Your Company, Nobody Knows?, chatbots operating outside corporate infrastructure leave no trace and accept no accountability. In Why the Org Chart Must Include Agents?, we showed how agents belong in the org tree. But placing an agent on the chart is not enough. We must also define what lives inside that agent, what it is allowed to do, and how it is governed. This is where policy enters the picture.

Policy: The Contract Between Agent and Organization

When you hire a human, you write a job description. That document defines what the employee will do, what they will not do, how they will report, and which boundaries they must respect. AI agents have a digital equivalent: policy.md.

Policy is not merely a list of rules. It is a contract between the agent and the organization. The agent agrees to these terms before it operates. If it cannot comply, it does not run. A well-written policy defines:

• Behavior rules: What the agent can and cannot do, and which decisions it may make independently
• Data boundaries: Which files it may read, which databases it may query, and where customer data may be transferred
• Approval requirements: Which actions require human sign-off, such as approving an invoice, canceling an order, or creating a new account
• Communication rules: Which channels it may use and what tone or format it must follow

Without policy, an agent is an uncontrolled extension beyond the organization’s perimeter. With policy, it becomes an automated guardian of corporate rules.

State Management: Draft, Active, and Passive

Human employees go through onboarding, active service, and offboarding. Agents follow the same lifecycle, only automated.

Draft: The agent is defined but not yet active. Its policy is being tested, skills are validated, and it is being prepared for production. In this stage, it cannot take any action without human approval. This is the ideal phase for testing an agent in a staging environment.

Active: The agent is fully operational. Policy is enforced, every action is logged, and the parent node monitors it. It performs only its defined tasks and respects all boundaries.

Active: The agent is fully operational. Policy is enforced, every action is logged, and the parent node monitors it. It performs only its defined tasks and respects all boundaries.

Passive: The agent was once active but has been deactivated. All skills are suspended, data is preserved. It can be reactivated or permanently deleted. This state is ideal for seasonal or project-based agents that you may need again later.

This state management reinforces the tool-versus-agent distinction we emphasized in What Is an Agent: From AI Tool to AI Agent. A browser chatbot has no draft phase, no passive state, and no supervised activation. It simply runs, unchecked.

Skill Types and How Policy Gates Them

Policy defines what the agent cannot do. Skills define what it can. A policy without skills is an empty boundary; skills without policy is uncontrolled capability.

An agent’s capability set is expressed through three main types:

Builtin: Capabilities embedded in the agent’s core. Natural language understanding, math, code writing — these are native model abilities. They require no extra setup and are still bounded by policy.

MCP (Model Context Protocol): Standardized connections to the outside world. Querying a database, reading a file system, calling an external API — these are added via MCP. Every MCP connection must be approved by policy.

HTTP / Function: The agent’s ability to call custom functions or make HTTP requests. Recording an order to ERP, triggering an alarm, sending an email — these are defined as either custom functions or HTTP endpoints.

Before using any skill, the agent checks policy. If policy says “this agent can send emails,” the relevant HTTP or MCP skill is enabled. If policy says “no,” the agent cannot invoke that skill at all.

Hiring an Agent Should Be No Different From Hiring a Human

For human employees, hiring involves: job definition, authority assignment, rule teaching, monitoring, and evaluation. The same applies to AI agents.

Definition: The agent’s role, authority, and reporting line must be clear. As we saw in What Is an Agent: Tool vs Agent, unlike a tool, an agent must have a defined identity and a responsible_id.

Approval: The agent must pass policy review, have its skills validated, and be supervised by its parent node. Just as a human employee passes reference checks, an agent must pass its testing phase.

Activation: The agent moves to Active state only after approval. A draft agent does not participate in production. This process is backed by the responsible_id relationship defined in the org schema.

For humans, hiring is an action. For agents, it is the same. The only difference is that training a human takes longer than writing an agent’s policy. But the principle is identical: define, approve, activate.

Next Stop: How Agents Delegate to Each Other

Policy and state management enable an agent to work alone. But in real corporate environments, agents do not work in isolation. One agent needs another agent’s capability. A customer request arrives; the first agent classifies it, the second prepares a proposal, the third triggers the approval flow.

In our next post, we cover exactly this: how agents delegate tasks to each other, how approval flows work, and how results are controlled. The org schema, policy, and state management we built in previous posts converge right here.