AWS’s TOLAP release puts object-level access control inside AI-agent tools

The most important detail in AWS’s new TOLAP project is not the acronym. It is the location of the enforcement point.

AWS Labs has published TOLAP, or Tool-Object Level Access Protocol, as an open-source security layer for AI-agent tools. The project is designed to decide what data may leave a tool after an agent invokes it: which rows are visible, which fields are hidden or masked, which endpoints are allowed, how many results can be returned, and whether the requested action is within the purpose of the delegation. Its first public release is a useful sign that agent security is moving away from a simple question—“may this identity call this API?”—toward a harder one: “what exactly may this particular call disclose or change?”

That distinction matters for teams building agents over databases, internal APIs, knowledge bases, object storage, and MCP servers. A normal permission check can authorize a connection while still leaving the tool free to return far more data than the user or workflow needed. TOLAP’s proposal is to put a policy wrapper around the function that actually fetches or changes the data, then enforce the policy before the result enters the agent’s context.

The project is not a replacement for identity management, network controls, database permissions, or human approval. It is a narrower control intended to close the gap between tool access and object-level exposure.

What AWS has released

AWS Open Source describes TOLAP as a source-point enforcement layer. The repository is available under the Apache 2.0 license and includes a policy schema, enforcement libraries for .NET, Python, and TypeScript, a reference policy server, examples, documentation, and integrations with popular agent and tool frameworks.

The central model is declarative. A policy can identify permitted objects and actions, hide selected fields, mask values, filter rows, restrict storage prefixes or API methods, apply result limits, and attach audit information. The examples use a healthcare-style dataset: an agent might be allowed to query patient records, but not receive Social Security numbers; email addresses might be returned as hashes; and rows might be limited to particular regions.

That is different from giving the agent a database credential with broad read access and asking the model to behave responsibly. In the TOLAP model, the agent can still construct a query through the tool, but the wrapper applies the effective policy to the result. Data rejected by the policy is removed before it becomes part of the model’s context.

AWS says the project’s SDKs share a versioned policy schema and common test fixtures so the implementations are intended to behave identically across languages. The repository also includes integrations for MCP SDKs, Strands, LangChain, LangChain.js, Vercel AI SDK, Mastra, OpenAI Agents, Pydantic AI, Semantic Kernel, and Bedrock Agents. Those integrations do not turn TOLAP into an MCP server. The project wraps the function used by the tool layer; the application still owns the data fetch.

For production use, the repository includes a policy server backed by PostgreSQL, immutable policy versions, publish and rollback operations, an audit trail, Cognito-authenticated administration, and signing-key rotation with an overlap window. Those components are reference infrastructure, not evidence that every organization should deploy the full stack.

Why ordinary tool authorization is not enough

Most agent architectures already have several permission layers. A user authenticates to an application. The application gives an agent a service identity or delegated token. A gateway checks the token. The tool calls a database or API. Each layer is valuable, but none automatically answers the object-level question.

Consider an internal support agent with permission to query a customer table. A role check may correctly say that the support application can call the customer-search tool. It does not necessarily say:

• which customers the requesting employee is allowed to see;
• which columns should be omitted;
• whether the result may include customers outside the employee’s region;
• whether an address may be returned in full;
• whether the query is allowed to return 5,000 rows;
• whether a read operation has quietly become an export operation.

A gateway can authorize the endpoint. A database can enforce grants. An application can filter responses. But if those decisions are spread across custom code, the effective boundary becomes difficult to inventory and test. The more frameworks, connectors, and agent runtimes an organization adds, the easier it is for one path to omit a check.

TOLAP’s architectural argument is that the tool is the last reliable place to prevent data from entering the agent context. Prompt instructions are not a security boundary. A model can misunderstand a rule, follow a malicious instruction embedded in retrieved content, or combine individually permitted results into a disclosure that the designer did not expect. If a sensitive field never crosses the wrapper, the model cannot recover it from its context.

This does not make the tool trustworthy by magic. The wrapper must be the only path to the protected source, and the application must prevent alternate credentials or unwrapped code paths from reaching the same data. Source-point enforcement is useful only when the source point is actually controlled.

The release adds more than row and field filtering

The first version’s object-level controls are the most immediately understandable part of the project. The newer material also describes controls around the purpose and sequence of agent actions.

TOLAP policies can include purpose profiles that narrow which policy applies to a request. Action validation then checks whether a tool call belongs to the permitted action set. If a prohibited action is present, it is rejected; if an allowed-action list exists and the requested action is not on it, it is rejected as well.

The project also describes delegation-chain validation. That matters when one agent invokes another agent or when a workflow passes authority through several services. A downstream component should not silently receive broader authority than the upstream grant. In a well-designed chain, each delegation preserves or narrows the scope, and the resulting decision remains attributable to the original authority.

The order is important. Purpose filtering chooses the applicable policy. Action validation checks what the tool is being asked to do. Object-level enforcement then controls what data may be returned or changed. Each stage is described as fail-closed and independently testable.

AWS also documents an optional semantic-alignment layer using an LLM judge. This is the most delicate part of the design. Deterministic rules can check a table, field, row filter, action, or endpoint. They cannot always determine whether a sequence of individually valid queries is consistent with the declared purpose. A judge can review the purpose description, the current tool call, and a recent history window, then allow, block, or escalate according to confidence thresholds.

The project places that judge after deterministic enforcement rather than before it. That ordering is sensible: a model should not be able to persuade a second model to reveal a field already forbidden by a structural policy. The judge is described as optional and off by default, with an administrator-controlled prompt that the agent cannot edit.

