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.
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.
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.
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.
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.