The Three-Gate Model

Authorization at the agent, the tool, and the data. All three.

Most teams put one authorization gate around their AI system, usually at the API or app boundary. That is a good start. It is also nowhere near enough.

Gate 1: The agent boundary

Who can talk to this agent? With what kind of prompt? In what context? This is the outer perimeter, the equivalent of can this user log in to this app.

• Authentication of the requesting user or system
• Authorization to invoke this specific agent
• Prompt-level guardrails for sensitive content or out-of-scope requests
• Tenant isolation in multi-tenant scenarios

Gate 2: The tool boundary

Once the agent decides to call a tool, MCP server, or external API, who decides if it is allowed? The agent itself? The tool? Or a policy layer between them?

• Which tools is this agent permitted to invoke at all?
• Under what conditions: user context, time, risk score?
• With what parameter constraints: dollar limits, scope filters, region restrictions?
• Should this specific invocation be allowed, given everything happening in this session?

Gate 3: The data boundary

When the agent retrieves data from a vector store, a database, an API, who decides what comes back? The data store? Or a policy layer that enforces row-level, column-level, or document-level access based on the user context?

• Which records can this user, and therefore this agent acting on their behalf, see?
• Which fields are masked, redacted, or filtered?
• Does the agent get a filtered result, or does it get everything and trust itself?
• What appears in the audit log when the answer is denied?

Why one gate is not enough

Each gate solves a different problem. Authorization at only the agent boundary means the agent can do anything inside, including pulling data the user should not see. Authorization at only the data boundary means the agent can attempt anything and you just hope the data layer says no. Authorization at only the tool boundary means agents access raw data freely.

Where the gates live

In practice, all three gates call the same policy layer, but enforce in different runtimes:

• Gate 1: at the API gateway, agent framework, or chat interface
• Gate 2: at the agent framework hook, MCP gateway, or tool wrapper
• Gate 3: at the data access layer, RAG pipeline, or query engine