The Agent Runtime Perimeter

AI agents are no longer just asking questions in a chat window. They are being pointed at internal databases, private APIs, ticketing systems, code repositories, customer records, and scheduled work. That is the shift operators need to notice.

The old question was whether an agent could connect to the tool. The new question is where the work executes after the connection exists.

That sounds technical, but it is really an operating question. If an agent can run code, call a private MCP server, read internal context, hold or proxy credentials, and update a system of record, the business has created a new execution lane. The model is only one part of that lane. The rest is runtime, network boundary, identity, tool exposure, evidence, review, and stop rules.

This is the agent runtime perimeter.

The perimeter moved from the network to the workflow

For years, the business security mental model was fairly simple. Some systems were inside. Some were outside. Employees crossed the boundary through login, device policy, VPN, SSO, and application permissions. The perimeter was imperfect, but at least people could picture it.

Agents make that picture less useful. An agent may be orchestrated by an external provider, execute inside a customer-controlled sandbox, reach internal systems through a tunnel, call tools through MCP, and act on behalf of a human user or a service identity. The boundary is no longer one wall. It is the path the work takes.

Anthropic’s May 2026 Managed Agents update makes this visible. The company introduced self-hosted sandboxes and MCP tunnels so enterprises can let agents access private systems without moving execution or internal resources outside their security boundary. InfoQ summarized the pressure clearly: organizations want autonomous agents, but they cannot allow “execution environments or internal systems to leave their security perimeter.” The same report notes that MCP tunnels let agents connect to private MCP servers “without exposing them to the public internet.”

That is useful. It is also clarifying. The market is not merely buying smarter agents. It is buying controlled places for agent work to happen.

The perimeter has become operational. It lives in the runtime, the connector, the identity broker, the approval flow, and the evidence trail. If those pieces are not named, the business does not actually know where the agent begins or ends.

Connectors are not the control system

MCP is valuable because it gives agents a standard way to reach tools and context. That is exactly why it needs an operating frame around it. A connector makes work possible. It does not decide whether the work is authorized, proportional, observable, or safe.

Cloudflare’s enterprise MCP architecture describes this in practical terms. Their internal approach moved away from local, employee-managed MCP servers because those created supply-chain, update, and governance risks. Instead, they describe managed remote MCP servers, portals, centralized logging, policy enforcement, DLP guardrails, and controls over which tools are exposed to which groups. The useful phrase is not the product language. It is the operating reality underneath it: discovery and governance had to become part of the platform.

Palo Alto Networks and CyberArk name the access problem from another angle. Their MCP access guidance warns that agents often sit in an identity blind spot and that unmanaged MCP servers can fragment authentication, token lifetime, policy, and audit logs. Their proposed control point is an identity broker between the AI agent and the MCP server. The reason is plain: instead of allowing the agent to directly hold credentials, the request can be proxied, authorized, audited, and governed.

That distinction matters for small businesses as much as enterprises. A small firm may not need an enterprise identity broker on day one. It still needs the concept. Do not let the agent quietly inherit broad keys just because the demo works. Decide whether the agent is using delegated human authority, an agent-owned account, a service credential, or a brokered path. Then decide what the agent can read, what it can write, what requires approval, and what evidence must be left behind.

The connector is the doorway. The control system is the set of rules that decides who may walk through it, carrying what, for which job, and with whose signature.

Security has to be substrate, not garnish

AWS’s AI Security Framework puts the timing problem bluntly: establish agentic identity and fine-grained access on day one. The same post summarizes the principle in a sentence operators should keep: “You aren’t adding security to AI. You’re building AI on top of security.”

That is the right order. Most agent projects get into trouble because the team treats security as the thing to add after the prototype proves value. The prototype gets broader access so it can look impressive. Then the impressive prototype becomes politically hard to slow down. By the time security arrives, the work pattern already depends on vague authority.

Agents punish that sequence because authority compounds quickly. A model with read-only access is one thing. A scheduled agent with private MCP access, write tools, customer data, and a weak stop rule is another. The jump from helper to actor is not a branding change. It is a change in the operating class of the system.

The practical answer is not to stop building. It is to make the runtime perimeter part of the build.

Before an agent touches private systems, the team should be able to answer seven questions.

1. Where does the agent’s work execute?
2. Which internal systems can it reach?
3. Which identity or credential path does it use?
4. Which tools are exposed, and are they read, draft, ask, or auto?
5. Who owns the agent and reviews its work?
6. What log or artifact proves what happened?
7. What condition makes the agent pause or stop?

Those questions are not bureaucracy. They are the minimum operating surface of a non-human worker.

The agent runtime permit

The easiest artifact is an Agent Runtime Permit. It is a one-page card issued before the agent receives access to private systems.

