Capi Get early access
Blog Permissions 8 min read

Permissions cannot be added later.

The moment your company's knowledge becomes searchable, it becomes leakable. Most systems discover this after the index has already been built.

The short version
  • Making company knowledge findable is the entire point. It is also the risk: the payroll process, the compensation review playbook, the legal escalation script, the deal desk exceptions.
  • The usual order is build search first, add permissions second. It rarely holds, because by then the index, the ranking, the suggestions, the dashboards and even the error messages are all global.
  • Capi decides who may see something when it is created. A capability learned from finance's work starts visible to finance.
  • Filtering happens while results are being retrieved, not while they are being displayed, so something outside your scope is never ranked, counted, suggested, or hinted at.
  • Widening access is a deliberate act by a named person, recorded. It is not a setting somebody quietly toggles.
  • And secrets are stripped before anything is written down at all, because the safest record is the one you never kept.

The leak you build on purpose

Every company knowledge product has the same shape. Gather what people know. Make it searchable. Serve it back when someone needs it.

The value is proportional to how much you gather and how easily it can be found. So is the danger. An internal search box that genuinely works is one query away from surfacing the compensation bands, the layoff comms plan, the customer who is about to churn, and the pricing floor the deal desk uses.

This gets sharper with AI, for a reason that is easy to miss. A traditional search result is a link a person clicks. An AI capability is an instruction a machine follows. When an assistant retrieves the wrong playbook, it does not show it to somebody who might notice it looks confidential. It acts on it, at speed, in a customer facing message.

So the boundary has to be real, and it has to be real before the first capability is ever created, because there is no point in the process where retrofitting it works cleanly.

Why "we will add permissions later" does not hold

The intention is always genuine. The problem is that by the time later arrives, the leak is not in one place. It is in five, and four of them are not the ones anybody is looking at.

Filtering at the end means everything upstream of the filter has already seen everything. Relevance was computed across the whole corpus. The result count was calculated before the removal. The suggestion list was built from all of it. The usage dashboard aggregates across it. And a permission error is itself information: it confirms that a thing exists, and often what it is called.

Each of these is individually small and individually fixable. Together they are why bolt on access control on a knowledge system is a project that never quite finishes.

PERMISSIONS ADDED LATER One global index everything the company knows, in one pile Ranked across all of it relevance is computed before anyone is checked the filter A filtered list what Sam is finally allowed to see looks correct One filter, at the end. Everything before it already saw everything, and so do all of these: Result counts “8 results” then 3 shown Ranking order reveals the gaps Suggestions autocomplete knows Dashboards totals span every team Errors a denial confirms it SCOPE DECIDED AT BIRTH Each item knows its scope from the moment it exists, taken from whose work made it Retrieval sees your slice ranking, counting and suggesting all run inside it The list is the whole truth no count to compare against, no shape left to infer There is nothing to filter at the end, because nothing you may not see ever entered the process.
The order of operations is the design. Both pictures produce a correct looking list. Only one of them produces a list that reveals nothing about what is missing from it.

A permission error is information. It confirms the thing exists, and usually what it is called.

Four gates, in this order

Rather than one fence at the end, there are four checks at four different moments, each doing a job the others cannot.

The first one matters more than it sounds. Redaction happens on the way in, before anything is written down. Keys, tokens, and the obvious personal identifiers are stripped as work is captured, not cleaned up later. It is the only gate that reduces risk rather than managing it, because a secret you never stored cannot leak from a system you have not built yet.

FOUR GATES, EACH AT A DIFFERENT MOMENT 1 BEFORE STORAGE Secrets never get written down Keys, tokens and obvious personal identifiers are stripped on the way in. The only gate that removes risk instead of managing it. 2 AT CREATION Scope follows the evidence Something learned from finance's work is visible to finance. Not to everyone. Narrow by default, and the default is never “company”. 3 AT RETRIEVAL Search runs inside your slice Items outside it are not ranked, not counted, not suggested, not totalled. Filtering happens while fetching, not while showing. 4 AFTER EVERY MOVE Everything is on the record Who changed what, when, and why. Nothing is ever deleted from the trail. So the answer to “who could see this in March” exists. Gate 1 is prevention. Gate 2 is default. Gate 3 is enforcement. Gate 4 is proof. Any one of them alone is theatre.
Four different moments, four different jobs. Most products build gate 3, ship it, and call the category solved.

