AI agent web and transport security covers the interfaces and connections that carry agent decisions into real actions. A careful prompt does not protect a transcript endpoint that returns another user's messages. An encrypted connection does not protect a credential forwarded to the wrong provider.
For teams running coding agents or building agent control interfaces, the useful review unit is a boundary: who supplies data, which component trusts it, and what effect follows. This guide focuses on those integration decisions. Start with our coding assistant security guide if you need the broader threat model.
| What should the review establish? | Evidence to collect |
|---|---|
| Can generated content become browser code? | Renderer configuration, output sinks, and controlled browser tests. |
| Can one user access another run? | Server authorization and synthetic tests with separate principals. |
| Does approval match execution? | Displayed operation, recorded authorization, and final tool arguments. |
| Does the client contact the intended peer? | Endpoint selection, certificate validation, and authorized connection evidence. |
| Where do credentials travel? | Attachment logic, redirects, proxy configuration, and redacted traces. |
Map the agent's actual interfaces
Draw a short path from the chat screen to the run API, tool dispatcher, external service, and returned artifact. Add streaming connections, reconnect handlers, and history exports when they exist. Record implementation locations rather than treating the diagram as proof.
For each hop, distinguish the application's identity from the user's identity. A tool server may run under a shared account while the front end serves multiple users. That arrangement needs an explicit place to enforce per-user resource access. Our AI asset inventory guide explains how to separate referenced, configured, and observed components.
Do not fill missing evidence by querying production data automatically. Source, schemas, redacted exports, and synthetic fixtures often establish the relevant behavior without accessing a real conversation.
Can output become active content?
Inspect the renderer's handling of text, Markdown, raw HTML, URLs, and embedded previews separately. Encoding appropriate for HTML text is not automatically appropriate for a URL or JavaScript context. OWASP recommends context-specific output handling and cautions against relying solely on a Content Security Policy. OWASP XSS prevention guidance.
A useful starting search in your application's source directory is:
rg -n 'dangerouslySetInnerHTML|innerHTML|srcDoc|rehypeRaw' .
These matches are review leads, not findings. Trace whether model or tool output reaches each sink and which controls apply. Equivalent APIs and custom rendering code need inspection even if the search returns nothing.
Check streaming and completed messages independently. A system can sanitize the final answer while rendering partial chunks differently. Also inspect generated images and previews: an automatic request deserves review even when no script executes. A displayed website link alone does not establish exfiltration; show the actual destination and data flow.
Can users access only their runs?
Authentication establishes a principal; authorization decides whether that principal may access a particular run, transcript, artifact, or tool operation. OWASP recommends checking permissions on every request. Hiding a control in the browser is insufficient. OWASP authorization guidance.
For an isolated test, create synthetic users A and B with separate runs. Exercise the history, artifact download, export, reconnect, and cancellation paths that the application actually exposes. The expected result is deliberate denial before another user's content or mutable state becomes accessible.
Record the handler and check responsible for that result. A negative test against one endpoint does not establish coverage of an alternate export route. Likewise, a shared cache needs review of the identity and policy information used in its key.
MCP servers add one more thing to check. The protocol is stateless, so servers that need state across requests mint a handle, such as a cart ID or workflow ID, and receive it back as an ordinary tool argument. The MCP guidance on state handle hijacking says servers "MUST NOT treat possession of a state handle as authentication," should generate handles with a secure random number generator, and should bind them server-side to the authenticated user, for example by keying stored state as <user_id>:<handle> where the user ID comes from the verified token. In a review with your synthetic users A and B, hand A's handle to B and confirm the server rejects it.
Token handling needs the same attention. The same page calls "token passthrough" an anti-pattern: an MCP server that accepts a token from a client without checking that it was issued to that server, then forwards it to a downstream API. It says the authorization specification forbids it and that servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." Its stated risks are practical for a reviewer: controls that rely on the token audience are bypassed, audit logs at the downstream API show the wrong identity, and a stolen token can use the server as a proxy for data exfiltration. The check is a code-level one. Find where the server validates the audience claim, and where it attaches a credential to an outbound call.
Does approval survive execution changes?
Consider an illustrative agent that prepares an email. The interface displays recipient A, but the dispatcher accepts a new recipient from the browser after approval. The relevant failure is that the execution request can diverge from the approved action.
Our review recommendation is to trace the approved operation through to its final consequential arguments. Check recipient, destination, resource, and relevant state, then examine retries and reconnects for duplicate side effects. Use a recording mail stub and synthetic addresses to demonstrate behavior; sending a real message adds no necessary evidence.
The same reasoning applies to file deletion, remote tool calls, and configuration changes. Beam's skill specification and review guide explains why a candidate's permission declarations cannot grant authority, while our MCP security guide addresses tool-origin trust.
Where can agent-controlled requests go?
Inspect provider base-URL overrides, document fetchers, remote MCP endpoints, and preview services. Trace scheme and host parsing, destination checks, DNS resolution, redirects, and network restrictions. OWASP distinguishes fetching from a fixed set of trusted services from fetching arbitrary external destinations; the applicable controls depend on that design. OWASP SSRF prevention guidance.
Use local controlled destinations or request-recording stubs for verification. A general code review does not authorize contacting internal metadata services or scanning addresses found in configuration. Record a potentially unsafe fetch path as source evidence when runtime testing is unavailable.
A concrete case: OAuth discovery in MCP clients
The MCP project's security best practices describe an SSRF path that is easy to miss because the client, not the user, chooses the URL. During OAuth metadata discovery an MCP client fetches addresses supplied by the server: the resource_metadata URL in the WWW-Authenticate header, the authorization_servers entries in the Protected Resource Metadata document, and the token_endpoint, authorization_endpoint and other URLs in the Authorization Server Metadata. A malicious server can fill those fields with internal targets. The guidance lists direct private addresses, cloud metadata endpoints at 169.254.169.254, localhost services, DNS rebinding, and redirect chains.
For a review, this turns into a short list of questions about the client:
- Does it require HTTPS for OAuth URLs, with an explicit development exception for loopback addresses only?
- Does it block private, loopback and link-local ranges, using a maintained library rather than hand-written parsing? The guidance warns that attackers exploit encoding tricks such as octal, hex and IPv4-mapped IPv6 that custom parsers miss.
- Does it validate each redirect hop, or disable automatic redirects?
- For clients that run on a server, is outbound traffic routed through an egress proxy that enforces network policy?
- Is DNS resolution pinned between the check and the request? The guidance names the time-of-check to time-of-use gap, where a name resolves to a safe address during validation and an internal one at fetch time.
The guidance adds that the same concern applies to authorization servers that fetch client metadata documents from a URL. A fetch that follows a URL supplied by an unknown party is the pattern in every case.
The OAuth side has also had a real flaw of this general shape. Our post on the MCP TypeScript SDK OAuth credential leak (CVE-2026-104850) covers a malicious MCP server steering the SDK's OAuth client into sending refresh tokens and client secrets to its own authorization server. It is a different bug from SSRF, but it has the same cause: the client trusted an address that the server controlled.
Local servers and the browser
An MCP server that runs on the developer's machine is also a web service, and a browser on the same machine can reach it. The MCP transport specification says servers "MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks," that servers running locally "SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0)," and that they should authenticate all connections. It states the consequence directly: without these protections, "attackers could use DNS rebinding to interact with local MCP servers from remote websites."
The best-practices page lists the same issue under local server compromise, along with a malicious startup command in a client configuration. To review it, check three things on a test machine: which address and port each local server listens on, whether it rejects a request with a foreign Origin header, and what command and args each entry in your client configuration would run. A local request recorder is enough for the Origin test. You do not need an external target.
Here the browser-facing and transport-facing questions meet. A server that listens on all interfaces without authentication is reachable by other devices on the network. A server that listens only on loopback but ignores the Origin header is reachable from a web page you visit. Each needs its own evidence.
What does transport security verify?
Review each connection separately: browser to edge, edge to application, and application to tool or provider. Check certificate-chain validation, expected peer identity, trust roots, and disabled-verification exceptions. Select protocol settings using the actual deployed library and current guidance; avoid pasting a cipher configuration from a different server. OWASP TLS guidance.
Then trace credentials. Which component attaches the token, and can a redirect or endpoint override change its recipient? For JWT-based authentication, verify the expected algorithm, issuer, and audience using the appropriate library. Readable token claims are not verified claims. Opaque credentials need their own verification path. RFC 8725: JWT best practices.
If the integration stores encrypted credentials, inspect the library API, key reference, authentication-failure handling, and construction-specific nonce requirements. Use established authenticated-encryption mechanisms rather than inventing a scheme. OWASP cryptographic storage guidance.
Order the work
If time is short, a sensible order is: first the local servers and the credentials they hold, because a compromise there reaches the whole machine; then the places where a client fetches an address supplied by a server; then the approval-to-execution path; then rendering. This is a judgement, not a ranking from a source. Adjust it to your deployment. A hosted agent with many users should put authorization of runs and handles first.
For each item, write the invariant in one sentence before you test it, for example "a request for run B made with user A's session is denied before any content is read." The sentence becomes the regression test later, and it keeps the report from drifting into general advice.
Report what the evidence supports
A useful finding identifies the boundary, affected principal, prerequisites, source location, redacted evidence, reachable effect, and fix. Keep severity separate from confidence. “High confidence that verification is disabled in this configuration” does not establish that an attacker intercepted a deployed connection.
List reviewed flows, omitted routes, unknown versions, and runtime checks not performed. Keep browser rendering, API authorization, and deployed transport as separate verification claims. Finish with regression expectations tied to the original invariant, then continue with our vibe coding security checklist.
Related reading from this blog: the Cursor MCP config poisoning write-up shows a configuration file acting as the trust anchor, and the MCP security practical guide covers tool poisoning and rug pulls, which sit above the transport layer this guide reviews. For a recent transport-level case, see the MCP Python SDK advisories on cross-origin redirects and $ref fetches.
For ongoing visibility after review, read what agent monitoring measures. Visit agentbeam.com for advanced monitoring and control options, including self-hosting and further monitoring guidance. That optional handoff does not upload evidence or configure collection automatically.
Reviewed September 14, 2026. Examples are illustrative; deployed behavior depends on the application, client versions, and configuration actually inspected.