What Is an Agent Proxy? Access Control for AI Tool Calls

What Is an Agent Proxy?

An agent proxy is a forward proxy for AI agents. A forward proxy acts on behalf of a client: instead of the client reaching a service directly, its requests pass through an intermediary that can inspect, modify, or block them. Network teams have used this pattern for years in the form of an egress proxy that mediates outbound traffic and enforces policy on each request before it leaves the network. An agent proxy applies the same shape to an AI agent. The agent is the client, the app (Gmail, Google Calendar, Drive, a database) is the service, and the proxy sits in between.

The difference from a network proxy is what it understands. A network proxy sees packets and hostnames. An agent proxy sees the tool call: which app the agent wants, which action it wants to take (read, send, delete), which records it is asking for, and on whose behalf. That is the level at which an access decision actually means something. "Allow this agent to read the last thirty days of one mailbox, with customer names redacted" is a rule you can only enforce if you can see the call, not just the bytes.

A Proxy for Data Access, Not a Model Router

The word proxy is overloaded in AI, so it is worth drawing a line early. An AI gateway or LLM proxy also sits in front of something, but it sits in front of the model providers. Its job is to route prompts to the right model, fail over between providers, cache responses, and track token spend. It is an infrastructure layer for talking to models.

An agent proxy points the other way. It does not care which model is running or how the prompt was written. It governs what happens after the model has decided to act, at the moment the agent reaches out to an app for data. The two layers are complementary, but they solve different problems: one manages your access to models, the other manages a model's access to your data.

Why AI Agents Need a Proxy

An agent is only useful if it can act, and acting means reaching real data. The problem is that the access it needs to be useful is the same access an attacker would want, and the agent itself is easy to steer.

The Agent's Permissions Are the Attack Surface

OWASP ranks prompt injection as the number one risk for LLM applications (LLM01:2025), and lists "excessive agency" (LLM06:2025), too much functionality, too many permissions, or too much autonomy, as a top risk in its own right. Read together they describe a single failure mode: an agent is given broad, standing access to an app, and then an attacker, or simply a confused model, uses that access to do something the user never intended. The agent's permissions are the attack surface.

This is why the problem cannot be fully fixed inside the model. Prompt injection works by blending untrusted content (a web page, an email, a shared document) with trusted instructions in the same context, and there is broad agreement among security researchers that it cannot be reliably eliminated at the model layer. If the model can be tricked into trying something, the only durable defense is a layer outside the model that limits what the attempt can actually reach.

Real Incidents, Not Hypotheticals

The pattern has already produced concrete, attributed incidents:

• EchoLeak. A zero-click indirect prompt injection flaw in Microsoft 365 Copilot, tracked as CVE-2025-32711 and rated CVSS 9.3, disclosed by Aim Security and patched by Microsoft in June 2025. A single crafted email could cause the assistant to leak data from its context to an attacker with no user action. Microsoft reported no evidence of exploitation in the wild.
• The GitHub MCP exfiltration. In May 2025, Invariant Labs showed that a malicious issue filed in a public repository could hijack an agent using the official GitHub MCP server and push private repository contents, including private plans and salary information in their proof of concept, into a public pull request. They stressed it affects any agent using that server, regardless of the underlying model.
• The Supabase MCP leak. A documented setup where an agent held a full-access database key showed that a support ticket carrying hidden instructions could make the agent read a private tokens table and paste its contents back into the ticket. Broad scope plus one injected instruction was enough.

In every case the model was working with access it had legitimately been granted. The fix is not a smarter model. It is a narrower grant, enforced on each request.

How an Agent Proxy Works

The architecture an agent proxy implements is not new. Security teams call it a policy enforcement point. NIST defines a policy enforcement point (PEP) as the component that intercepts a request and enforces an authorization decision, while a separate policy decision point (PDP) makes the decision by evaluating the applicable policy. It is the same split that NIST's Zero Trust architecture (SP 800-207) puts at the center of modern access control: nothing is trusted by default, and every request to a resource is checked.

Map that onto an AI agent and the roles fall out cleanly. The access rules you configure are the policy. The agent proxy is the enforcement point that intercepts each tool call and applies them. The agent is the subject asking for access, and your apps and data are the protected resource.

Checking Each Outbound Request Against Your Access Configuration

The core loop is simple, and it runs on every single call:

1. The model decides to act and emits a tool call, for example "search email from the last quarter" or "send this message."
2. The agent proxy intercepts the call before it reaches the app. It reads what the call is actually asking for: which app and account, which action (read, write, send, delete), which records, and over what time range.
3. It checks that request against the access configuration for this agent: what this identity is allowed to see, whose data it may touch, which actions are permitted, and what must be hidden.
4. It resolves the call to one of three outcomes, then carries it out and logs it.

The important property is that the decision is made by the policy, not the model. However the model was prompted, however it was tricked, a tool call that the configuration does not permit does not happen. That is what makes the proxy a durable control rather than a suggestion.

Allow, Redact, or Deny

Every checked call ends in one of three outcomes:

• Allow. The request is within policy and passes through to the app unchanged.
• Redact. The request is allowed, but sensitive fields in the data returned to the model are masked first, so the agent gets the structure it needs without the raw names, amounts, or contact details. This is enforcement on the response side of the same tool call.
• Deny. The request falls outside policy, a write from a read-only agent, a mailbox it may not touch, a record outside its time window, and is blocked before it reaches the app.

Each outcome is recorded. The log captures which agent made the request, what it asked for, what was decided, and what was returned or withheld. One boundary matters here, and PortEden states it plainly: the proxy sees the tool call, the request, the decision, and the response. It does not see the user's prompt or the model's reasoning. The record is what the AI actually did to your data, which is exactly what an auditor asks for.

