Auditable egress: how to log every proxy-routed network call an AI agent makes

Your compliance team wants a list of every external service your AI agents contacted last month. The agents made many outbound HTTP calls across many sandbox instances. The records are inside individual sandboxes. Each agent's framework formats them differently. Some calls never appear because generated code made them outside the agent's own logging.

Auditable egress captures that record at the infrastructure layer. The resulting record is tamper-resistant and independent of agent code.

Agent observability today concentrates on prompt traces and token counts associated with an agent's thoughts and reasoning chains. It mostly skips what the agent does on the network. Compliance auditors and security teams need a network record, as do incident responders. It must contain the endpoint and time along with the credential used.

A September 2025 Gartner survey polled 360 IT application leaders. Of those leaders, 74% called AI agents a new attack vector. Only 13% strongly agreed they had the right governance structures in place. For a CISO, an agent-independent egress log produces evidence rather than policy text.

TL;DR

• Agent-level logging misses outbound calls from generated code: Frameworks log what they instrument. Runtime scripts may not be instrumented, so the trail has gaps.
• Infrastructure-level egress logging captures traffic routed through the proxy: The proxy records outbound requests before forwarding them in one consistent format.
• The audit trail is independent of agent code: Developers don't instrument each outbound call. New agents inherit logging when their traffic uses the proxy.
• Compliance mapping becomes direct: SOC 2 CC7.2 addresses monitoring of system components for anomalies, while ISO 27001:2022 requires logging and monitoring activities.
• Anomaly detection surfaces unauthorized access: A spike in calls to an unfamiliar domain becomes an alert. So does a request outside the allow-list.

Auditable egress is ideal for coding and code-generation agents first. It also suits PR review agents and other agents executing generated code.

Why agent-level logging produces incomplete audit trails

Framework observability answers which tools the agent invoked. A compliance review asks which hosts the sandbox actually contacted. Those answers diverge in two places.

Framework instrumentation only covers framework calls

LangChain and LangGraph are examples of agent frameworks that instrument their own tool calls and model interactions; CrewAI does the same. Traces show which tools the agent invoked and what the model returned. They don't capture every HTTP call made by runtime-generated code.

PR review agents that execute generated test scripts hit this gap constantly. An agent might generate a Python script calling requests.get("https://external-api.com/data"). That request never enters the framework trace.

Assume any tool call your instrumentation does not wrap is invisible. The AEGIS framework does not defend against "attacks that bypass the SDK entirely." A direct API call outside the instrumented client leaves no framework trace. A compliance reviewer sees the tool name but not the host or credential behind it.

Standardize how each agent logs

A fleet built by different teams and frameworks produces inconsistent logs. Full URLs appear in one agent's logs, but another records only the domain. A third records nothing at all. Domain-only records make path-level allow-list review impossible after the fact.

Merging those records requires format normalization and deduplication, plus evidence that nothing is missing. An engineer maps each framework's destination field to a common column. Timestamp alignment across time zones and clock drift comes next. Retries may also require deduplication when a framework logs them twice.

Then the auditor asks for proof that no agent was omitted. No per-agent log can answer that. Infrastructure-level logging inverts the proof. Each non-bypassed request from a proxy-respecting client is recorded once at the boundary. Every resulting entry uses one format.

How to implement infrastructure-level egress logging

The egress proxy is the single logging point. The proxy terminates Transport Layer Security (TLS) before logging. Each record carries the destination, method, timing, and credential identifier. Request and response bodies stay out.

Use the egress proxy as the single logging point

The proxy sets HTTP_PROXY, HTTPS_PROXY, and NO_PROXY inside the sandbox. It also installs a certificate authority (CA) certificate. That certificate reveals the full request, rather than only the CONNECT host and port.

Without termination, the proxy sees little. RFC 9110 limits the CONNECT target to "only the host and port number of the tunnel destination."

The proxy can also inject credentials by destination domain. The sandbox then never holds the raw key. The base image therefore helps determine current coverage.

