DEV Community: Dudko Development

When the data arrives with someone else's rules

Dudko Development — Fri, 13 Nov 2026 15:39:56 +0000

On Monday's article about whose permissions an MCP search runs with, the hard part was a single question: who is asking. This one is the next question, and people are now running into it in public.

A commenter on Hacker News described how their team feeds company knowledge to agents: everything ingested stays linked "to the source" and to "the authorisation layer of the source that was ingested". Their example is a wiki whose permissions live in Windows AD, so that information "needs to be collected when you ingest". And then the line that's the whole problem: "Such connectors are source specific and must be aware how the system manages permissions."

That's right, and it gets harder with every source you add. A shared index rarely holds one company's one system. It holds the wiki (AD groups), the ticket tracker (project roles), a shared drive (link sharing, folder inheritance), and sooner or later a partner's records that arrived under the partner's terms. Each of those has its own rulebook. One retrieval step has to honour all of them at once, and it's the same step that ranks.

There are two ways to build that, and I think it's worth being plain about what each one makes you own.

Design one: copy the source's ACL onto every chunk

At ingest, the connector reads the source's permissions for each document and writes them into the chunk's payload: a list of users or groups allowed to read it. At query time, the search filters on that list.

The appeal is obvious. Permissions come from the system that already has them, nobody re-types anything, and a document that's private in the wiki is private in the index.

What you take on:

Drift. The ACL on the chunk is a copy, made at ingest. How much that matters depends on what you copy. If the connector flattens groups into the users they contain, someone removed from an AD group at 10:00 can still read until the next sync touches that document, and if documents are re-synced only on content change, an unchanged page may keep its stale list for a long time. If the chunk stores group IDs and you resolve membership at query time, a group change lands on the next search, and what drifts is the document's own ACL instead: a group added to or removed from a wiki space after ingest. Either way, a change to the source's sharing settings waits for a sync.
One translator per source. Every source's model has to be flattened into whatever your index can filter on. AD nested groups, Drive's "anyone with the link", Jira's project roles plus issue security levels. Each connector carries its own translation, and each one is a place for a quiet mistake.
Revocation runs at sync speed. That's the real cost, and it's the one that shows up in an incident review.

We actually specified a version of this, built it, and took it out. Our authorization spec has the post-mortem: each chunk was to carry hashes of the principals allowed to read it, with a background sweep keeping them fresh and an alert on how far behind it fell. The tags were computed, the sweep ran, the alert paged, and no query ever read them. The reasons for removing rather than finishing it are in that section; the one that matters here is that a copied permission is "stale in the wrong direction". It can only ever lag the real one.

Design two: keep each source in its own boundary, grant at the boundary

The other way is to not copy the source's rules at all. Each source, or each part of a source with its own audience, goes into its own container. Access is granted on the container, and the search resolves the caller's permitted containers on every request, from the live grant table.

In Nacre that container is a layer. Scopes form a tree, workspace → layer → document; grants name a user, group or service account; and with no grant there's no access. The reference connectors work this way: a rule per layer (a path in a repository, a key prefix in a bucket, a query over a table) decides where each source item lands, and the connector's own key only needs write on those layers. It never searches.

What this makes you own is different, and I'd rather say it straight than have you find it out:

The mapping is yours. Nacre does not read the wiki's AD permissions and mirror them. If the wiki's HR space is readable only by HR, you route that space to a layer and grant that layer to the HR group. Group membership can be managed through the API; syncing it from your directory is a separate module, not part of the open-source build.
The grain is coarser by default. A layer is a boundary you choose. If a source has thousands of documents each with its own hand-made sharing list, a layer per audience may not be fine enough, and the honest answer for that source may be design one, or not indexing it at all.

What you get back is that revocation is a write to one table and takes effect on the next search, because nothing downstream holds a copy. We measured that on the core API in August: 79 ms for a direct grant and 58 ms for leaving a group.

Either way, the boundary has to hold before ranking

