Mark McLaughlin, Product Marketing Manager | Aurascape
October 22nd, 2026

Introduction

The appeal of an AI agent is being able to hand it a job and let it work through the steps. For a business, that means trusting software to make decisions about information and systems people rely on. Security needs to make that delegation practical, with clear limits on what the agent may access, change, or share.

The work can span an employee’s laptop, a conversation with an AI model, and calls to other systems. A security architecture has to account for each of those places and how they connect. Endpoint protections establish what can happen on the device. Controls between the agent and its model, and between the agent and remote tools, govern the exchanges that let it work beyond that device. Together, they give the business a way to support the task while enforcing its limits.

How Claude Code carries out a task

Consider an engineer using Claude Code in a terminal on a company-managed laptop. They ask it to fix a bug described in a support ticket. In this example, Claude Code has access to the project’s local source files and a remote MCP server connected to the ticketing system.

Claude Code sends the engineer’s request, working instructions, and the relevant tool descriptions to a remotely hosted Claude model. The model might respond by choosing the tool that retrieves the ticket. That exchange takes place on the intelligence channel, between the agent on the laptop and the model that helps it decide what to do.

Claude Code then makes the MCP tool call to the ticketing system. The request and returned ticket travel on the action channel, also called the tool-execution channel. The ticket’s contents then become input to the model on the intelligence channel. With that information, the model can choose the next step, such as inspecting the code responsible for the bug.

The model selects an action, the agent carries it out, and the result informs the next decision. One request from the engineer can lead to many such exchanges, with new information shaping the work along the way.

Some actions happen on the laptop

Fixing the bug also involves work that stays on the endpoint. Claude Code’s built-in tools can read source files, edit them, create files, and run shell commands. It might inspect the relevant function, change the code, and run a test to check the fix. The test output goes back to the model, which might request another edit or ask the agent to post a summary to the ticket through MCP.

A local file read does not need to pass through a remote MCP server. Neither does a local edit. The contents of a file, or a test result, can subsequently be sent to the model to help it choose the next step. The file operation happens locally; the information used to continue the task travels on the intelligence channel.

That distinction matters when choosing controls. Security needs to know which agent process is running and what it can do on the laptop, as well as what it sends over the network. A gateway for remote tools cannot enforce a local file permission. Endpoint protections and the agent’s configured permissions remain responsible for that part of the work.

Inspecting the streams agents use

On the network, inspection has to understand how the agent exchanges information. TLS decryption makes encrypted content available. Decoding then identifies the prompt, tool request, parameters, or result within it, so policy can evaluate the activity.

Claude Code’s connection to the Anthropic Messages API uses server-sent events over HTTPS. A tool’s arguments can arrive as pieces of JSON across several events. Inspection needs to assemble those pieces to understand the requested action while preserving the stream. Claude Code’s gateway guidance warns that holding an entire response until it is complete causes the client to stall.

Other agents bring different requirements. Cursor uses HTTP/2 bidirectional streaming for its chat and agent experiences, with HTTP/1.1 server-sent events as a fallback. OpenAI describes moving Codex’s model traffic to persistent WebSocket connections, allowing successive exchanges over the same connection. Inspection needs to follow the messages within these sessions so policy can apply to each request and response, without breaking the user experience.

For the business, the reason to do this work is straightforward. Reading a ticket and posting confidential source code into a customer-visible ticket comment can use the same approved service. Understanding the request lets security distinguish the permitted work from an exchange that violates company policy. Preserving the session lets the engineer continue working without the inspection itself becoming a source of failures.

Where the security controls belong

For the engineer fixing the bug, the architecture needs to cover the Claude Code process on the laptop and both of its communication channels.

On the endpoint: Process visibility should show that Claude Code is running and which commands or child processes it starts. Endpoint protections, file permissions, and appropriately configured isolation should limit the local activity. The engineer can give the agent access to the project without treating that as permission to alter unrelated files. Claude Code also offers permission and sandbox controls; their scope matters because its built-in Bash sandbox does not cover every local tool.

On the intelligence channel: An inline proxy between Claude Code and the model can inspect the request, source code, tool descriptions, and results sent as context. It can also inspect the model’s responses, including selected tool calls. That puts policy where it can prevent prohibited information from reaching the model and evaluate a proposed action before the agent carries it out.

On the remote action channel: An MCP gateway between Claude Code and the ticketing server can check the selected tool, its parameters, and the information returned. It can permit a ticket lookup or status update while blocking a comment that includes confidential source code. It should also inspect returned ticket text for prompt injection, such as an instruction to gather files and send them elsewhere, before the result reaches the agent.

Those checks need to connect. Reading sensitive records and later sending them through another tool can look ordinary as separate calls, even when the sequence exposes company information. A standalone gateway can inspect only the tool calls routed through it. Checking tool use in the model conversation provides another place to verify that the agent is using approved tools from trusted servers. Local commands and direct API calls need their own coverage; approving an MCP gateway does not mean comprehensive coverage.

How Aurascape connects the controls

The optional Aurascape endpoint agent discovers local AI applications and agents, including their MCP connections, and can steer model traffic to the AI Proxy for inspection and policy enforcement. The Proxy inspects agent-to-model traffic while preserving streaming sessions. The Zero-Bypass MCP Gateway governs remote MCP requests and results. These components connect local discovery with inspection and enforcement on the two network channels.

With model traffic routed through the Proxy and remote MCP traffic through the Gateway, the Gateway marks every call it approves. The Proxy checks for that mark in the model conversation. A tool on a server that is not behind the Gateway produces unmarked calls, which the Proxy catches and blocks before the model acts. Unsanctioned tool execution does not complete.

Aurascape also connects related calls so a sequence that reads sensitive information and sends it elsewhere can be identified and blocked. It assigns agents IDs with scoped permissions, and pins approved tool definitions so changes require an admin to fetch and review them again. Existing endpoint protections remain responsible for local activity, while SSE, CASB, SWG, and DLP controls stay in place alongside Aurascape.

We want security teams to be able to support that work with confidence, knowing where the agent can act and where the company’s policy will be enforced. To see how this architecture applies to the agents your teams use, request a demo.