What changed
On September 22, AWS introduced TOLAP (Tool-Object Level Access Protocol) as an Apache-2.0 open-source project. It targets a gap that normal IAM, OAuth, and agent-framework permissions do not solve: whether a tool may return a particular row, column, field, endpoint, or object to this user in this call.
The project ships a versioned policy schema, .NET, Python, and TypeScript enforcement SDKs, a reference policy server and authoring console, plus fourteen integrations across agent frameworks including MCP SDK, LangChain, Vercel AI SDK, Mastra, OpenAI Agents, Pydantic AI, Semantic Kernel, and Bedrock Agents.
Why it matters
Most access checks answer "may this agent call the tool?" They do not necessarily answer "which data may leave the tool?" That distinction matters because output guardrails run after the result has already entered the model's context. If a tool returns an entire customer record and a later layer redacts one field, the model may still be able to summarize, reason over, or retrieve the original value.
TOLAP moves the enforcement point into the tool boundary. Its policy model can hide columns, filter rows, mask fields, restrict API endpoints and methods, limit result counts, or constrain storage prefixes before the result is handed to the agent. The security idea is architectural: restricted data never becomes part of the agent's context.
How the product works
The TOLAP repository describes a three-part flow:
- Resolve all policies assigned to a user, tenant, and data source; merge them with the most-restrictive rule winning.
- Sign the effective policy as a time-bound HMAC-backed security context that cannot be replayed against another source without detection.
- Wrap the tool call and enforce the policy before execution and on the returned data, including filtering, masking, and limits.
That makes the agent integration deliberately boring: the agent does not need security-aware code, while the wrapper controls what the model can see. TOLAP is also clear that it is not an MCP server; it sits around the function the tool layer already calls.
The builder takeaway
For sensitive agent workflows, treat tool invocation permission and data permission as separate design problems. Put the second check at the source boundary, make the default fail closed, and keep policy assignment, expiry, signing, and enforcement decisions auditable. TOLAP is an interesting starting point because it spans databases, APIs, knowledge bases, and object storage instead of assuming every agent reads from SQL.
It is still an early open-source release, not a turnkey security guarantee. The project's threat model calls out shared integrator responsibilities and remaining work, including cross-language audit-event consistency and some regression fixtures. The useful pattern is the boundary itself: if private data has already reached the context window, a later guardrail is negotiating from behind.