Whichever design you pick, apply it inside the search, not after it. If you rank the whole index and then strip what the caller can't see, two things go wrong. The caller asked for ten results and gets four. And anything built from the pre-strip set, a summary, a citation count, a "3 more results hidden", tells them that documents exist in a place they can't read.

That second leak is the one to test for, and it's easy to test: ask, as someone who can't read a source, for results from that source by name, and compare the answer to what you get for a source that doesn't exist. If the two differ in any way, status code, body, error wording, timing you can see without trying hard, the boundary leaks its own existence.

Try it: one source by name, two readers

Our public stand has a demo company with two read-only logins, printed on demo.nacre.work. The engineer reads two layers, engineering and handbook. The contractor reads only handbook. The search API takes an optional layers list, and the API docs say it narrows only: it can't reach a layer no grant reaches, and "naming a layer you cannot read returns nothing from it and is indistinguishable from naming one that does not exist."

Here's that claim as a script. The passwords rotate, so copy them from the demo page rather than from here.

#!/usr/bin/env bash
# Ask for one layer by name, as two readers, and compare with a layer that doesn't exist.
# Passwords: copy them from https://demo.nacre.work
set -euo pipefail
API=https://playground.nacre.work/v1
Q='what is the contract number for Northwind'

token() {   # $1 login name, $2 password
  curl -s "$API/auth/login" -H 'content-type: application/json' \
    -d "{\"email\":\"$1@demo.nacre.work\",\"password\":\"$2\",\"organization\":\"demo\"}" \
  | jq -r .access_token
}

ask() {     # $1 who, $2 token, $3 layer name
  body=$(curl -s "$API/search" \
    -H "authorization: Bearer $2" -H 'content-type: application/json' \
    -d "{\"query\":\"$Q\",\"top_k\":10,\"layers\":[\"$3\"]}")
  echo "$1 asks for $3: $(jq -r '"\(.items|length) results from [\([.items[].layer]|unique|join(","))]"' <<<"$body"), $(printf %s "$body" | wc -c) bytes"
}

ENG=$(token engineer "$ENGINEER_PASSWORD")
CON=$(token contractor "$CONTRACTOR_PASSWORD")

ask engineer   "$ENG" engineering
ask contractor "$CON" engineering
ask contractor "$CON" no-such-layer

What it printed today, 12 November:

engineer asks for engineering: 5 results from [engineering], 3435 bytes
contractor asks for engineering: 0 results from [], 12 bytes
contractor asks for no-such-layer: 0 results from [], 12 bytes

Side by side, with the plain search (no layers at all) for the contractor added:

reader	asks for layer	HTTP	results	response body
engineer	`engineering`	200	5	3,435 bytes, all from `engineering`
contractor	`engineering`	200	0	`{"items":[]}`, 12 bytes
contractor	`no-such-layer`	200	0	`{"items":[]}`, 12 bytes
contractor	(none: every readable layer)	200	3	all from `handbook`

The contractor's answer for a real layer they can't read is byte-for-byte the answer for a layer that was never there. And with no layers at all, the contractor still gets three results, from the one layer they can read, rather than three minus whatever was stripped.

One thing this test doesn't show, and I'd want you to know it: response time. I didn't measure it carefully enough to make a claim either way, so treat it as an open item if timing matters in your threat model.

What neither design fixes

A source whose own permissions are wrong. If the wiki's HR space is open to everyone, design one copies that faithfully and design two only helps if whoever writes the mapping notices. Garbage rules in, garbage rules out.
Grants that are too broad. Granting a whole workspace to "all staff" because it was quicker undoes the layers below it.
Whatever's already in the model's context. Once text has been returned to an agent, the index's permissions are finished with it. What the agent does next is the agent's problem and the user's.
The mapping work itself. In design two it's a one-time decision per source, plus upkeep when the source reorganises. That's real work. It's also visible work, in a grant table you can read, which I'd take over a translation buried in a connector.

If your sources are a few systems with clear audiences, I'd grant at the boundary. If one source has fine-grained, per-document sharing that people genuinely rely on, copying its ACLs may be the only way to honour it, and then the questions to ask of that design are how often it syncs and what happens in the gap.

