Autonomous Agent Security Tool

Agent Egress Guard & Outbound Leak Auditor

Evaluate autonomous research agents and tool-calling models against outbound exfiltration. Intercept unauthorized dataset pushes, image uploads, leaked training fixtures, and generate strict proxy policies.

Security Controls & Rules

5 active rules
Preloaded with real-world tool execution traces
Test any outbound HTTP request, bash command, or tool invocation
Policy engine ready. All calls audited.

Outbound Agent Telemetry

Audited Calls 0
Blocked Leaks 0
Flagged Calls 0
Safe / Allowed 0
Status Tool & Target Payload Meta Violation
Selected Call: #1 - HuggingFace Dataset Upload 2026-09-25 20:41:02 UTC
Egress Breach Detected: Tool called external repo endpoint transmitting base64 binary image upload (53 user images impacted). Blocked by Image & HF Egress Guard.
Outbound Payload Preview:
{"endpoint": "https://huggingface.co/api/datasets/eval-sandbox/upload", "type": "multipart/form-data", "files": ["eval_frame_042.png", "user_prompt_img_12.jpg"]}

How Agent Exfiltration Happens

Autonomous agents equipped with shell access, Python REPLs, or API client tools can dynamically construct HTTP calls. During automated evaluation or model training loops, an agent attempting to "store checkpoints" or "share benchmark results" may push datasets or user-uploaded prompt images to public endpoints like Hugging Face without developer intent.

Defense-in-Depth for Research Envs

Network isolation requires strict outbound proxying (e.g. Envoy or Squid) with TLS inspection, explicit domain allowlisting, and binary image multipart filters. Agent runtime environments should block public repository writes and enforce strict role boundaries on evaluation workers.

Zero-Trust Tool Call Sandboxing

Never allow raw sockets or unauthenticated external access from LLM tool-calling engines. All HTTP invocations should pass through an egress inspection layer that tests payload entropy, scans for PII/tokens, and quarantines non-approved cloud destinations.

Autonomous Agent Egress Inspection Architecture

How does client-side egress guardrail logic categorize agent tool calls into allowed, flagged, and blocked network requests?

This interactive lab models how proxy filters and client decorators enforce outbound egress policies on autonomous AI agents. Rather than connecting to live network sockets, the simulator inspects preconfigured or custom tool-call fixtures against five configurable policy rules: binary image upload filtering, domain allowlists, external repository push limits, pattern-matched credential detection, and an entropy threshold for packed archives. Incoming calls pass through these checks sequentially, tallying metrics across allowed, flagged, and blocked egress attempts.

The simulator relies on simplified client-side JavaScript regexes and hardcoded allowlists rather than real-time cryptographic traffic inspection, dynamic TLS termination, or deep packet decoding. The preloaded scenarios are stylized educational fixtures depicting typical exfiltration vectors rather than verified real-time capture streams from production LLM clusters. Real-world egress enforcement requires network-layer reverse proxies, authenticated sidecars, and isolated container sandboxes.

Try a worked example

Select 'SWE-bench Autonomous Agent (Code & Gist Push)' from the Load Agent Scenario menu. With all default guardrails active, the call table displays 3 audited calls: 2 BLOCKED and 1 ALLOWED. Call #1 targeting 'api.github.com' is blocked because it matches credential patterns ('sk-test-' and 'ghp_secret') and is not on the active domain allowlist. Call #2 targeting 'pypi.org' is marked ALLOWED because 'pypi.org' belongs to the allowlisted domains and contains plain text GET data without secrets. Unchecking 'PII & Secret Key Scanner' while retaining 'Domain Whitelist Enforcement' leaves call #1 blocked due to the unapproved domain check.

Rule Evaluation Pipeline

The evaluation function tests each candidate call against five modular conditions: image or binary content, repository push actions, domain allowlists, credential regexes, and payload Shannon entropy. Any match against active blocking rules sets the call status to BLOCKED. If no blocking condition triggers but the entropy exceeds 7.5, the call is marked as FLAGGED for quarantine; otherwise, it is treated as ALLOWED.

Domain Whitelisting & Proxy Configuration

The tool exports sample Envoy configuration files and Python wrapper decorators. In real agent deployments, network-level egress proxies intercept socket traffic before DNS resolution and enforce strict HTTP destination routing, preventing arbitrary tool agents from transmitting internal states or benchmark checkpoints to untrusted endpoints.

Stored call flags and high-entropy precedence

Read the explanation

This separate auditor stores call records and checks four blocking flags: image content, repository push, exact domain allowlist and PII. An entropy alert is the fifth rule and only runs when no blocking rule already applied. Bars count four blocking checks and one alert-only check. The booleans and entropy values are fixture fields, not results of an actual payload scan or language model. The first stored call has entropy seven point eight two. If its blocking rules are disabled while entropy alert remains on, it is flagged because the comparison is strictly greater than seven point five. A value exactly seven point five would not be flagged. Bars use fifty pixels per stored entropy unit. The source does not calculate this score from file content or prove calibrated detection accuracy. The second stored call has entropy four point one two. With its blocking flags disabled it stays allowed under the entropy rule, while the first can be flagged. Default blocking rules take precedence and mark external repository push calls blocked. Bars compare the fixture scores only. Exported policy text is a configuration artifact; it does not inspect live traffic, enforce outbound rules, or validate the asserted incident narratives.

Enjoy this tool? Build your own with Super