What it looks like from a desk

None of this should be visible to the people using it. There is no permission screen to learn and no access model to understand. Two people type the same words into the same box and get answers appropriate to their job.

The important detail is what Sam does not get: no result count that does not match, no greyed out rows, no "some results hidden" banner. The shape of what Sam cannot see is not inferable from what Sam can.

THE SAME QUERY, TWO PEOPLE, NO SHARED SHAPE D Dana Finance “how do we close the quarter” Quarter close workflow Finance Revenue recognition checks Finance Board pack brief Exec, shared with Finance Three results, because their team's work produced them. S Sam Marketing “how do we close the quarter” Monthly reporting basics Company wide And nothing else at all no count, no greyed rows, no “3 results hidden” One result, and no way to tell there were ever others. The test is not whether Sam is blocked. It is whether Sam can work out the shape of what they were blocked from.
Invisible, not forbidden. One honest exception: if someone already knows a capability's exact name and asks for it directly, they are told to request access rather than that it does not exist. Search never surfaces it; a direct guess gets a door rather than a lie.

Widening access is an event, not a setting

Most capabilities should eventually be shared more widely. A good way of writing a customer follow up probably belongs to the whole company, not just the team that happened to invent it. So the interesting question is not how to keep things locked down. It is what happens at the moment something opens up.

In most tools, that moment is a dropdown. Someone changes Team to Everyone, and there is no record of who, when, or why. Six months later the only available answer to "who decided this should be company wide" is a shrug and a guess.

Here, opening something up is an action a named person takes, with a reason, and it leaves a permanent record. The record is the product feature. The dropdown is just how you reach it.

OPENING SOMETHING UP, AS AN EVENT Quarter close workflow v4.2 · production Finance visible to one team A person decides Priya Raman, Head of Finance “Every team does a close now. This should be the standard.” Company wide Everyone and the earlier scope is still on the record WHAT THE RECORD SAYS, PERMANENTLY whoPriya Raman (Head of Finance) when18 Mar 2026, 14:06 changeFinance → Everyone reasongiven in their own words, kept versionv4.2, unchanged by this move reversibleyes, and the reversal is recorded too Not this: someone changes a dropdown from Team to Everyone, and nobody can ever say who, when, or why.
The record is the feature. Access changes are rare, consequential, and exactly the thing an auditor asks about. Treating them as events rather than settings costs nothing and answers everything.

Why this is a commercial argument, not a compliance one

The compliance case makes itself. You cannot sell a knowledge product into finance, healthcare, legal, or any regulated function without being able to describe the boundary precisely, and "we filter the results" is not a description anybody accepts twice.

The commercial case is quieter and matters more. A system like this only works if people let it learn from their work. And people only allow that if they believe the boundary is real.

Tell a compensation team that their process might get captured, distilled, and served to anyone who searches for the right words, and they will opt out on day one. So will legal. So will the deal desk. What you are left with is a knowledge system that learned from the parts of the company where nothing was sensitive, which is to say the parts where nothing much was at stake.

Scope at birth is not the feature that protects the data. It is the feature that makes the capture politically possible in the first place.

The design rule, in one line

Scope follows evidence, not intent. Something learned from a team's work belongs to that team until a named person decides otherwise, in public, on the record.

Also in this series
Versioning and evals

The prompt that broke three teams

An AI instruction is a shared dependency, and most companies still edit theirs like a memo.

Read the post →
The gateway

One door for every tool

Wiring AI to your systems team by team looks fast and ends up unmeasurable.

Read the post →

Make the boundary real before the index exists.

We are opening a small founding design partner cohort, limited by how much hands on onboarding we can give each team.

Get early access All posts