An agent may be allowed to call a customer-data tool without being allowed to see every customer row or field. AWS’s open-source TOLAP project aims to enforce that smaller boundary before tool output enters the model’s context. The practical question is not whether the agent was told to behave, but whether the data path actually filters what it can receive.
What TOLAP does
In a September 22, 2026 technical introduction, AWS presented TOLAP as an Apache-2.0 policy schema and SDKs for .NET, Python, and TypeScript. The source repository includes examples and a threat model. TOLAP wraps the function behind an agent tool and applies object-level rules to the data it may return. It is protocol-agnostic: it can sit behind an MCP tool, but it is not an MCP server itself.
Think of two separate decisions. The first is whether the agent may invoke a tool at all. The second is which records and fields that tool may expose for this user and purpose. A generic “read customers” permission does not answer the second question. If the tool returns an unrestricted database result and relies on a system prompt to hide confidential columns, the sensitive data has already crossed into model context. TOLAP is intended to filter at the tool/data boundary instead.
Where it fits beside existing controls
Database row-level security can restrict a query at the storage layer. An API gateway can decide which endpoint a caller may reach. A prompt can state the desired behavior, and an output filter can catch some disclosures after generation. These controls solve different problems. TOLAP adds policy around the tool function and its returned objects; it does not replace database permissions, authentication, or a gateway. Our Google API Gateway MCP analysis covers endpoint exposure and governance, while the WebMCP permission guide discusses user approval for site actions.
For example, a support agent might be allowed to answer whether an order was shipped. The application could authorize the order lookup but omit payment identifiers, unrelated customers, and internal fraud flags from the returned object. The desired result is a narrow answer with enough evidence for the task, not a full record that the model is merely instructed not to repeat.
A small implementation test
Start with one low-risk tool and a synthetic dataset containing an allowed field, a forbidden field, an allowed row, and a forbidden row. Define the user, purpose, and policy context. Test the wrapped function with authorized and unauthorized requests, then inspect the raw tool response before the model sees it. The forbidden values should be absent there—not only absent from the final answer.
Next, attempt the same data access through every other path the agent can reach. AWS explicitly warns that TOLAP only enforces policy where its wrapper is used; a direct database connection bypasses it. Test expired and replayed signed contexts as well. AWS says the signed expiry bounds replay, but a valid context remains reusable during its lifetime unless the optional replay guard is enabled. Keep lifetimes short and review the repository’s full limitations before production use.
The LLM judge is an advisory layer.
TOLAP also describes an optional LLM judge for semantic alignment: a query may obey structural rules yet drift away from the user’s stated purpose. That judge runs after deterministic checks and is off by default. AWS notes that its assessments can vary across runs, so it is not a compliance gate. Treat it as an additional signal for review, not a way to override a denied field or replace deterministic access control.
TOLAP is most useful as a design reminder: authorize not only the action an agent can take, but also the particular data it can observe. Before adoption, map every path to the protected data, prove that the wrapper is on each intended path, and keep a test showing the forbidden value never reaches the agent. The strongest security claim is the one your own boundary tests can reproduce.