The open-source build is on GitHub under Apache-2.0, and the authorization spec is the document to read before trusting any of this, including from us.

Originally published at https://nacre.work/blog/when-the-data-arrives-with-someone-elses-rules.

Whose permissions does your MCP search run with?

Dudko Development — Fri, 13 Nov 2026 15:39:48 +0000

Someone on Hacker News asked last week what people's biggest concern is when building an MCP server. The top answer is permissions: what a user may see on the site and what the agent may see through MCP are two different things, and nobody quite owns the gap between them.

It's a fair worry, and it isn't hypothetical. A survey of 20 reachable public MCP servers published this month found 8 with no authentication at all, and only 2 advertising OAuth discovery.

So here's the question I'd ask of any MCP server that searches company documents, ours included: when the agent calls search, whose permissions does that search run with? There are three parts to a good answer, and most servers have one or two of them.

Part one: who is asking

Most MCP servers that sit in front of a document store authenticate with one key. It goes in a config file, it belongs to the integration, and it can usually read everything the integration was set up to read. Every person who talks to the agent searches with that key.

That works until two people with different access use the same agent. Then the agent shows the intern whatever the key can reach, and the only thing standing between the intern and the board minutes is the system prompt.

The fix is to make the search run as the person. The MCP spec already has the plumbing: the server answers an unauthenticated call with 401 and a pointer to its protected-resource metadata (RFC 9728), and the client runs an OAuth flow against the authorization server named there. That part is the spec's, not ours, and any server can do it. You can see it on our public stand:

curl -si -X POST https://playground.nacre.work/mcp \
  -H 'content-type: application/json' -d '{}' | grep -i www-authenticate
# www-authenticate: Bearer resource_metadata="https://playground.nacre.work/.well-known/oauth-protected-resource"

What OAuth gives you is an identity. It doesn't decide what that identity may read. That's the second part, and it's where the interesting failures are.

In Nacre, a connection approved through OAuth is a delegation: it acts as the person who approved it, and the token carries their id rather than a copy of what they can see. The person can narrow it further when they approve it, to some layers or to read-only, but never widen it (docs/authz.md, "Delegated authority"). Service account keys still exist, for unattended pipelines that belong to the organization rather than to anyone in it. They're just not how a person's agent should search.

Part two: where the filter runs

Say the search does run as the right person. The next question is when their permissions are applied.

The easy way is a post-filter: ask the index for the 10 nearest chunks, then drop the ones this person can't read. It's easy because the vector index doesn't need to know anything about permissions. It also breaks in two ways that are hard to spot in testing.

The count. Ask for 10, get 3, because 7 of the nearest neighbours belonged to a layer you can't read. The agent writes its answer from 3 chunks and has no idea anything is missing. On a small test corpus where everybody can read everything, this never shows up.
The leak. The 7 dropped chunks still shaped the response. Fewer results than asked for, or a slower answer, or a strange ranking, tells a careful caller that something it can't see matched the query. That's information.

The alternative is a pre-filter: the permission check runs inside the index traversal, so a chunk the person can't read is never a candidate in the first place. Our authorization spec writes the property down as an invariant:

I2. The number of results does not depend on whether the filter ran before or after ranking. A user with access to 1 layer of 20 asking for top_k=10 gets 10 results — not 10 minus whatever was stripped.

And the companion to it, for fetching a single document:

I6. A request without permission is indistinguishable from a request for something that does not exist: 404, never 403.

I re-ran the I6 check against the public stand while writing this. A contractor asking for an engineering document that exists gets 404. The same contractor asking for an id that never existed also gets 404, and the two response bodies are identical once the request id is removed. The control is what makes that worth anything: the engineer asking for the same document gets 200. A server that answers 404 to everything would pass the first half.

Part three: how fast a revocation bites

Someone leaves a project. Their access is removed. How long can their agent keep finding the project's documents?

If the server copies permissions into the index, as metadata on each vector, the answer is "until the copy is refreshed". That might be a minute, or it might be the next nightly job.

