TOLAP: Closing the data-object security gap in AI agent architectures

If your organization deploys AI agents across organization or government environments, you’re likely discovering that security models can’t keep pace. Agents access data through tools such as plugins, function calls, and Model Context Protocol (MCP) servers, and those tools connect directly to source systems. The agent constructs its own queries, decides which endpoints to call, and determines what data to retrieve. Every interaction is an autonomous data-access decision.

Every major agent framework has a security model for this. Amazon Web Services (AWS), Microsoft, and Google each ship agent solutions with authentication and credential management built in. Amazon Bedrock Agents, for example, enforces AWS Identity and Access Management (IAM)-based authorization on which AWS Lambda functions, Amazon Simple Storage Service (Amazon S3) buckets, and Amazon Bedrock Knowledge Bases an agent might invoke. Each model authorizes whether the agent can invoke a tool. None enforce policy on what the tool returns. The gap between those two questions is where data leaks into the model’s context window.

The frameworks acknowledge this gap and tell you to fill it yourself. Tool-Object Level Access Protocol (TOLAP) closes that gap: It means organizations can deploy AI agents against sensitive data sources with confidence that access policies follow the data, not the agent.

Why traditional access models fall short

The instinct is to reach for existing access control models. No one designed them for the agent loop, and each has limitations in this context.

Role-based access control can’t say which columns are visible or which rows should be filtered. Attribute-based access control evaluates policy at a centralized engine, but agents that construct direct queries bypass it entirely. Database row-level security applies only to databases. APIs, knowledge bases, and object storage are out of scope. Content guardrails filter what the model says, not what the model sees; by the time they intervene, unauthorized data is already in the context window, available for summarization, reasoning, and exfiltration through prompt injection.

The question is no longer whether agent tools need data-object security. The question is what the standard for it should be.

Introducing TOLAP

TOLAP is an open protocol that moves access control to the only layer that can’t be bypassed in an agent system: the tool itself. The tool is the boundary between the agent and the data source. If the tool enforces policy at that boundary, every other layer above it becomes optional defense rather than load-bearing security.

Three principles

The properties described hold when a system conforms to the TOLAP specification:

1. Source-point enforcement – The system enforces security where data originates, not in a layer above it. The tool wraps the data source and applies policy before any data crosses the boundary. Because the tool is the only configured path to the data source, there is no route that bypasses enforcement. The tool is the security boundary.
2. Object granularity – Policies operate on individual data objects, not on tables, resources, or services. Columns, rows, fields, tags, endpoints, HTTP methods, similarity thresholds, file prefixes, and result limits are all first-class targets. A single TOLAP policy can simultaneously declare that a user can query the patients table, can’t see the ssn column, can see rows filtered to their assigned regions, and receives the email field as a SHA-256 hash.
3. Agent transparency – The calling agent requires zero security awareness code. Restricted data doesn’t exist from the agent’s perspective. Prompt injection attacks aimed at extracting unauthorized data have nothing to extract because the data wasn’t in the response. The defense is architectural, not behavioral.

Five components

A TOLAP-conformant system has five components, run in this order on every tool call:

1. Security Profiles are declarative, reusable policy definitions. An administrator authors a profile specifying allowed objects, hidden fields, masked columns, row filters, tag restrictions, endpoint access, and operational limits. Administrators assign profiles to users, groups, roles, or service accounts with mandatory audit fields—who granted access, when, and why—and optional time-bound expiry.
2. The Policy Resolution Engine computes the effective policy for a user and data source by merging all applicable profiles. The merge strategy is most-restrictive-wins:
   • Intersect allowed sets
   • Union hidden sets
   • Conjunctively combine row filters
   • Take the minimum value for numeric maxima
   • Require unanimous agreement for Boolean permissions
3. The Security Context packages the effective policy into a hash-based message authentication code (HMAC)-signed, time-bound, self-contained envelope. The system signs it to prevent tampering, time-stamps it to prevent replay, and makes it self-contained to eliminate database lookups at enforcement time. It transports cleanly across process, network, and cloud-account boundaries.
4. Secure Tool Wrappers enforce the policy at the data boundary: rewriting queries, masking fields, filtering results by classification, and enforcing volume limits.
5. The Secure Tool Factory instantiates wrappers with the correct security context and credentials for each request. Agents receive tools from the factory and don’t construct data access directly.

The following diagram illustrates how the five TOLAP components execute in sequence on every tool call, from policy resolution through enforcement at the data boundary.

