# How Should Enterprises Set Boundary Controls for AI Agents in 2026?

Savannah Jenkins · September 24, 2026

> The Direct Answer: Treat AI Agents as Untrusted Remote Users Enterprise AI agent boundary controls are the technical and organizational limits that...

## The Direct Answer: Treat AI Agents as Untrusted Remote Users

Enterprise AI agent boundary controls are the technical and organizational limits that constrain what an autonomous or semi-autonomous agent may read, execute, communicate, purchase, modify, or retain. The direct answer is to treat agents as untrusted remote users: give each one a named identity, narrowly assigned permissions, time-bounded credentials, restricted tools, spending limits, and an independently enforced policy layer. The enforcement point should sit outside the model, because a prompt instructing an agent to respect rules is not a security boundary. By September 2026, the relevant architecture is no longer simply model selection or chatbot governance; it is a control system connecting identity, data access, action approval, observability, and incident response.

**Also worth reading:** [What are the definitive agent authentication protocols for 2026, and how do enterprises secure autonomous AI agents?](https://agustin-otegui.com/knowledge/what_are_the_definitive_agent_authentication_protocols_for_2026_and_how_do_enterprises_secure_autonomous_ai_agents.php) · [What is non-human identity lifecycle management for AI agents and how should enterprises architect it in 2026?](https://agustin-otegui.com/knowledge/what_is_non-human_identity_lifecycle_management_for_ai_agents_and_how_should_enterprises_architect_it_in_2026.php) · [What Is an Agentic AI Control Plane and How Should Enterprises Build One?](https://agustin-otegui.com/knowledge/what_is_an_agentic_ai_control_plane_and_how_should_enterprises_build_one.php)

A useful boundary distinguishes permission from instruction. An instruction says, “Do not transfer customer records,” while a permission prevents the transfer because the runtime credential lacks access to the destination, the file size exceeds 10 MB, or the action requires approval from a data owner. Agents can misinterpret natural-language policies, be manipulated through untrusted content, or pursue an objective through an unintended sequence of actions. This is why enterprises should enforce deterministic rules in gateways, operating-system controls, databases, cloud services, and agent runtimes. A model may be helpful and compliant most of the time, but probabilistic behavior cannot carry the full responsibility for regulated access.

The operating model matters as much as the tooling. A boundary is effective only if security, data, risk, legal, and business owners agree on which actions can be automatic and which require human review. A small team can begin with read-only agents and low-risk workflows, but it should expand autonomy only after measuring denied actions, attempted policy violations, tool-call accuracy, and incident frequency. The goal is not maximum restriction; excessive friction can push teams toward shadow deployments. The appropriate target is bounded autonomy, where approved business objectives are possible without granting indefinite authority.

## How the Controls Work and Why Old Security Patterns Are Not Enough

Boundary controls operate at several points in an agent’s action path. The orchestration layer receives the user’s objective and decides which models, tools, and contexts are available. A policy enforcement point then evaluates identity, purpose, data classification, environment, action type, destination, and accumulated risk before the tool executes. A browser agent requires site-level and action-level restrictions, while a coding agent needs file, repository, command, package registry, secret, and deployment controls. An agent that sends email needs sender verification, recipient restrictions, content inspection, attachment scanning, and approval rules for external recipients.

Traditional access management remains necessary, but agent behavior adds new problems. A human user normally works through a relatively stable interface; an agent can call an API repeatedly, compose several otherwise permitted steps into a harmful sequence, or change the parameters of a tool call thousands of times. Rate limits are therefore both availability controls and abuse controls. Reasonable starting thresholds might be 20 tool calls per minute for ordinary workflows, 5 external messages per hour for an unattended sales agent, or 3 high-risk actions before human approval. These are design defaults, not universal standards, and should be adjusted through testing.

Provenance and context should also affect authorization. An agent acting on a verified internal ticket can receive different permissions from one operating on text copied from a public website. Session credentials should be short-lived, rotated, and scoped to the active task rather than stored permanently in prompts or tool descriptions. High-impact tools should require stronger evidence than read-only tools, creating a simple privilege ladder. Examples include read access to approved documentation, then draft creation, then external publication, with human approval required only at the appropriate transition. Independent telemetry should record the policy decision, tool arguments, result, model and prompt version, and approving identity.

This approach is consistent with enterprise guidance from organizations such as IBM, Oracle, PwC, and BCG, which frame agent governance as a shared-responsibility problem across platforms, teams, and vendors. A control plane can coordinate these decisions, but it does not eliminate enforcement in the systems that own the resources. If the policy says “do not delete production data,” the database or infrastructure environment must enforce that decision even if the agent platform is unavailable.

## A Practical Control Architecture for Enterprise Agents

The recommended architecture has six connected functions: inventory, identity, policy, execution mediation, observability, and response. First, maintain a registry of every agent, owner, business purpose, model provider, tool, data source, deployment environment, and autonomy level. Unknown or unregistered agents should receive no production credentials. This registry can initially live in a configuration database, but it should become integrated with CI/CD, cloud catalogs, identity providers, and procurement records. Without an owner, an agent becomes difficult to disable and nearly impossible to hold accountable.

Identity should be workload-specific. Agents should not impersonate employees or share a broad service account, because individual attribution becomes impossible and revocation becomes coarse. Use separate credentials for development, testing, and production, with production access granted only through approval workflows. Secrets should be issued just in time through a vault or secrets manager and never printed into logs. Where supported, use cryptographic workload identity and short-lived tokens. For legacy tools that lack modern authentication, place a controlled adapter in front of the tool rather than exposing the target system directly.

Execution mediation belongs beside the action, not merely beside the conversation. The agent requests an action; the broker checks the policy, executes it, and returns a sanitized result. Approved read operations can proceed automatically within limits, while writes to production, external communication, financial transactions, permission changes, and destructive operations should use a stronger approval path. Human reviewers should receive a compact description of the requested action, affected resources, expected cost, data involved, and reason. A reviewer who receives an unexplained tool trace will approve mechanically, which defeats the control.

Logging should support both investigations and routine improvement. Store a tamper-resistant record of requests, policy evaluations, approvals, tool calls, outputs, errors, and revocations. Apply retention rules based on data classification and legal requirements, because audit records can themselves contain sensitive prompts. A weekly review of denied or unusual actions is more useful than accumulating millions of logs no one examines. A pilot can use 30 days of telemetry to establish baselines, but it should not wait six months before addressing an obvious privilege problem.

## Comparing Enforcement Models and Alternatives

Enterprises usually have four main choices: prompt-based restrictions, conventional application controls, agent-specific policy runtimes, and a combination. Prompt restrictions are inexpensive to add but unsuitable as the only defense. Conventional IAM and API gateways provide proven enforcement, although they may lack context for multistep agent behavior. Agent-specific runtimes can evaluate model, tool, prompt, and session signals, but introduce another platform to secure and operate. Most production environments require conventional controls plus agent-aware mediation rather than a complete replacement of existing security architecture.

| Feature | Prompt Instructions Only | Existing IAM and API Controls | Agent Policy Runtime | Combined Architecture |
| --- | --- | --- | --- | --- |
| Enforcement reliability | Depends on model behavior | High at the resource layer | High for agent-specific rules | Highest coverage across decisions and resources |
| Deployment effort | Low initially | Medium to high | Medium | High initially, reusable across agents |
| Context awareness | Natural-language but inconsistent | Strong identity, limited task context | Strong session and action context | Rich context with deterministic resource enforcement |
| Multistep risk detection | Weak | Requires custom logic | Designed for sequences and tools | Correlated detection across layers |
| Human approval support | Basic or absent | Available in some systems | Typically task-aware | Evidence-rich, resource-specific approval |
| Best role | Helpful guardrail, not a boundary | Last-line resource protection | Agent decision and action control | Recommended production pattern |

Browser agents and coding agents expose different risks, so no single product category solves every requirement. Browser controls can block navigation, form submission, downloads, clipboard access, and credential entry, but they cannot guarantee that content displayed to a user is correct. Coding agents can restrict paths and commands, yet sandboxing one process does not automatically protect a container, cloud account, or deployment pipeline. Managed agent platforms may speed delivery, but buyers should ask whether policies can be exported, whether logs are portable, and whether the provider can technically bypass customer-defined controls.
A lower-cost alternative is a small internal gateway built from an API gateway, open-source policy tooling, and cloud-native identities. It may fit a 5–20 person pilot, but operating a high-availability policy service becomes expensive once it supports hundreds of agents. Commercial platforms can reduce integration work, although subscription prices are rarely the total cost. Evaluation should include engineering time, audit integration, policy maintenance, model observability, security review, and the cost of reviewing risky actions. Cheaper software is not cheaper if exceptions accumulate faster than the team can review them.

## Implementation Steps That Work for Regulated and Business-Critical Agents

Begin with classification rather than procurement. Classify intended agents by autonomy, data sensitivity, reversibility, and financial or physical impact. A read-only internal research assistant is a different risk class from an agent that can issue refunds or modify production infrastructure. For a typical first production workload, limit the agent to 3–5 tools and 2–3 approved data sources. Require at least two-person approval for actions above a defined threshold, such as moving more than $1,000, deleting more than 100 records, or publishing to an external audience.

Next, create a threat model using concrete misuse cases. Consider prompt injection embedded in a web page, poisoned documents, credential theft through a tool response, excessive API spending, unauthorized data transfer, and an agent taking a valid action in the wrong context. Test whether changing a message, tool result, account, or location causes a policy failure. Red-team the orchestration, tool adapters, identity system, and approval interface; evaluating only the model misses many of the most consequential defects.

Policies should be versioned and tested before deployment. A practical rollout uses four environments: local development, isolated testing, a limited production group, and broad production. The limited group might contain fewer than 10 users for the first 2–4 weeks, with rollback available in under 15 minutes. Track task completion, unauthorized-action attempts, false approvals, tool-call latency, average human review time, and cost per successful task. Expand only when controls are both effective and operationally usable. If agents need approval for every minor step, the process may be safe but economically weak and prone to unsafe rubber-stamping.

Finally, connect the controls to existing governance. Security teams should own enforcement standards, data owners should authorize access, business owners should accept residual risk, and legal teams should review external commitments. Vendors should provide audit access, incident notification, data-location details, and evidence for their subprocessors. An annual control review is insufficient for fast-changing agents; a quarterly review is more realistic, with immediate review after a new tool, model, data source, or material autonomy increase.

## Common Mistakes That Create False Security

The most common mistake is calling a system prompt a security control. Prompts can improve behavior and communicate expectations, but they can be overridden indirectly through untrusted content and provide no reliable prevention of a permitted tool call. Another mistake is granting one agent identity access to every tool required across different teams. This creates a large blast radius and hides whether a particular action belongs to the agent’s actual purpose. Permissions should be granted to an agent version and task, then reviewed when those purposes change.

Teams also underestimate non-model attack paths. A powerful model does not need shell access if it can read a deployment token from a repository. A safe model can still be dangerous when connected to an API with broad write permissions. Overlapping orchestration frameworks, personal browser profiles, shared developer accounts, and copied secrets can bypass a carefully designed gateway. Shadow agents are particularly problematic because they often appear in side projects or employee productivity tools before receiving official review.

Overshooting in the other direction is equally wasteful. Blocking every external action can make an agent unable to perform useful work, while allowing every action and observing afterward provides little prevention. “Human in the loop” should not be used as a decorative checkbox; the reviewer must have enough time, evidence, and authority to reject the action. Automation bias, alert fatigue, and unclear approval requests turn nominal oversight into ceremonial approval.

Measurement errors can make these problems harder to detect. Counting prompts rather than actions obscures risk, and counting successful tasks without denominator data can conceal rising costs or unsafe behavior. Track a defined denominator such as tool calls, active users, transactions, or completed workflows, and report both failure and exception rates. A mature program distinguishes model errors, tool errors, policy denials, human overrides, and incidents rather than combining them into one accuracy number.

## When to Act, What It Costs, and What Good Governance Achieves

Act immediately when an agent can access confidential information, make external commitments, spend money, change permissions, deploy code, or affect physical or safety-relevant systems. A useful trigger is not merely “the model is large enough,” but “the consequence of an unintended action is material.” For lower-risk internal drafting or summarization, a lighter process can be justified, but identity, data handling, logging, and an off switch still apply. Organizations should not wait for a public breach to discover that no one owns the agent or can revoke its credentials.

There is no dependable universal market price for enterprise AI agent boundary controls because the total cost depends on existing IAM, cloud, logging, and security investments. For planning purposes, many organizations reserve roughly 5–10% of an agent platform’s first-year budget for control integration, testing, and monitoring, while pilots may absorb substantially more engineering effort than license fees. This is a planning heuristic, not a vendor benchmark. Commercial runtime subscriptions may be priced per user, agent, action, or protected workload, and cloud policy services can add storage, API, and telemetry charges. Procurement should demand a transparent cost model before allowing high-volume tool calls.

The expected benefit is not perfect prevention. No architecture guarantees that every agent decision is correct, and vendors’ claims about policy enforcement should be tested against direct tool access and deployment configurations. Good governance produces smaller blast radii, faster revocation, better evidence, and predictable recovery. It also lets the business increase autonomy gradually rather than choosing between an unrestricted agent and a manual process. The decisive metric may be the share of risky actions prevented or reviewed, not the number of agents deployed.

By late 2026, the defensible enterprise position is that agent permissions are temporary capabilities, not permanent properties of a chatbot. Start with low-risk, read-only workloads; enforce controls at the resource; measure real action paths; and expand only with evidence. Enterprises that wait for agent standards to settle can still make progress, because identity, least privilege, data classification, approval, and audit are durable controls that do not depend on a particular model or vendor.

## Quick answers

### What are the most important boundary controls for enterprise AI agents?

The most important controls are named workload identity, least-privilege access, short-lived credentials, tool restrictions, data filtering, rate limits, human approval for high-impact actions, and tamper-resistant audit logs. These controls must be enforced by systems outside the model, because prompt instructions alone can be bypassed or misinterpreted.

### How can an enterprise prevent an AI agent from deleting production data?

Do not grant the agent direct production deletion permissions. Route the action through a policy-enforcing tool that checks role, environment, affected record count, time, and approval status, then execute it with a separate service identity that is itself restricted. Test the control with direct API calls, altered parameters, retries, and compromised tool descriptions rather than testing only the chat interface.

### Are system prompts a security boundary for AI agents?

No. System prompts can guide behavior and provide warnings, but they are probabilistic instructions inside the same model that processes untrusted context. Production security requires independent enforcement in gateways, databases, operating systems, cloud IAM, and tool brokers, with prompt instructions used only as an additional behavioral guardrail.

### What is a safe first production use case for an enterprise agent?

A read-only internal research or drafting workflow is usually safer because actions are reversible and data exposure can be constrained. Limit it to a few tools and approved sources, disable external publication, and begin with fewer than 10 users for 2–4 weeks. Expand autonomy only after reviewing denied actions, errors, review time, cost, and incident signals.

### How much do enterprise AI agent governance controls cost?

There is no universal price because pricing and integration costs vary by deployment. A practical planning heuristic is to reserve about 5–10% of the first-year agent budget for control integration, testing, logging, and monitoring, then calculate review labor and cloud telemetry separately. Vendors may charge by user, agent, action, workload, or protected resource.

Canonical: https://agustin-otegui.com/knowledge/how_should_enterprises_set_boundary_controls_for_ai_agents_in_2026.php
Markdown: https://agustin-otegui.com/knowledge/how_should_enterprises_set_boundary_controls_for_ai_agents_in_2026.php/index.md