The Four-Boundary Check: Securing AI Access Across Tenants
AI privacy fails when access is approved once and never rechecked. The four-boundary check enforces identity and authorization at every step.
Yash Sharma4 min readSecure LLM and agent execution
Research area 38: Privacy, identity, authorization and tenant-isolation engineering
In brief
- An AI agent's access must be rechecked as conditions change, not approved once and trusted forever.
- The four-boundary check rechecks authority at retrieval, context, execution and output.
- Ignoring it costs unauthorized effects, incomplete deletions and losses discovered only after the fact.
Privacy, identity, authorization and tenant-isolation engineering proves that an AI agent's access to data and actions still holds once conditions change: a recipient is swapped, a credential is revoked, a cache is shared across customers, or a person asks to be forgotten. Reported 2026 incidents kept tracing back to two failures: authority granted once and never rechecked, and a deletion that reached one copy of a record while derivative copies survived untouched. An executive shipping agents into regulated or multi-tenant environments needs to know what a permission checks and when, because a broad grant that looked safe in review is the mechanism behind nearly every leak.
What it is
Identity, authentication and authorization are three different questions. Identity answers who or what is acting, authentication establishes a claim to that identity, and authorization decides whether this specific principal may carry out this specific effect, right now. Privacy is broader than any single check: it spans collection, use, inference, retention and disclosure, and a system can be authorized to act while still failing privacy on disclosure. Tenant isolation means real boundaries across the infrastructure agents share, retrieval indexes, embeddings, caches and logs, not separate labels on a screen.
Four principles hold the area together. Authority binds to the exact effect, principal, tenant, resource, recipient, purpose, expiry and delegation depth, not a broad tool name, and it is rechecked at every point it is used, not only where the request enters. Revocation is a live condition that must reach queued work, running subagents and cached decisions the moment they try to take effect. Deletion travels with the data: a record removed from one store but surviving as a summary or cached copy was never actually deleted, only relocated. A 2026 review of 21 permission-design proposals and five commercial systems found clearly described revocation in only six, proof that a consent screen says nothing about the backend once access is pulled.
The architecture
My framework for this area is the four-boundary check: bind authority to the exact effect, then recheck it, deterministically, at four points in the data's path, retrieval, context assembly, execution and output, rather than trusting one permission granted at the start.
The capability carries eight parts: principal, tenant, resources, actions, purpose, expiry, delegation depth and policy epoch, alongside a digest of the exact arguments and recipient. If either changes, the digest no longer matches and the system must seek a fresh decision.
Retrieval filters what reaches the model using authenticated tenant and resource permissions, not what a prompt claims. Context assembly checks that nothing downstream quietly joins one tenant's material with another's. Execution enforces the capability against the exact sink and action, not a general tool name. Output validates what is about to be disclosed as its own separate decision, because a system can retrieve and reason correctly and still leak on the way out.
Two failure modes recur. Translation error grants the wrong recipient or resource when a compiler turns plain language into a policy rule, and default-deny execution only enforces that wrong rule consistently. Incomplete reach is revocation that never touches a queued task, a running subagent or a cached decision. A model precise on paper but rechecked at only one boundary is one gate with three open doors behind it.
How to lead it
Ownership belongs with a single identity and privacy engineering function operating all four boundaries as shared infrastructure, reporting jointly to the chief information security officer and the chief privacy officer. Fund a capability-issuing service binding authority to the exact effect and recipient digest, an independent cross-tenant conformance suite testing retrieval, caching, retries and output after every change, and revocation propagation reaching derived artifacts, embeddings and queued work, proven with a residual-recoverability test rather than a row count.
Measure adversarial requests blocked, residual data recoverable after deletion, and how long revocation takes to reach cached work. A signed token or an encryption certificate is not proof of end-to-end protection.
Three decisions belong to an executive alone: the differential-privacy budget the organization accepts for a federated feature, since that number trades utility for a measurable privacy bound, whether shared cache infrastructure is worth its latency advantage against an unclosed timing channel, and whether a new multi-tenant feature ships before or after an independent conformance suite has run.
What it is worth
The money and the risk show up in the same three places: unauthorized effects a broad permission let through, information that survives a deletion the business believed complete, and the cost of discovering either after the fact. Task-scoped authorization moved from 71 of 100 tasks completing without added friction to 100 of 100 after refinement, with all 634 adversarial requests in the same benchmark blocked, at two-tenths of a cent to under four cents per task. Deletion coverage moved from 36 of 300 facts recoverable after ordinary deletion to 6 of 300 once deletion logic reached semantic derivatives, real progress and still not zero. Selective cache isolation kept most of the latency and reuse benefit of a shared system while narrowing, not closing, a timing side channel.
What the evidence does not support is a claim that these mechanisms, together or alone, prove a full production data flow is private. No 2026 study reviewed here independently audited an entire deployed system end to end, and that gap is where an executive's remaining exposure sits.
Questions leaders ask
- Does encrypting our data make an AI agent's data access private?
- No. Encryption protects data while stored or in transit, but does nothing against misuse by an endpoint already authorized to read it. The 2026 evidence treats encryption as one control among several, alongside authorization checks, retention limits and deletion propagation. An encryption certificate proves one protected path, not that the whole data flow is private.
- If we delete a customer's data from our main database, is it gone?
- Not necessarily. A 2026 study built to test this found that after deleting a person's text records, 36 of 300 probed facts remained recoverable from images the deletion never touched, a rate that fell to 6 of 300 once deletion logic covered semantic derivatives. A successful delete call proves that call's effect, not that every summary or cached copy is gone.
- Can two customers safely share the same AI infrastructure to save on cost?
- Partially, with the right controls. A 2026 study of shared prompt caching across nine models kept up to 70 percent of cache reuse and cut latency by 30 percent against full per-tenant isolation, while leaving some timing-based exceptions unresolved. Shared infrastructure can be a reasonable trade, but it needs its own conformance testing rather than an assumption that separate accounts mean separate protection.
- Does a signed approval token mean an AI agent's action was properly reviewed?
- Not fully. A signature authenticates who issued the token, not whether a human reviewed the exact meaning of what they approved. If the recipient or resource in a request changes after approval, the original token no longer matches and should not authorize the new effect. Review has to expose the actual consequence of an action, and rechecking has to happen at the moment the effect runs.
- Who should set the differential-privacy budget for a federated AI feature?
- An executive, not the machine learning team alone, because the budget trades measurable utility for a measurable privacy bound and has to reflect what the business will risk, not what maximizes a benchmark score. A 2026 federated fine-tuning study reported real accuracy gains at fixed privacy budgets, but those gains say nothing about whether the underlying accounting was independently audited, a separate, unresolved decision.
