Last time, I cracked open the filing cabinet. This time, I had to tackle the decidedly unglamorous part: deciding who gets a key to which drawer, and making sure that answer survives contact with an eager AI agent.
A shared company memory cannot be one big, warm soup of context. In the real world, memory is strictly compartmentalised: client A, client B, payroll, draft contracts, and that special category of files I call “things Teo should absolutely never paste into Claude while half-awake.”
Part 2 of Enterprise Shared Context (ESC) is about building the walls. On our SHIELD playground, this means Tony Stark and Alexander Pierce can query the exact same catalog and see two completely different organisations.
Unix solved this thirty years ago, and we forgot
I didn’t invent a novel theory of security. I just stole the classic small-Unix instinct and carried it over to the modern filing cabinet.
The basic file permissions we all intuitively understand – owner, group, other – are fine for a personal laptop. They fall apart within twenty minutes at a marketing agency. The second you need a rule like, “Avengers can read this brief, Sokovia Accords oversight can read it too, Hydra gets exactly two specific files, and the intern can’t see the parent directory,” you have to welcome Access Control Lists (ACLs).
For a Context Owner, the philosophy behind ACLs boils down to two entirely separate questions:
- Access: “Who is allowed to touch this exact file or folder right now?”
- Inheritance: “What permissions will newly created files automatically inherit when someone drops them in here?”
One locks the doors in the room today. The other acts as a birth certificate for files that don’t even exist yet.
ESC mirrors this split on purpose. When a Context Owner grants access to a folder, it applies right now and simultaneously sets the template for the next file scan. If you need Hydra kicked out of a shared Avengers folder, you don’t create a complex, theatrical “deny” rule that inevitably breaks later. You simply revoke their grant on the folder, and explicitly hand them access to the two miserable PDFs they actually own.
The same catalog, two different buildings
Here is Tony Stark versus Alexander Pierce running against the exact same SHIELD playground. Org charts and public scraps overlap. Everything else cleanly diverges.
Tony sees 68 readable paths. Pierce sees 31. They share 26 baseline files (the public charter, the generic org chart, polite corporate paperwork).
The rest is a pure Chinese wall: Tony gets the technical primers and tactical mission logs; Pierce gets the Hydra watchlist and a couple of archived internal memos. Same underlying system. Two entirely different operational realities.
Policy choices that prevent madness
If you want to keep the Context Owner’s job manageable, you have to lock in a few ground rules early. Debating these twice is a fast track to architectural chaos:
- Teams over individuals. Teams come first; individual user overrides are a rare exception path.
- Permissive team matching. If you belong to any team granted on a file, you’re in.
- Nearest ancestor wins. If inherited folder defaults ever clash, the closest parent directory takes precedence.
- The Context Owner exception. The Context Owner holds the master key and sees the whole tree. Everyone else gets a specifically tailored slice.
The primary product challenge isn’t the underlying database. It’s whether the Context Owner can confidently answer a panic question like, “What exactly can Pierce see if he logs in right now?” in under twenty seconds.
The part that still leaks in paragraphs
Paths are easy to wall off. Prose is not.
Filtering a list of files is elementary. A compiled LLM wiki, however, is treacherous. An AI summarizing twenty files will happily weave insights from Client A and Client B into the exact same sentence, genuinely believing it is being helpful. You can have mathematically airtight file permissions, and the wiki will still casually commit an NDA violation in paragraph two.
This is why ESC abandoned the fantasy of “one giant company wiki with dynamic redaction.” Redacting prose on the fly is just prompt-engineering roulette.
The safer solution is isolated sandboxes:
- Master Vault: The overarching wiki (for Context Owners only) compiles everything.
- Downstream Vaults: Users and teams with wiki privileges get isolated, personal maps.
- Strict Compilation: These downstream wikis are compiled only from the files that specific team’s filtered catalog can see. The AI compiler never even glimpses the forbidden files.
In short: a compiled map is considered guilty until proven innocent. The only reliable way to prevent paragraph leaks is to never put two competing secrets in the same context window.
What I still refuse to fake
I deliberately haven’t built in-app file uploads, moves, or deletes yet.
Those are the danger zones. Moving a file means recalculating inheritance, purging derived text extracts, invalidating cached wiki vaults, and ensuring nobody accidentally drags an unredacted payroll sheet into a shared client folder.
It’s tempting to slap a quick upload button into the UI for the demo. But I’d rather defer that functionality than ship an accidental HR incident disguised as a friendly web feature.
Next up, we cross over from static walls to active agents: system rules, integrations, and the delicate art of handing a machine just enough context to do its job without giving it free rein to wander the corridors.
Now that the building actually has doors.