What is a Security Boundary (Agent)?

Every secure system has boundaries — perimeters that separate permitted operations from prohibited ones. For traditional applications, these are network perimeters, authentication boundaries, and authorisation scopes. For AI agents, the security boundary is defined by tool access, argument constraints, and server connectivity.

Defining an agent's security boundary requires answering three nested questions. Outer boundary: which MCP servers can the agent reach? This determines the universe of available capabilities. Middle boundary: within those servers, which tools can the agent invoke? This scopes the specific operations available. Inner boundary: within those tools, what argument values are permitted? This constrains how operations are performed.

A well-defined security boundary has the property that an agent operating entirely within it cannot cause harm beyond acceptable risk. If the boundary is drawn correctly, even a fully compromised agent — manipulated by prompt injection, hallucinating wildly, or adversarially controlled — is contained. The damage is bounded by the boundary.

The challenge is that security boundaries are often implicit rather than explicit. An agent's boundary is whatever its MCP client configuration and server capabilities happen to permit. Without a tool like Intercept that makes boundaries explicit and enforceable, the boundary is undefined — meaning the agent's effective boundary is 'everything accessible through configured MCP servers.'

Intercept makes agent security boundaries explicit, declarative, and enforceable. YAML policies define the boundary at each level: server connectivity, tool access, and argument constraints. The boundary is documented in version-controlled policy files, making it reviewable by security teams and auditable by compliance. Intercept enforces the boundary on every tool call — any operation outside the defined boundary is denied, regardless of why the agent attempted it.