You ask an AI agent to compare the plans offered by three SaaS companies. A few minutes later, it returns a tidy table with prices, features, and limits.
The task is complete. Nothing appears to have gone wrong.
Now ask a different set of questions. Which services did the agent contact? Which systems saw the search terms, page content, or API credentials? Did any of that information enter a third-party log?
Many teams cannot answer with confidence.
The fastest way to find an over-permissioned agent is usually not to read its tool manifest. It is to trace one complete task.
A tool configuration tells you what an agent is allowed to do. Request logs show what it actually did.
One Research Task Can Create Several Data Paths
A user enters one instruction, but the agent may complete a long chain of actions behind the interface.
It may send the query to a search service, open several pages, extract the useful text, and pass selected sections to a model. The browser can also load fonts, analytics scripts, and other third-party resources. An MCP tool may contact another service, while an observability platform records tool names, arguments, results, and errors.
Each system sees a different part of the task.
The search provider may receive only the query. The SaaS websites can see the visitor’s IP address, browser headers, and cookies. The model provider may receive the prompt and selected page text. A logging service might store URLs, tool outputs, or complete error messages.
Most of these connections may have a valid purpose. The problem begins when nobody on the team can explain why a destination appears in the workflow.
An unfamiliar domain is not automatically malicious. It could belong to a content delivery network, a remote browser service, or an error-monitoring tool. Before judging it, identify which component made the request and what information the request carried.
A Simple Egress Map Is More Useful Than a List of Permissions
Agent reviews often begin with permission names: browser, search, files, email, or CRM. Those labels are convenient for configuration, but they say little about the path taken by the data.
A more useful record is a data-flow and egress map. In this context, “egress” simply means traffic leaving the agent’s environment.
The map does not need to become a complicated architecture diagram. For the SaaS comparison task, a hypothetical version might look like this:
| Destination | Initiated by | Data sent | Required? |
| Search API | Agent runtime | Search query | Yes |
| SaaS website | Browser | URL, headers, cookies | Yes |
| Model API | Agent runtime | Prompt and selected page text | Yes |
| Analytics endpoint | Web page | Page and browser metadata | Review |
The domain names matter, but the relationship between the data and the component sending it matters more.
An analytics endpoint, for example, may have been loaded by the SaaS website rather than the agent platform. Meanwhile, a familiar model endpoint could be receiving a page section that should have stayed inside the company network. Looking only at the reputation of each domain would miss that difference.
The map should also record which credential was used, where logs are stored, and what happens when a service fails. Some agents switch to another tool when the first choice is unavailable. The task still finishes, so the user may never notice that the data took a different route.
Browser Logs Show Only Part of an Agent’s Traffic
When an agent runs through a local Chrome browser, the Network panel in DevTools is a sensible place to begin. It records page requests and can display headers, payloads, cookies, initiators, and responses. Developers can also export the requests as a HAR file. The Chrome Network panel documentation explains these features in more detail.
A HAR file, however, is not a complete record of an agent’s traffic.
The agent runtime may send model API requests directly. Server-side search calls, MCP requests, background workers, and log uploads can bypass the browser. If the agent uses a remote browser, DevTools on the developer’s laptop will not reveal everything happening inside the remote session.
A first review does not need to become a full network investigation. In most cases, three sources provide a workable view: browser requests, the agent runtime trace, and the history of MCP or other tool calls.
Put those records on the same timeline. If a model call occurs just after the browser reads a pricing page, check which parts of that page entered the prompt. If an MCP tool contacts another API a few seconds later, identify the credential and permission scope used for that request.
The sequence often explains more than any single log.
MCP Makes Tool Access Easier, but It Can Blur Credential Boundaries
An MCP server may act on a user’s behalf when it connects to a third-party service. Problems arise when the server accepts a token from the client and passes that same token to another API without checking who the token was created for.
The current MCP authorization specification requires services to validate that a token was issued for the intended resource. It also rejects unverified token passthrough. This separation helps prevent misuse and creates a clearer audit trail: investigators can see which client used which server to reach a service. The MCP authorization security guidance describes these requirements.
Not every team can build a separate authentication system for every tool immediately. A practical starting point is to make each credential narrow enough for its task and easy to revoke on its own.
An agent that reads public product pages should not inherit access to a production database, internal drive, or deployment platform simply because those credentials already exist in the same environment.
This is one reason agent security goes beyond checking whether a chatbot produces a bad answer. The OWASP Top 10 for Agentic Applications includes tool misuse, agent behavior hijacking, and identity or privilege abuse among its major risk areas. Once a model can take action, an error can travel through real permissions.
Encryption Protects the Route, Not the Choice of Destination
When an agent runs on an employee laptop, hotel Wi-Fi, or a shared office network, a VPN can encrypt traffic between the device and the VPN server. It protects part of the network route. It does not decide whether the agent should contact a particular service.
The wrong destination can still use an encrypted connection. An agent can also send sensitive content to a poorly authorized API through a protected tunnel. Transport security and destination approval are separate controls.
The issue becomes more complicated when an agent can change the network state itself.
Checking the current IP address is a read action. Connecting to another location, changing the network exit point, or disconnecting is a state-changing action. It may affect later browsing, synchronization, and other applications on the same device.
Network-changing tools should be treated more like file writes or account changes than simple lookups. The workflow should record the original state, authorize the change for a specific task, and restore the previous state when the task ends.
Trace One Low-Risk Task from Start to Finish
The first audit should not involve customer records, production API keys, or confidential documents. Choose a task based on public information, then use a test account and credentials with a limited scope.
Create a new test session and note the start time. Do not delete older logs. They are part of the audit history, and removing them is not required to create a clean test window.
Give the agent one fixed prompt and let it finish without adding instructions halfway through. Then collect the browser requests, runtime trace, and tool-call history. Place them in time order and mark each handoff.
For every outside destination, record the component that started the request, the type of data sent, the credential used, the reason for the connection, and the person or team responsible for that service.
Suppose the browser opens a pricing page at 10:02. At 10:03, the runtime sends a pricing table to the model. The model then asks for a second search tool, and an MCP server contacts another API at 10:04. That short timeline exposes three separate trust decisions that the original prompt never showed.
An unexplained connection needs investigation, not an immediate accusation. Determine whether it belongs to the page, the browser infrastructure, the model provider, or a monitoring service.
If the destination appears unnecessary, block it only in a sandbox or staging environment. Watch whether the agent stops, reports an error, or quietly chooses another tool. A fallback route may create a new data path rather than remove the old risk.
One test cannot prove that the agent will always behave the same way. Different prompts, failures, and tool combinations may produce different routes. The audit still gives the team something valuable: the first verified record of how a real task moved through the system.
Every New Destination Should Require a New Decision
An egress map becomes stale if it remains an audit document that nobody uses.
Confirmed services can be added to an approved destination list. Tools should use credentials that are limited in scope and can be revoked separately. Logs containing prompts, tokens, or page content need redaction and a clear retention period. Tools that change files, accounts, networks, or outside systems should face stricter approval than read-only tools.
Server-side MCP clients also need protection from redirects, private network addresses, and cloud metadata endpoints. Official MCP security guidance recommends measures such as URL validation, private-address restrictions, egress proxies, and network policies. A domain allowlist can help, but it cannot handle DNS rebinding, redirect chains, or changing infrastructure on its own.
A team does not need to build a huge agent-security program before it learns anything useful. Start with the workflow people use most. Trace each handoff, explain every destination, and turn the result into default rules.
Every new place an agent can send data creates another trust relationship. That destination may be entirely reasonable, but it should exist because someone made a clear decision—not because someone happened to notice it in a log months later.