A work permit names the agent’s job. A runtime permit names the place and path of execution. It says: this agent runs here, reaches these systems, uses this credential path, sees these tools, writes only under these conditions, leaves this evidence, and stops when these signals appear.

The permit should be boring. Boring is good. Boring means an operator can inspect it before something breaks.

A useful permit has eight fields.

• Runtime: where the agent executes, including sandbox, cloud, local environment, or provider-managed orchestration.
• Perimeter: which private networks, services, APIs, repositories, databases, or SaaS systems are reachable.
• Identity: the agent name, human owner, account model, and credential path.
• Tools: the exposed tools, grouped as off, read, draft, ask, or auto.
• Trigger: the event, schedule, user request, or workflow state that starts the run.
• Evidence: the run log, ticket note, source list, approval record, or replay artifact the agent must leave.
• Review: the cases that require human approval or another control check before action.
• Stop rule: the exact condition that makes the agent pause, refuse, or escalate.

This is how Stephen’s “agents that actually work” position becomes concrete. The agent is not trusted because it sounds confident. It is trusted because the business can see the lane it is allowed to operate in.

What this looks like in a real workflow

Imagine a professional-service firm wants an agent to prepare client renewal briefs. The tempting build is obvious: connect the agent to email, CRM, project notes, billing, support tickets, and a document workspace. Ask it to summarize account health and prepare the next-step plan.

That agent may produce a beautiful first output. It may also cross boundaries nobody meant to give it. It might read billing context that should not shape the client message. It might pull stale notes. It might draft commitments that sound like approved business decisions. It might update a CRM field because the tool was available, not because the agent was authorized to change the record.

The runtime permit changes the design before the agent runs.

The agent executes in a managed sandbox. It can read CRM account summary fields, active project tickets, approved meeting notes, and support status. It cannot read billing disputes, HR notes, or private partner comments. Its credential path is brokered through an approved connector. Its tools are read-only except for creating a draft brief in a shared review folder. It runs every Thursday at 4 p.m. Its evidence is a source list, confidence note, and exceptions section. It requires human approval before any client-facing message or CRM update. It stops on conflicting records, missing source freshness, legal language, health or employment issues, billing disputes, or any request outside the renewal-brief job.

The agent is less theatrical. It is also safer, easier to review, and easier to improve.

Now the firm can expand carefully. Maybe the next version drafts a CRM update after review. Maybe later it creates an internal follow-up task when a confidence threshold is met. Each increase in authority is added to a known runtime lane instead of being smuggled in through another connector.

That is how agent autonomy compounds without turning into fog.

The control point is the product

The public language is converging. Anthropic is talking about self-hosted sandboxes and MCP tunnels. AWS is talking about agentic identity and fine-grained access on day one. Cloudflare is talking about MCP portals, logging, policy enforcement, and shadow MCP detection. Palo Alto and CyberArk are talking about identity brokerage and deterministic controls for a non-deterministic environment. Operators on public forums are asking the human version: who accessed the info, again?

They are all pointing at the same substrate problem.

Agents need a control point between intention and action. Not a meeting. Not a policy PDF. A real operating point in the path of work where identity, permission, tool exposure, approval, evidence, and stop rules can be enforced.

For some teams that control point will be an MCP portal. For others it will be an identity broker, an agent gateway, a sandbox boundary, an approval queue, or a workflow orchestrator. The product name matters less than the operating question: can the business see and govern the path from human intent to agent action to system change?

If the answer is no, the agent is not ready for more access.

Bottom line

The next wave of agent adoption will not be decided by who connects the most tools. It will be decided by who can define the runtime perimeter clearly enough that useful work can happen without invisible authority.

Before connecting the next private MCP server, write the permit. Where does the work run? What can it reach? Who owns the credential? Which tools are exposed? What gets logged? What needs approval? What makes the agent stop?

If those answers are clear, the agent has a lane. If they are missing, the connector is only creating a faster path into ambiguity.

Sources

• Anthropic / Claude, “New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels,” May 2026: https://claude.com/blog/claude-managed-agents-updates
• InfoQ, “Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems,” May 19, 2026: https://www.infoq.com/news/2026/05/claude-mcp-tunnels/
• AWS Security Blog, “The AWS AI Security Framework: Securing AI with the right controls, at the right layers, at the right phases,” May 15, 2026: https://aws.amazon.com/blogs/security/the-aws-ai-security-framework-securing-ai-with-the-right-controls-at-the-right-layers-at-the-right-phases/
• Cloudflare Blog, “Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP,” April 14, 2026: https://blog.cloudflare.com/enterprise-mcp/
• Palo Alto Networks / CyberArk, “Secure AI Agents — New Controls and Visibility for MCP Data Access,” May 12, 2026: https://www.paloaltonetworks.com/blog/identity-security/secure-ai-agents-controls-visibility-mcp-data-access/

Stephen Nickerson.
Built for operators who need agents they can test, trust, and improve.