The first confidentiality guardrail I built for my AI agents had a blacklist at its center: a list of company names, client names, and sensitive terms that must never appear in a commit to a public repository. It seemed obviously correct. It was wrong in both directions at once, and the way it was wrong taught me more about disclosure in the agent era than the fix itself.
Here is the first direction. My public websites name my employers, past and present. They name clients I have advised and collaborators I have worked with. That is not carelessness; it is my resume. I wrote those pages, published them deliberately, and benefit from their existence. A blacklist that treats names as secrets flags my own biography as a leak. The first time a guard blocks you for restating your own published resume, you stop trusting the guard.
Which produces the second direction, the one that actually matters. When I audited how my guardrails classified my repositories, the repositories that publish my websites (the most public surfaces I own) had the sensitive-pattern scanning switched off entirely. Not because anyone decided the published surfaces needed no protection. Because the name-blacklist made protection unusable there: every author bio would have fired it. The over-block had quietly caused the under-protection.
A guardrail that flags your own resume as a leak will end up switched off exactly where you publish.
That failure forced a redesign from the ground up, and its conclusion is the subject of this piece: for AI agents embedded in your working life, the name was never the secret. The secret is the approval.
What an embedded agent actually knows
An AI agent doing real work for you reads your email, your chat, your meeting transcripts, your private repositories, your client work. Within weeks it knows more about your professional life than you have ever published. This is precisely what makes it useful, and it creates a problem that existing safety work mostly does not model. The sensitive-data tooling of the pre-agent era treats leakage as strings to find and redact. Almost none of it governs an agent that drafts public prose on your behalf, in your voice, from knowledge of you that no pattern list describes.
I’ve written before about how an assistant’s accumulated memory isn’t really yours in the durability sense. This is the sharper problem inside the same fact: the accumulated knowledge is yours in the worst way. Everything the agent learned in private rooms is something it can casually say in public, truthfully, and no blacklist entry will ever match it, because the leak arrives described, not named.
Ask what a blacklist does about that. If the agent writes “a client in a regulated industry whose engagement was never announced,” no string matched, and the disclosure walks through. If it writes a flattering, accurate sentence naming an employer I list on my own biography page, the blacklist blocks a fact I published myself. The blacklist models which strings are dangerous. The actual boundary is which disclosures I approved.
Two categories, one axis
Every fact an agent might state about your professional world falls into one of two categories.
Category one: what you deliberately published. Your bios, your site, your articles, your talks. For me that includes employers, advisory relationships, and collaborators, named because naming them serves my career. An agent restating these facts, in the same register I published them in, is doing exactly what I want. A guardrail must let this flow.
Category two: everything else. Every name, detail, and identifying description you have not personally published or approved, and above all, anything the agent learned from private context. It does not matter that the fact is true, or flattering, or adjacent to public facts. Unapproved is unapproved, and this category is where careers get damaged: the casual mention of an engagement, the internal decision described as a war story, the detail that lets an insider confirm what they suspected.
The axis separating the categories is approval and provenance: did I publish this, and where did the agent learn it? Notice what the axis is not. It is not the name. The same company can appear in both categories at once. An employer named on my resume is category one when the agent restates the relationship, and category two the moment the agent describes something that happened inside, even something positive. The precedent covers the fact I published, not the entity.
Making approval mechanical: the precedent ledger
“Did I approve this?” sounds like a judgment call, which sounds like something you cannot enforce mechanically. Most of it, it turns out, you can.
The core is a precedent ledger: a version-controlled file listing each entity I have publicly disclosed a relationship with, what kind of fact I published, and (this is the load-bearing rule) evidence. Every entry cites where I published the fact: this bio page, that article. No citation, no entry. An agent’s belief that something is public is not evidence that it is public; agents inherit that belief from private context all the time. The evidence rule is what keeps the ledger honest, because it makes every allowance auditable back to a page I authored.
Approvals accumulate. When I approve a new disclosure, it enters the ledger with a date and a citation, and approval becomes precedent.
Scope matters as much as membership. A ledger entry covers a register of facts (biography: relationship, role, era, public work), not the entity. There is no entry that makes operational detail about anyone publishable. And precedent permits a mention; it does not compel one. For active relationships, the mechanical guard stays on regardless of precedent, so each new mention gets a deliberate decision rather than a default.
Classify by surface, not by repository
The second structural change: enforcement severity follows the publication surface, not the repository’s visibility. Repo visibility turns out to be a proxy that fails in both directions. The private repositories that build my websites publish every merge to the open internet: private repo, fully public surface. Meanwhile my open-source projects live in public repositories that are not my biography and should never carry a client’s name even in a code comment.
So the guard classifies three ways. Personal notes that no one else reads: credential scanning only. Published surfaces I author: full scanning, minus exactly the ledgered names in their published registers, because my resume can restate my resume. Everything public-facing that is not my authored surface, plus anything touching client work: strictest class, where even ledgered names block, and the classifier resolves ambiguity by escalating to strict rather than relaxing.
The pattern generalizes past git. Ask of any channel your agents can write to (a publishing pipeline, a social scheduler, an email draft folder): what surface does this ultimately reach, and which precedents apply there? If you are classifying by where the file sits rather than where the content lands, you have the same hole I had.
The judgment layer: five tests
The mechanical layer catches strings. Disclosure risk is mostly not strings. It is descriptions, combinations, implications. So above the hook sits a decision procedure the agents apply to anything outward facing. Five tests, in order:
- Precedent. Is this exact kind of fact about this entity already on a surface I author? Cite the ledger entry. No entry, no pass.
- Provenance. Where did you learn this? If the answer is private context (messages, transcripts, private repos, meetings), it is protected until an independent public counterpart is cited.
- Negativity. Would the named party read this as anything other than positive or neutral? Any doubt fails.
- Identification. Could an outsider, an insider, or a motivated adversary narrow an unnamed reference to the real party? “A major metropolitan newspaper where I ran engineering” is governed exactly like the name, because it resolves to the name. It survives the tests only because that relationship is already all over my published biography.
- Aggregation. Do individually public facts combine into a disclosure none of them makes alone? A public role, a public timeline, and a new anecdote can triangulate a confidential situation precisely. Judge the combination.
When any test is uncertain, the answer is ask, never assume. And the asking is cheap, which matters: each approval appends to the ledger, so by default the system asks each question once. The exception is chosen, not accidental: entries can be marked ask-every-time, which is how active relationships stay deliberate.
This article went through the same five tests before you read it. It names no employers and no clients. Its one identifying description, the newspaper sentence above, passes because that fact carries ledger precedent with a citation to my published bio. The relationships it keeps generic stay generic for two different reasons that the model distinguishes cleanly: most fail the precedent test, and at least one has precedent but is withheld anyway, because precedent permits and never compels.
The part I did not expect: enforcement is a velocity feature
I built this expecting to pay a speed tax for safety. The opposite happened, and I now think the inversion is the real lesson.
Before, every outward-facing draft carried a quiet question: is there anything in here the agent should not have said? That question was slow precisely because it was unstructured. It re-litigated my entire disclosure posture per draft. Now the dangerous class of error is structurally blocked (fail-closed hooks on every commit path, the ledger deciding in milliseconds what has precedent), and the residual judgment is five ordered tests instead of one diffuse worry. The constraint that kept agent-drafted public writing scarce is gone: the per-draft review cost collapsed, and what remains is the writing.
The boundary being mechanical is what lets a draft get written without stopping at every proper noun. Enforcement is not the tax on velocity.
The mechanism behind all of this is open source: the policy model, the ledger schema, the hook engine. Publishing it costs nothing, because the secret was never in the mechanism. It lives in one private data file: my ledger, my precedents, my approvals. Yours would be yours. And the engine fails closed on a missing or unverifiable ledger, so anyone who adopts the mechanism inherits the protection, not just the code.
Name blacklists feel like protection because they block things. But a guard that cannot tell your resume from a leak will be switched off where you publish, and a guard that only knows spellings will wave through every leak that arrives described rather than named. Govern the approval, trace the provenance, and let your name appear exactly where you already put it.