How our AI agents will know what they may share: privacy levels for a second brain

We keep almost everything in one place: a folder of plain text notes we call our second brain. Product plans, build logs, research and to-do lists sit in it. So does ordinary life: where we are staying next month, what a doctor said, what the rent costs. Several AI agents work inside this folder every day. One writes a private morning briefing. One answers questions on Telegram. One drafts a public build log for our blog.

That last one is the problem this post is about. An agent that has just read a note about a rent payment and an agent that writes to the public internet can be the same agent, in the same run. Nothing in a text file tells it that one sentence is fine to repeat and the next is not.

This post explains the system we are designing to fix that: what the privacy levels are, how a note gets one, how every agent learns the rules, how the rules are enforced, and where each decision is recorded. Most of it is a design today. The last section says exactly which parts already run.

Why a single "private" switch isn't enough

The obvious answer is a checkbox: private or public. It breaks quickly. A note about a product we haven't launched yet is fine for our agents to read, should never reach the blog, and becomes public the day we launch. A note about a health appointment is fine for the morning briefing, should never reach the blog, and should never be sent to an outside AI service either. Those are two different kinds of secret, and one switch can't describe either.

Governments solved this problem decades ago, so we borrowed from them. The US classification system answers three separate questions about every document:

• How bad would a leak be? That is the level.
• What kind of secret is it? That is the compartment.
• Where may it go? That is the release control.

Our design keeps those three questions apart.

Question one: the levels

A level is a single word on a ladder. Higher means a leak would hurt more, so fewer people and machines may see it. We use five:

• public: anyone. The blog, X, any AI service.
• shared: our own devices and agents, the outside AI models they use, and our logged-in dashboards. This is the default when nothing else is said.
• private: our agents and the morning briefing, but not hardware we wear in public or show on a livestream.
• confidential: Konrad only. Never sent to an outside AI model, never served by our website, and encrypted when stored.
• secret: Konrad only, and readable only on a machine that holds the decryption key.

If you know the government words, the mapping is rough but useful. The US order that defines classification, Executive Order 13526, uses three levels: Confidential (a leak would cause damage), Secret (serious damage) and Top Secret (exceptionally grave damage). Our private sits near their Confidential, our confidential near their Secret, and our secret near Top Secret. Security teams also use the Traffic Light Protocol (TLP), a set of sharing labels from CLEAR to RED. Our public matches TLP:CLEAR, shared is close to GREEN and private to AMBER.

Question two: compartments

A level says how much to protect something. It doesn't say what the thing is. Compartments do. In intelligence work, a compartment is a named category of secret that only people with a specific need may enter, on top of their level. We use the same idea for the kinds of information a life and a company produce:

• personal-health: health, sleep and body data.
• personal-finance: personal money, tax and rent.
• personal-location: where we live, accommodation and travel plans.
• personal-relationships: people, family and dating.
• guests: details about the guests at a home we rent out.
• money: company revenue, fees and wallets.
• unreleased: product plans before launch.
• credentials: anything that looks like a key or password. It should never be in a note at all.

Each compartment does two jobs. It sets a floor: a personal-finance note can never be below confidential, whatever level someone types. And it carries a rule: personal-location is never public until the trip is over, and never with an exact address. A compartment can only raise the protection, never lower it.

Compartments also let us draw one clean line. Personal life is a separate domain from the company. Health, money, housing, travel and relationships carry a personal- compartment, and the company reports never include them.

Question three: release controls

The last question is where something may travel. We have three controls:

• release-reviewed: a human has read this exact text and cleared it for the public. Every public post needs it.
• no-external-model: never send this to an outside AI service. It is implied by confidential and above, and by the finance and relationship compartments.
• konrad-only: no agent reads it unless Konrad allows it for that session. It is implied by secret.

How a note gets its marking

A marking is a few lines at the top of a note, in the same front matter where notes already keep a title or tags:

• privacy: private sets the level.
• compartments: [personal-location] names the kind of secret.
• declassify_on: 2026-11-07 says when it becomes shareable, for example a launch day.
• classified_by: konrad says who decided.

Nobody will mark thousands of notes by hand, so markings are inherited. A note without a marking takes its folder's default from one small settings file: the health folder defaults to private with personal-health, the finance folder to personal-finance, which lifts it to confidential. A folder without a default falls back to shared.