If the proxy injects credentials, record the credential identifier, never the value. Keep request and response bodies out. Logs can capture passwords or email contents intentionally or inadvertently. Keep bodies out to mitigate that risk, consistent with SP 800-92.

One vendor example is Google Cloud's Secure Web Proxy transaction logs. They record requestSize and responseSize, but no payload.

Build a structured audit record

Design each record to satisfy NIST SP 800-53 control AU-3. It needs what happened, when, where, the source, the outcome, and the identity involved.

For agent egress, use a structure like { timestamp, sandbox_id, agent_id, destination_domain, destination_path, method, credential_id, status_code, bytes_transferred }. Treat it as a target shape, not a schema copied from product documentation.

Security teams can query that table directly. Which agents contacted external APIs before 6:00 a.m.? Which sandbox reached a domain outside the allow-list?

The record must also be append-only and stored outside the sandbox. AU-9(2) requires storage on a component "physically separate from the system being audited." AU-9(6) requires read-only access. A compromised sandbox can then neither erase nor edit its own record. That resistance is what an auditor tests.

How to implement auditable egress for your agent fleet

Four steps take a sandbox fleet from scattered per-agent logs to one queryable trail. Steps one and two configure the platform. Steps three and four connect existing security and compliance systems.

Route all sandbox egress through the proxy

Every sandbox in the workspace should send outbound traffic through the egress proxy by default. Any avoidable path around the proxy creates a hole in the trail. On Blaxel, add a proxy config during sandbox creation.

The proxy routing docs describe the configuration scope as follows. "Adding a proxy config to a sandbox enforces the proxy on all outbound requests." Treat configuration scope and routing-level enforcement as distinct concepts.

The proxy can't be added after sandbox creation or fully disabled once set. Put it in every team's creation template. Standardized templates make the intended routing policy consistent across teams. They also reduce the chance that a newly created sandbox lacks the required proxy settings.

Two routing exceptions remain. A bypass list such as ["*.s3.amazonaws.com"] skips the proxy for named domains. Localhost and private ranges are always bypassed; the metadata address is too. Treat every bypass entry as a documented audit exception.

Proxy secrets injection and domain filtering are in public preview. They are not recommended for production use during that status. Current enforcement relies on tools honoring the proxy environment variables. Routing-level enforcement is planned. Until then, pin base images to HTTP clients that respect those variables.

Configure domain allow-lists and alert on violations

Define the domains each agent type may reach. Seed the first list from a week of observed destinations, then enforce it. Log allowed and blocked requests alike. Blocked entries prove the control operates. That proof is what an auditor asks to see.

In the Silent Egress study, a tool-using agent reached an egress event in roughly 89% of 480 runs. Domain allow-listing blocked all egress to clearly external attacker domains in that paper's setup.

An egress proxy should accept allow-lists and deny-lists per sandbox. Scope rules by method and path. Deny rules should win over allow rules. Blocked requests should return an explicit error response. Your pipeline should capture every blocked request routed through the proxy.

Treat a single block as a likely code-generation mistake. Treat repeated blocks to one domain as a possible compromise and escalate. Review patterns by agent type, sandbox, method, and destination. That context helps analysts distinguish isolated implementation mistakes from repeated attempts. Those repeated attempts may target an unauthorized service.

Keep the enforced list aligned with the audit inventory. An approved destination should appear in both places. An observed destination outside the list should create a reviewable event. This connection turns a configuration file into operating evidence.

Export egress logs to your security monitoring system

Wire the proxy log into the security information and event management (SIEM) system your security team already watches. Build or verify that export path yourself. Splunk and Datadog accept structured JSON; Elastic does as well. A record shaped like the one above lands without a custom parser.

Write the proxy's per-request identifier into the field your SIEM uses for trace correlation. This identifier connects the network record to related monitoring data. Keep sandbox_id as a separate indexed field for workload-level filtering.