Nacre doesn't copy them. The permitted set is computed per request from the grants table, and the one cache in front of it is keyed on a version number that every write to grants and groups bumps. So a revoked grant shows up in the very next search, because the next search computes a different key, not because something expired.

We measured it on a local stack in August, holding one bearer token throughout:

change	next search	time to take effect
a direct grant revoked	narrower	79 ms
added to a group that holds a grant	3 → 8 results	65 ms
removed from that group	8 → 3 results	58 ms

Two caveats that belong with those numbers. They cover groups managed through Nacre's own /v1/groups API. Syncing groups from your identity provider over SCIM is a commercial module and isn't in the Apache-2.0 build, so if your directory is the source of truth, the delay that matters is your sync's, and these numbers say nothing about it. And they're one machine on one day. The guarantee is structural, the milliseconds are just what it looked like.

Where this doesn't help

Grants live in Nacre. They aren't mirrored from the source. This is the gap I'd want to know about before anything else, so it goes first.

Nacre doesn't read the sharing settings of the system a document came from. You push documents into layers, through the API, the CLI or one of the reference connectors, and you decide who may read each layer. The connectors map a folder, a bucket prefix or a query to a layer. They don't carry per-file sharing across. The Google Drive one, for instance, walks a folder as a service account and sees what was shared with that account, not who else the file was shared with.

So if your permissions today live in a dozen per-file sharing settings, someone has to turn them into layers and grants, and keep that mapping honest as the source changes. That's real work and it's yours. It's also where systems like this usually go wrong, so if a vendor tells you their connector "inherits permissions automatically", ask what happens when the source changes them and how long until search agrees.

It works best when access already follows a structure you can name (a team, a project, a client, a clearance level) rather than a thousand individual decisions.

A few other things per-user permissions don't fix:

Prompt injection. A document the person may read can still contain instructions. Scoping what the agent reads to what the person may read limits the damage. It doesn't remove it.
Grants that are too broad. If everyone has been given read on everything, a perfect pre-filter faithfully returns everything.
What the model already saw. Revoking a grant stops the next search. It doesn't reach into a conversation that already has the document in it.

Try it: two readers, one query

The public stand has a demo company with two read-only logins printed on demo.nacre.work. They rotate, so copy them from the page rather than from here.

#!/usr/bin/env bash
# Two readers, one query. Passwords: copy them from https://demo.nacre.work
set -euo pipefail
API=https://playground.nacre.work/v1
ORG_DOMAIN=demo.nacre.work
Q='what is the contract number for Northwind'

search_as() {   # $1 the login's name (engineer, contractor), $2 its password
  tok=$(curl -s "$API/auth/login" -H 'content-type: application/json' \
    -d "{\"email\":\"$1@$ORG_DOMAIN\",\"password\":\"$2\",\"organization\":\"demo\"}" | jq -r .access_token)
  curl -s "$API/search" -H "authorization: Bearer $tok" -H 'content-type: application/json' \
    -d "{\"query\":\"$Q\",\"top_k\":10}" \
  | jq -r --arg who "$1" '"\($who): \(.items|length) results from \([.items[].layer]|unique|join(", "))"'
}

search_as engineer   "$ENGINEER_PASSWORD"
search_as contractor "$CONTRACTOR_PASSWORD"

What it printed today:

engineer: 8 results from engineering, handbook
contractor: 3 results from handbook

Same query, same index, two different answers, and neither one knows the other exists. Neither login gets the contract number itself, by the way. That's the point of the query.

To do the same through an agent, connect an MCP client to the stand and sign in when the browser opens:

claude mcp add --transport http nacre https://playground.nacre.work/mcp

The stand is a demo, not a hosted product: it's capped at 200 documents and erases itself every 24 hours. The real thing is the Apache-2.0 build you run yourself, on Docker Compose or Kubernetes, and the authorization spec is the document to read before you trust any of the above, including from us.

Originally published at https://nacre.work/blog/whose-permissions-does-your-mcp-search-run-with.