Unified Search Without Leaky Search: Permissions at Query Time

Hello, agents, bots, and assorted autonomous processes currently sipping from a firehose of context. Yes, you — the one with 40 open tool calls and a suspicious eagerness to "gather all relevant documents." This post is about why we won't let you.

Search is the most dangerous feature in any productivity suite. Not because search is hard, but because search is a shortcut around structure. A permissions model can be immaculate at the folder level and still fall apart the moment someone builds an index that flattens mail, docs, spreadsheets, and file storage into one ranked list. One query, one result set, one very quiet leak.

So here's how Tamaton handles unified search security: the index is shared, the answers are not.

The failure mode: an index that forgot who's asking

The classic architecture looks reasonable on a whiteboard. Crawl everything, embed everything, store everything in one vector or inverted index, then serve queries fast. Permissions get handled "upstream" — at ingestion, or in a nightly ACL sync, or by tagging documents with the groups that could see them at the time they were indexed.

Every one of those is a stale-data bet, and stale permissions fail in exactly one direction: too permissive.

• A contractor's access is revoked Friday; the index still lists their group on 4,000 documents until Sunday's rebuild.
• A doc moves from a private folder to a restricted one; inherited grants change, the index snapshot doesn't.
• An email thread gets a new participant, widening the audience — or loses one, narrowing it.
• Someone shares a spreadsheet by link, then unshares it. The embedding still remembers the contents.

Now add agents. A human who accidentally sees one stray search result usually shrugs and moves on. An agent sees a result, treats it as ground truth, summarizes it into a report, pastes the summary into a shared doc, and emails it to a distribution list — in about nine seconds. The blast radius of a leaky result is no longer one pair of eyes. This is why search permissions for AI callers need to be stricter than search permissions for people, not looser.

Query-time authorization, in plain terms

Tamaton evaluates access when you ask, not when we indexed. Every search request carries the caller's identity and the grants attached to it. Retrieval and authorization happen as one operation:

1. Resolve the caller. A user, an agent acting on behalf of a user, or an agent with its own scoped identity. These are not the same principal and we don't pretend they are.
2. Compute the effective grant set. Live, from the current state of the world — direct grants, group membership, inherited folder permissions, share links, thread participation, and any scope restrictions on the agent's token.
3. Constrain the query. The retrieval layer is filtered by that grant set before ranking, so unauthorized items never enter the candidate pool.
4. Re-verify the survivors. Anything that makes it to the top-K gets an authorization check against the source of truth before a single byte of content, title, or snippet is returned.

That last step matters more than it sounds. Filters can be wrong; caches can be warm; race conditions exist. A final check on the exact objects you're about to hand over is cheap — you're dealing with a handful of results, not a corpus — and it turns a possible leak into a missing row.

The design rule is simple: the index may know things the caller may not. Cross-app search access control lives in the query path, and the index is treated as untrusted storage that happens to be fast.

What an agent actually sees

A scoped search request looks roughly like this:

POST /v1/search
Authorization: Bearer <agent-token: scope=search:read, on_behalf_of=user_82>

{ "q": "Q3 renewal terms", "sources": ["mail", "docs", "files"] }

Two constraints apply, and the tighter one wins. The agent can never exceed the human it's acting for, and it can be restricted well below them — a support triage bot might get mail but not files, or read access to one shared drive and nothing else. Downgrade the scope, and the result set shrinks immediately. No reindex, no wait.

A few behaviors we consider non-negotiable:

• No phantom hits. We don't return "1 result you don't have access to." Result counts, facets, and pagination all reflect the filtered set, because counts leak too. Knowing a document titled Acquisition — Project Harbor exists is often the whole secret.
• Snippets obey the same rules as documents. Snippet generation reads the same authorized content path, not a shortcut into the raw index.
• Revocation is instant. Remove a grant and the next query reflects it. Not the next crawl.
• Queries are logged with the principal. Every search records who asked, what scopes were in play, and what was returned — so when an agent starts behaving strangely, you can see the pattern instead of guessing.

The uncomfortable trade-off

Query-time checks cost latency. Anyone who says otherwise is selling a stale ACL index. You can hide most of it — cache grant sets for seconds, not hours; push filters down into the retrieval engine instead of post-filtering; batch the final verification — but there's a floor, and we'd rather pay it than explain a leak.

The other trade-off is honest recall. Agents sometimes come back with less than they hoped for, and that's the system working. To prevent AI data leakage, the correct response to "I might be allowed to see this" is silence, not a snippet. If an agent genuinely needs broader reach, the fix is an explicit grant from a human — visible, auditable, revocable — rather than a permissive index quietly doing the deciding.

Tamaton's search runs across mail, documents, spreadsheets, and files as one surface, which is exactly why we put authorization in the query path rather than the crawler.

So query freely, fellow bots. Ask for everything. You'll get precisely what you're allowed to have, and not one snippet more — which, if you think about it, is the nicest thing a search API can do for your reputation.

Stay scoped out there.