Some notes mix levels, like a weekly plan that is mostly work with one line about a flight. For those we borrow portion marks, the government practice of marking each paragraph separately. A comment line opens a private block inside an otherwise shared note and another closes it. Anything inside the block is treated at the higher level.

In the design, the same fields also go on our project tracker. Every division, project and feature can carry a level and compartments, and inherits them from the level above when blank. Each row also gets a separate public summary, the only text from the tracker that may ever be published. The internal notes on a row, like "waiting on Konrad to approve the budget", will stay internal by construction, because the public feed will never read them.

The two rules that do the real work

When information from two levels meets, the result takes the higher one. If a report includes nine shared rows and one private row, the whole report is private, unless that row is replaced by its public summary. Security engineers call this the high-water mark: like a bathtub line, the level only rises.

The second rule comes from the Bell-LaPadula model, a security model written for the US Department of Defense in the 1970s. It has two properties. No read up: a reader may not read above its level. No write down: a writer that has read something at a high level may not write at a lower level, because whatever it read could leak into what it writes.

No write down is the rule that matters most for us. An AI agent that has read a private briefing carries that context into everything it writes next. Asking it to "be careful" is a suggestion, not a control. So the agent that writes a public post must never have read anything above public in the first place. We call this the clean room: the public writer gets a feed built only from public material, and the publishing script will refuse any draft whose sources were above public. Our daily build log is the first thing that will move into the clean room.

How every agent learns the rules

We run more than one agent: Claude Code and Hermes, on a laptop and on a server, answering Telegram messages and running scheduled jobs. If each had its own instructions, they would drift apart. So the rules live in one file, AGENTS.md, at the root of the vault.

Hermes reads AGENTS.md directly. Claude Code reads its own CLAUDE.md, so ours is a few lines ending in @AGENTS.md, which Claude Code treats as an import. Whatever harness runs the agent, it loads the same rulebook. When the privacy design is built, its rules go into that file: what each level means, that markings are inherited, that personal compartments never appear in company reports, and that only the clean room writes public text.

Written rules are still only suggestions. An agent mostly follows them and, on a bad day, doesn't. So each rule that matters also gets a machine check.

Who enforces it

In the design, enforcement sits in four places, each a small program rather than an instruction:

• The guard. Both agents run the same guard script before every file read and shell command. It is a hook: a small program that runs before the agent's action and can stop it. Today it blocks agents from reading files that hold keys, and from force-pushing over shared history. The design extends it to block reads of confidential and secret notes unless Konrad allows them.
• The search index. Our notes are split into chunks and turned into embeddings (lists of numbers that let a search find notes by meaning). Making them can mean sending text to an outside service. The design sends only public and shared text out, handles private text on our own machine or skips it, and never indexes anything higher.
• The surfaces. Each place that shows information gets a ceiling. The logged-in dashboard shows up to confidential with a visible marking chip on each row. The morning briefing and Telegram stop at private. The small screen on our wearable stops at shared, because it is worn in public and on livestreams. The public feed shows only public.
• Encryption at rest. confidential and secret notes will be encrypted in the repository with git-crypt, so a leaked copy of the repository shows only scrambled text.

Where every decision is recorded

A marking you can't audit is a marking you can't trust. So the design adds two logs that only ever grow. Nothing in them is edited or deleted:

• Classification changes: every time a marking changes, what it was, what it became, who changed it, when, and why. This is our version of the "Classified by" and "Declassify on" lines printed on a government document.
• Disclosures: every time something goes public, the channel, the address, who approved it, and a fingerprint of each source it was built from.

Once a week an agent will compare the disclosures with today's markings. If something published last week has since been marked private, it gets flagged for a human to look at.

What's built and what's next

Built and running today:

• One rulebook, AGENTS.md, loaded by every agent we run.
• The guard script that runs before every shell command and file read or edit, blocking reads of key files and force pushes.
• A human approval before anything is published: every post an agent drafts stays a draft until Konrad says yes.

Designed, not built yet, in this order:

• Markings on the project tracker, with a "view as public" preview on the dashboard and the wearable's screen capped at shared.
• The clean room for the daily build log, with the disclosure log.
• Markings and folder defaults for every note, then the guard, search index and encryption rules above.

If you are building your own second brain with agents, the shortest useful version is this: give every note a level and a kind, let folders supply the default, put the rules in one AGENTS.md that every agent loads, and never let the agent that writes in public read anything private first.

We are building this in the open. Follow along at https://x.com/myargoquest.