MCP and the Agent Proxy

In practice, the most common way an agent reaches an app today is the Model Context Protocol (MCP), the open standard introduced by Anthropic in November 2024, adopted by OpenAI in March 2025, and since donated to the Linux Foundation's Agentic AI Foundation. MCP connects AI applications to external systems through a client-server model: the AI client loads a server's tool definitions into the model's context, and each tool call and its result pass back through the model. It is the connector layer the agent ecosystem is standardizing on.

MCP's own security guidance reads like a case for an agent proxy. It warns about the "confused deputy" problem in MCP proxy servers, forbids "token passthrough" (a server must not accept a token that was not issued for it, partly because doing so breaks the audit trail and lets the server be used to exfiltrate data), and prescribes "scope minimization," warning that broad, omnibus scopes like files:* or admin:* widen the blast radius of any stolen token. The protocol authors are describing the same gap: a connector with broad scope is dangerous, and something has to enforce least privilege on each call.

PortEden plugs in at exactly that point. Its MCP servers expose a typed set of tools per provider, and the access rules decide which tools an agent can call and what each call returns. For terminal, headless, and framework-driven agents, the same rules run through the PortEden CLI, and the OpenClaw integration routes those agents' tool calls through the same engine.

Agent Proxy vs AI Gateway, API Gateway, and DLP

Several existing layers look adjacent to an agent proxy, and teams often ask whether something they already run covers it. Usually it does not, because each was built for a different boundary.

The distinction is the unit of control. An agent proxy is the only one of these that makes a decision per tool call, with knowledge of the app, the action, the specific records, and the agent's identity. That is the granularity the threat model demands.

What an Agent Proxy Should Enforce

Sitting in the right place is necessary but not sufficient. An agent proxy is only as good as the rules it can express. The controls that matter map directly onto the risks the standards bodies name, and they are the same decisions you make when granting an AI agent access with least privilege. PortEden groups them into six, set once and enforced on every call across email, calendar, drive, and tasks. They are covered in depth in the guide to hardening AI tool access, and in brief:

• Visibility. How much the agent can see per resource, from full content down to free/busy or filenames only.
• Contact rules. Whose data is in scope, set per address, domain, or list.
• Action limits. Read versus write versus delete, including read-only and draft-only modes that strip send and delete from the tool surface. This is the direct answer to excessive agency: the tool is simply not there to misuse.
• Time window. How far back and forward the agent can reach, so an injected instruction cannot pull years of archives.
• Account scope. Which accounts, workspaces, and boards are in play, so an agent cannot leak across boundaries.
• Data reduction. Field-level redaction of names, amounts, and other sensitive values before they reach the model. This addresses the risk of sensitive information disclosure on the response side of the call.

Visibility, contact rules, action limits, time window, and account scope are how a proxy enforces least privilege. Data reduction is how it limits disclosure. Together they shrink what a compromised or manipulated agent can reach from "everything the token allows" to "only what this agent's job requires." For an organization, a single Account Policy sets a ceiling that no individual agent can exceed, with tighter Policy Groups per team.

How PortEden Works as an Agent Proxy

PortEden is the data firewall for AI, and it works as an agent proxy in front of every connected AI client. It sits between the agent and the providers it touches, Gmail, Google Calendar, Drive, Docs, Sheets, Microsoft 365, SharePoint, Slack, and task tools like Jira, Asana, and Notion, and applies the policy on every call:

• An identity per agent. Claude, ChatGPT, Cursor, Grok, and any headless agent each connect through their own credential, bound to a real person and team through Entra ID and Google Workspace sync. The credential is what the rules engine evaluates and what the log records. The reasoning behind this is laid out in why every agent needs an identity, scoped access, and an audit trail.
• Per-request access control. The six controls plus the org policy ceiling, applied to every tool call. This is the access control layer that replaces coarse OAuth scopes with a real decision per call, configured through access rules.
• A full audit trail. Every tool call logged with its decision and result, exportable for review and streamable to your SIEM. See the audit trail and the 2026 AI audit trail guide.
• One-click revocation. If a laptop is lost or a connector is suspected of misuse, one action cuts off the affected agent across every provider while the rest keep working under their existing rules.

Because the same rules engine governs the MCP servers and the CLI, an agent calling email_search through an MCP client and a script calling the same tool through the CLI are governed identically and logged to the same trail. There is no second policy surface to keep in sync, and no agent that quietly operates outside the model.

Getting Started

Putting an agent proxy in front of your agents takes about five minutes per client:

1. Sign in at my.porteden.com and connect your Google Workspace or Microsoft 365 accounts.
2. Connect each agent through its own credential: add the relevant MCP server endpoint to Claude, ChatGPT, or Cursor, or install the CLI for terminal, headless, and OpenClaw agents.
3. Set the policy with access rules: visibility, contact rules, action limits, time window, account scope, and redaction.
4. For an organization, define the Account Policy ceiling and per-team Policy Groups, and turn on directory sync.
5. Review the audit trail, and stream events to your SIEM if you want agent activity beside the rest of your security telemetry.

The Bottom Line

AI agents are being connected to real business data faster than the controls around them. The incidents that have already landed share one shape: an agent with legitimate, broad access is steered into doing something the user never intended, and because prompt injection cannot be solved inside the model, the access itself is the thing that has to be governed.

An agent proxy is where that governance lives. It is a policy enforcement point for AI: for each outbound request the model makes, it checks the requested app, action, and data against what you actually allowed, then allows, redacts, or denies it, and logs the result. That is what PortEden does as a data firewall in front of every AI client your team already uses.

Every tool call checked. The least access the agent needs. A record of everything it touched.