An agent that reads public websites needs a defined network boundary and an execution role scoped to its work. This field guide explains how to review both, including MCP request paths and local metadata access.

Review reachability and authority together

A destination policy controls where a component can connect. Its execution identity controls what it can do when it arrives. Review both for public retrieval, authentication discovery and privileged business operations. Separate an untrusted retrieval component from privileged execution where the platform permits it, and assess the local credential boundary explicitly.

What the evidence establishes

The PDF separates Zenity’s AgentCorruption findings from AWS guidance and the author’s architecture recommendations. It preserves the distinction between researcher findings, provider documentation and evidence about an actual deployment. The report is not evidence of a current customer breach, a microVM escape or universal cross-account compromise.

AWS documents AgentCore’s MicroVM Metadata Service (MMDS) as a source of execution-role credentials inside the VM, independently of network mode. Code or actors inside that VM can access those credentials. EC2’s Instance Metadata Service (IMDS) has related concepts, but its configuration guidance needs to be interpreted for the actual runtime.

Map every request origin

A fetch server opens connections from its own host. An MCP client can also fetch OAuth metadata during authentication, before a tool call occurs. Include browser tools, HTTP-source connectors, authentication discovery and shell environments in the request inventory. Name the initiating process, destination classes, resolver, proxy, credentials and control owner.

Separate controls for each request path
Request pathControl to establishEvidence to retain
Public retrievalApproved destination policy and narrow execution identityEffective DNS, redirect and connection enforcement
Authentication discoveryPolicy for every discovery URLApproved identity services and client-side enforcement
Business operationsNarrow operation and scoped identityDestination authorization and required permissions
Local metadataRuntime-specific access boundaryWhich processes can reach credentials and why

Enforce the policy at the connection

Public retrieval should begin without access to private, loopback, link-local or other reserved destinations. Document required exceptions. Internal business connectors need a narrow allowlist for their intended service and authorization at that service. Apply the destination policy across IPv4, IPv6 and redirects, bind address validation to the connection, and preserve TLS hostname verification.

A proxy covers only the traffic it mediates. Review alternate libraries, direct sockets, shell access and configuration permissions. A local metadata request may never traverse an external proxy. Prompt instructions alone cannot enforce these transport boundaries.

Review fixes and permissions separately

The six-page PDF compares records for MCP fetch, Google MCP Toolbox and the rmcp Rust SDK. It distinguishes advisory publication dates from package releases and describes the limits of the fixes. Use maintained releases containing the relevant fixes, pin reviewed dependencies and confirm the running artifact. A patch in one library does not establish coverage for every request path.

Use the runtime’s own metadata and execution-role guidance. Explain required actions and resource permissions in terms of specific operations. Prefer narrow business tools, preserve authorization at the destination and keep credentials out of model-visible results. Short-lived credentials retain their granted permissions while valid.

Evidence an architecture review should produce

Retain a request map, allowed destinations and denied classes, an isolated policy test record, a bypass review, effective role permissions, telemetry coverage and running artifact versions. Use inert fixtures for redirects, changing DNS answers, IPv6 and proxy-side resolution. Redact credentials, authorization headers and sensitive query values from records.

Check the monitoring surface before promising coverage. Establish what tool, process and enforcing-proxy records actually capture, including local metadata access. Assign an owner and review date to approved exceptions, and retest when the runtime or request path changes.

Read the full field guide

The PDF includes an illustrative architecture diagram, the three security-record comparisons, six proposed review outputs and nineteen references. It connects network reachability to runtime authorization and sensitive tool output. TrustCyber architecture advisory can help review agent tool egress, metadata exposure and execution-role scope.

Selected primary sources

Open the primary-source pages used to verify the claims summarized here.