Organizations should treat the judge as an additional signal, not as a substitute for deterministic access control. Its output is probabilistic, its configuration needs evaluation, and ambiguous cases should have an explicit review path. The strongest boundary in this release remains the ordinary one: do not return data that the policy forbids.

What this changes for MCP and agent-tool teams

The practical impact is greatest for teams that are adding tools faster than they are adding authorization design.

MCP makes it relatively easy to expose capabilities to a model. The security question is not only whether the server requires authentication. It is also whether each tool has a narrow data contract and whether the server filters the result before the client or model sees it. A tool that returns an unrestricted database result is still broad even if the MCP connection uses a short-lived token.

The same problem appears outside MCP. An OpenAI Agents tool, a LangChain retriever, a Bedrock Agent action group, a function-calling endpoint, or a custom Python wrapper can all become an accidental disclosure boundary. TOLAP’s approach is deliberately below the model framework: put the policy around the function that talks to the source, then keep the same enforcement model when the orchestration layer changes.

That separation has an operational benefit. Teams can test the security behavior without testing the model’s ability to follow instructions. A policy test can assert that a prohibited column is absent, a row filter is applied, a result cap is honored, and a prohibited action fails. Those are ordinary software and security tests. The model can then be evaluated for usefulness on the reduced result set.

There is a tradeoff. A wrapper at the tool boundary sees what the tool returns, but it may not understand every business meaning in the data. A policy can hide a field and filter a region. It may be harder to express that “these five permitted queries together create a prohibited inference” without maintaining history or adding a semantic review step. That is why the release’s deterministic and semantic layers should be understood as complementary rather than interchangeable.

The boundaries that still belong to the application

TOLAP does not eliminate the need for conventional security controls.

Identity still matters. The policy needs a reliable subject, group, role, service account, or delegated principal. If every request arrives as the same overpowered service identity, object-level rules may have too little context to make a meaningful decision.

Credential design still matters. A wrapped tool should not have a credential that can bypass the wrapper and access the source directly. Short-lived credentials, scoped roles, network restrictions, secret rotation, and separate identities for development and production remain basic controls.

The source system still matters. Database row-level security, API authorization, storage policies, and application-level business rules should continue to enforce their own boundaries. TOLAP can reduce what an agent receives, but it should not be the only protection around a critical database or irreversible operation.

Approval design still matters. Hiding fields does not make a destructive action safe. Deleting a record, changing a payment, rotating a key, or deploying code may need a human approval step, a two-person rule, a transaction preview, or a reversible workflow. TOLAP’s action validation can reject calls outside a scope, but an allowed action can still be too consequential to run automatically.

Observability still matters. The useful audit event is not just “tool called.” It should connect the human or service that delegated authority, the agent identity, the purpose, the tool, the effective policy version, the data scope, the result size, the decision, and any approval. Without that context, incident responders may know that a query ran but not why it was permitted.

Finally, governance still matters. Policies need owners, expiry dates, review triggers, version control, rollback, and tests that run when a connector changes. A policy wrapper can become a false sense of safety if no one checks whether the underlying tool has gained a new parameter or a new route around the enforcement function.

A sensible evaluation plan

Teams do not need to adopt the entire TOLAP stack to learn from the release. The design suggests a practical review of existing agent tools.

Start by inventorying the actual data paths. For every agent tool, identify the function that reads or mutates the source, the credential it uses, alternate access paths, and the point at which the result becomes model-visible. Draw the path from user request to tool call to source response. If the team cannot name the enforcement point, it probably cannot prove the boundary.

Next, separate capability authorization from data authorization. “The agent may use customer search” is a capability statement. “The agent may see customers assigned to this employee, without date of birth and with email masked” is a data policy. Put both in testable form.

Then create negative tests. Ask whether the wrapper blocks a prohibited table, removes a restricted field, filters rows outside scope, masks sensitive values, caps unusually broad responses, rejects an unapproved action, and fails closed when policy resolution or signing fails. Test direct access with the tool credential as well as access through the normal agent path.

Test composition, not only single calls. A model may obtain sensitive information through several harmless-looking queries, or pass authority from one agent to another. Log and review sequences, delegation changes, and repeated exports. If business purpose matters, define when a sequence needs human review instead of trying to encode every interpretation in a prompt.

Finally, measure developer friction. A security layer that is too difficult to integrate will be bypassed. The right question is not whether a wrapper can express every policy imaginable. It is whether the organization can make the safe path the easiest path for every connector and framework it supports.

Why this release is worth watching

TOLAP is an early open-source answer to a problem that many agent deployments currently solve with scattered middleware and conventions. Its most useful contribution is conceptual: access to a tool is not the same as authorization to every object the tool can reach.

That distinction is becoming more urgent as agents move from conversational search into workflows that query production systems, summarize private records, call APIs, and delegate tasks to other agents. Existing identity platforms remain necessary, and providers are adding agent identities, conditional access, and policy controls. But identity at the outer layer does not automatically constrain the shape of a result at the inner layer.

The project should be evaluated as infrastructure, not as a turnkey safety badge. Read the threat model. Verify that every source path is wrapped. Review the policy schema and failure behavior. Run the examples against representative data. Check whether the license, dependencies, supported runtimes, and operational model fit the organization. Treat the optional LLM judge as a review aid that needs its own validation.

The immediate advice for platform and security teams is straightforward: for every agent tool that touches sensitive data, define the smallest useful result before the model sees it. Enforce that definition in code at the data boundary, keep the credential from bypassing it, and record which policy made the decision. AWS’s TOLAP release gives teams a concrete open-source project to inspect while making that architecture easier to discuss.

This is the material change: the security boundary for an AI agent is not only the identity that starts a request. It is also the function that decides what may cross into the agent’s context.