# How Many Credentials Should Your AI Agent Have? Zero. — Jim Clark, Docker

## Executive summary

As AI agents become capable of running unsupervised and for extended periods, managing their potential impact (the 'blast radius') is critical. The solution proposed is to implement granular sandboxing, where agents operate within highly restricted environments defined by their specific task intent. This architecture utilizes MCP Gateways as single control points to manage all incoming context, tools, and resources, ensuring that agents never have unnecessary credentials. The integration of Cross App Access (XAA) further enhances safety by leveraging existing corporate SSO infrastructure for identity claims.

## Key takeaways

- Safety through Restriction, Not Supervision: AI safety is achieved by limiting the tools and context available to the agent, rather than relying solely on human supervision. The goal is to model the sandbox boundaries after the precise intent of the task.
- The Role of Sandboxes and MCP Gateways: A sandbox is a restricted execution environment for an agent. MCP Gateways serve as a single control point, funneling all Micro-Control Point (MCP) traffic to manage which tools, resources, and prompts are accessible to the sandbox.
- Zero Credentials Principle: The most critical security maxim is that a sandbox should contain zero credentials. This drastically reduces the potential blast radius if the agent performs an incorrect action.
- Cross App Access (XAA) for Identity: XAA allows agents to utilize existing corporate Single Sign-On (SSO) systems (like Okta) to define agent identity claims and authorization grants, centralizing administration without requiring new consent screens.

## Technical details

- Agent Architecture Components: An agent's workflow is composed of: 1) A **Harness** (a loop that takes context and requests work); 2) A **Sandbox** (the restricted place where work is done); and 3) **MCPs** (Micro-Control Points, which allow the agent to pull in new context and tools).
- MCP Gateway Implementation: The MCP Gateway acts as a central funnel (e.g., `mcp.gateway.docker.internal`) for all MCP traffic, allowing the gateway configuration to control the tools and resources available to the sandbox, making harnesses MCP-agnostic.
- Modeling Intent (Examples): Sandboxes should be modeled after the task's intent. Examples include: 1) A newsroom split into separate sandboxes (Researcher, Fact-Checker, Publisher) to prevent mixing untrusted input with dangerous tools; and 2) A coding agent that only receives signing keys when the specific action (committing) requires them, rather than having them available throughout the entire task.
- CLI Tooling: The `sbx` CLI tool is available for building and managing these containerized sandboxes.

## Practical implications

- Build engineers can containerize AI agents using sandboxes (`sbx`) to enforce strict role separation and limit access to sensitive resources (e.g., Git signing keys, corporate APIs).
- The architecture allows for progressive disclosure of capabilities, meaning a complex workflow can use many MCPs, but individual sandboxes only need the minimum required for their specific sub-task.
- By centralizing control through an MCP Gateway, build systems can manage and audit all tool calls and resource access points for autonomous agents.

## Topics

AI Safety, Containerization, Agent Orchestration, Identity and Access Management (IAM), Microservices Architecture, Docker MCP Gateway, Docker Sandboxes docs, sbx CLI reference, Okta Cross App Access

Source: https://www.youtube.com/watch?v=ZUZVNKFSmTM