To join an egress entry to a prompt trace, place the trace identifier in the required field. Splunk Observability Cloud needs exactly trace_id. Datadog accepts dd.trace_id or trace_id. Elastic expects trace.id and transaction.id.

Index sandbox_id alongside the trace identifier. An analyst can then filter by one sandbox_id and a time range. That query pulls the proxy-routed calls associated with the sandbox.

An incident responder can follow the sequence from user input to agent reasoning and the external call. SP 800-53 AU-6(3) asks for that kind of cross-repository correlation. Verify that timestamps use a consistent reference and remain queryable across repositories.

Build compliance reports from the egress log

Turn the raw table into recurring reports. For SOC 2, produce three:

• External services contacted: List every service reached through the proxy during the audit period. Group by agent type to expose unexpected destinations.
• Blocked requests: Record each blocked call with the rule that triggered it. A cluster against one domain shows reviewers where to investigate.
• Credential usage: Report which credential was used, broken out by domain and frequency. Frequency shifts can reveal quietly widened agent scope.

For ISO 27001:2022, label the same outputs against the network security control and the controls for logging and monitoring activities. The logging control covers logging, while the monitoring control covers monitoring activities. Network security is covered by the network security control.

Generate reports on a schedule rather than on request. Store each export with a message digest. Protect it through approved encryption or read-only media, as SP 800-92 asks. Land the files in write-once object storage outside the sandbox fleet.

An auditor can then verify that each report matches the underlying log. Scheduled generation also provides dated evidence across the review period. Keep the report's coverage statement explicit. It should identify bypass exceptions and the proxy-routing boundary.

How to map egress audit trails to compliance frameworks

An egress log only helps in an audit if you can tie it to the controls reviewers actually test. The sections below map the same proxy record to SOC 2, ISO 27001:2022, and industry rules like HIPAA and DORA.

Map monitoring system activities to SOC 2

Trust Services Criteria CC7.2 covers monitoring. The entity must monitor "system components and the operation of those components for anomalies." Its points of focus include "logging of unusual system activities." They also include detecting "unauthorized access from outside the system boundaries."

An egress log with allow-list violations flagged is evidence for both. The evidence applies to requests captured at the configured proxy boundary.

CC6.1 covers points of access by outside entities. Those points must be identified, inventoried, and managed. Your allow-list is that inventory. CC6.7 restricts "the transmission, movement, and removal of information." It addresses the same control from the data-loss side.

The proxy configuration and allow-list prove control design. Dated log entries across the review period prove operation.

Map logging and network security to ISO 27001:2022

Use the logging and monitoring activities controls in your statement of applicability. Include the network security control as well. Do not use the superseded 2013 control numbers. Under the IAF transition rules, 2013 certifications "shall expire or be withdrawn" after October 31, 2025. The 2013 control numbers are now outside accredited scope.

The egress log maps to the logging control, while alerts on unusual destinations support monitoring activities. Proxy enforcement and allow-lists map to the network security control. The append-only egress record provides logging evidence. The allow-list and proxy configuration implement network security at the agent infrastructure layer.

Keep the mapping attached to operating evidence rather than treating it as a control-name crosswalk alone. Retain dated proxy configurations, allow-list versions, allowed and blocked log entries, and the scheduled reports generated from those records. The report coverage statement should identify the proxy-routing boundary and any bypass exceptions.

This evidence separates control design from control operation: the configuration shows what should happen, while the dated records show what happened during the review period. Use the current ISO 27001:2022 control labels consistently in the statement of applicability and report headings, as well as the evidence inventory. That consistency makes it easier to trace alerts and blocked requests, along with approved destinations, from the underlying egress record to the applicable logging, monitoring activities, or network security control.

Address industry-specific requirements

The Health Insurance Portability and Accountability Act (HIPAA) Security Rule sets the healthcare baseline. 45 CFR 164.312(b) covers audit controls. Covered entities must implement mechanisms that "record and examine activity in information systems." Systems holding electronic protected health information are in scope.