Figure 1. TOLAP security architecture: Security profiles flow through the Policy Resolution Engine to produce a tamper-proof security context, which the Secure Tool Factory uses to instantiate wrappers that enforce policy on every tool call. The AI agent receives only filtered data and doesn’t see unauthorized information.

A peek at what a policy looks like

A short example makes the protocol concrete. This policy grants a healthcare analyst persona access to a clinical database:

{
  "name": "healthcare-analyst",
  "permissions": { "canQuery": true, "canExport": false, "readOnly": true },
  "objectRules": {
    "allowedObjects": ["patients", "encounters", "diagnoses"],
    "hiddenObjects": ["billing_internal", "audit_log"],
    "fieldRules": {
      "hiddenFields": ["patients.ssn", "patients.date_of_birth"],
      "maskedFields": [
        { "field": "patients.email", "maskType": "hash",
          "parameters": { "algorithm": "sha256" } },
        { "field": "patients.full_name", "maskType": "partial",
          "parameters": { "showFirst": 1, "maskChar": "*" } }
      ]
    },
    "rowFilters": [
      { "field": "region", "operator": "in", "values": ["us-east", "us-west"] },
      { "field": "status", "operator": "notEquals", "value": "deleted" }
    ]
  },
  "limits": { "maxResults": 5000, "maxQueryTimeSeconds": 30 }
}

Under this policy, the agent doesn’t see ssn or date_of_birth (absent from the schema), receives email as a SHA-256 hash and full_name as “J*********”, sees only us-east and us-west rows excluding deleted records, and is capped at 5,000 results with a 30-second timeout. None of this is visible to the agent.

Cross-source coverage with one schema

The same protocol covers databases (Amazon Athena, Amazon Redshift, PostgreSQL, MySQL, BigQuery, Synapse, and others), APIs (REST, GraphQL, SOAP, FHIR, HL7, gRPC), knowledge bases (Amazon Bedrock Knowledge Bases, Amazon OpenSearch Service, Azure AI Search, Elasticsearch), and object storage (Amazon S3, Azure Blob Storage, Google Cloud Storage). Each source category interprets the relevant fields of one shared policy schema. One schema, all source types. Adding a new connector means writing a more secure tool wrapper, not redesigning the authorization layer.

Why this matters for the public sector

Public sector organizations face unique pressures when deploying AI agents. Government agencies handle citizen data subject to strict regulatory frameworks. Healthcare systems manage protected health information across federated environments. Defense and intelligence communities require compartmentalized access that adapts to mission context. TOLAP helps these organizations maintain compliance and preserve public trust by deploying AI agents at scale with consistent, enforceable access controls.

An open standard, available today

The specification

TOLAP defines a protocol-agnostic specification anchored in a versioned JSON Schema covering policy definition, policy assignment, and the merged effective policy.

The SDK

A reference SDK ships in .NET, Python, and TypeScript, each as three packages. The core package contains models, the merge algorithm, HMAC signing, and the enforcement engine with zero external dependencies. The store package defines a pluggable policy-storage interface with an in-memory implementation. (DynamoDB, PostgreSQL, or Redis can sit behind it without changing the rest of the system.) The MCP package wraps any MCP server with TOLAP enforcement: drop-in, no changes inside the tool implementation.

Security properties

By design, a TOLAP implementation provides:

1. Non-bypassable enforcement – When correctly configured, the tool is the only path to the data source
2. Tamper resistance – Effective policies are HMAC-signed; modification invalidates the signature
3. Replay resistance – Signed contexts are time-bound and expire
4. Cross-boundary integrity – Signed contexts transport cleanly across process, network, and cloud-account boundaries without losing their protections
5. Thorough audit – Every assignment carries mandatory audit metadata: who granted it, when, and why

TOLAP versus traditional approaches

The following table summarizes how TOLAP compares to traditional access control approaches across key dimensions relevant to AI agent deployments:

The bottom line

AI agents are accessing enterprise data at scale through tools. The security model that protects that data must operate inside the tool itself, not at the gateway, application, or in the prompt. TOLAP is declarative, auditable, transparent to the agent, and non-bypassable by design. The specification, the schema, and the reference SDK are open and available today.

Two questions for your team:

1. Where in your agent architecture does data-object policy enforcement live today? If the answer is “at the gateway,” “in the application,” or “in the agent’s prompt,” the architecture has the gap this protocol closes.
2. Would your enforcement survive prompt injection if the tool received unfiltered data? If the answer requires the agent to behave correctly, the answer is no.

Next steps

To explore the TOLAP specification, JSON Schema, and reference SDKs, visit the TOLAP open standard repository. For questions, contributions, or implementation guidance, see the project documentation.