Section 164.308(a)(1)(ii)(D) adds regular review requirements. These cover "audit logs, access reports, and security incident tracking reports." If agents touch protected health information (PHI), the egress log shows their proxy-routed destinations.

Financial services rules point the same way. The EU Digital Operational Resilience Act's delegated regulation 2024/1774 requires logging of "network traffic activities." Treat these rules as examples, not as your control list. Map the egress log to your own obligations with legal counsel.

Make proxy-routed outbound calls auditable by default

Moving egress logging to the infrastructure layer is a rollout decision, not a rewrite of your agents. Here's the adoption sequence, and how Blaxel's networking stack supports it.

Adopt infrastructure-level logging

Start with coding and code-generation agents, then include PR review agents and other workloads that execute generated code. Put the proxy configuration in every sandbox creation template so teams begin with the same routing policy. Define destination rules by agent type, document every bypass as an audit exception, and validate representative HTTP clients whenever the base image changes.

Send the resulting records to append-only storage outside the sandbox fleet and export them to the SIEM with sandbox_id and the appropriate trace identifier. Build the scheduled reports described above. Each report should state its proxy-routing boundary and identify traffic that may fall outside it because of bypasses or clients that ignore proxy settings.

This adoption sequence turns the audit from a reconstruction across framework-specific traces into a query over one structured dataset. It also gives security teams a direct way to investigate unexpected destinations, repeated blocks, credential-use changes, and the sequence connecting a sandbox to an external call. For agents executing self-written code, that difference decides whether an audit is a query or a reconstruction.

Use Blaxel's networking stack

Blaxel, the perpetual sandbox platform, includes proxy routing in its networking stack. The platform provides proxy routing and per-request identifier stamping. Domain filtering and proxy secrets injection are in public preview.

The egress proxy logs every outbound call routed through it with its destination and workload. Each captured call is stamped with an X-Blaxel-Request-Id. Dedicated egress gateways for static outbound IPs are in private preview.

For an audit deployment, pair that request identifier with sandbox_id in the monitoring export and preserve the proxy-routing boundary in each report's coverage statement. Keep bypass entries documented, and account for the public-preview status of domain filtering and proxy secrets injection when deciding where to use those controls.

Blaxel's compliance portal lists SOC 2 Type II and ISO 27001 (2022). It also lists a HIPAA business associate agreement (BAA). Sandboxes run as Firecracker microVMs, the same technology behind AWS Lambda. That microVM boundary is hardware-enforced.

Talk to the team at blaxel.ai/contact or start building at app.blaxel.ai.

FAQ

What is auditable egress?

Auditable egress is infrastructure-level logging of outbound requests routed through a network boundary. The record includes destination, method, time, credential identifier, and outcome. It is most reliable when teams document bypasses, standardize workload identifiers, and store records outside the sandbox fleet. Auditors can then query one boundary-generated dataset instead of reconciling incompatible framework traces.

Does egress logging capture request and response bodies?

Not in a well-designed audit trail. Keep metadata for compliance review and place any body capture in a separate, restricted pipeline. This separation limits exposure of passwords, email contents, PHI, and other sensitive information. If troubleshooting requires payload sampling, restrict it by destination, redact sensitive fields, and define access and retention controls independently from the primary egress log.

How does egress auditing work with agents that generate and execute code?

Treat generated-code coverage as a base-image validation test. Run representative scripts through supported network clients, confirm each expected request appears in the proxy log, and verify its workload identifiers. Repeat the test during image updates. Until routing-level enforcement lands, pin clients that honor HTTP_PROXY and HTTPS_PROXY, and record any direct-connect library or bypass rule as an exception to the stated audit boundary.

Can I use egress logs for incident response?

Yes. Filter by sandbox and time window, then review destinations, outcomes, credentials, and byte counts. Correlate the results with prompt traces through the appropriate trace identifier. A practical workflow starts with an alert, narrows the affected workload, and reconstructs the sequence around the call while preserving the proxy record as evidence outside the sandbox.