Field Notes from Deep Water Bay: Guarding Deep-Water Assets
Sham Shui Po is a Hong Kong district most people know for its electronics street market. Stall after stall of secondhand components; buyers squint at stock; nobody asks where anything came from and nobody asks where it's going. Ask a vendor if the goods are genuine and he'll look up once, push the crate toward you, and say: "If you want the real stuff, go to a gold shop."
I grew up around those streets. When I later ran data, I found that the world of data compliance has its own version of the market — we call it the deep-water zone. It holds a special class of assets whose names alone are worth protecting. Saying the name is opening the door. Guarding those names is harder than guarding a vault, because a vault has a lock; a deep-water asset's name is the lock.
The market rules, translated
The vendors who survive Sham Shui Po follow three rules:
- Never discuss provenance on the stall floor.
- The genuine goods never sit on the counter — only trusted regulars get shown them.
- Disputes are settled off the street, quietly, keeping some face.
Translated to assets: proprietary names stay confidential; core assets stay physically isolated from circulating code; violations are handled through internal process, not broadcast. Deep-water survival is, at bottom, information-entropy management. How much information you can hold back is how much value you keep.
1. Register first: classify the assets
Guarding deep-water assets doesn't start with scanning. It starts with a registry — moving the judgment "what counts as deep water" from human heads into a machine-readable table.
Each entry carries three things: name, classification, and keyword/path fingerprints. Classification is tiered, with the top tier marked top secret and the next confidential.
What sits in the top tier? Federated verification engines, cross-agent trust propagation, cost-game schedulers, supply-chain security scanners, multimodal attack detection, edge split-brain self-healing. Plus two especially sensitive classes:
- Raw red-team attack samples — the attack data used to train defenses. Leaking them hands outsiders the blueprints of your own target range.
- Model weights — the entire distilled product of training runs.
The keyword/path fingerprints feed the scanner: each asset registers dedicated keywords (for attack samples: attack-1m, path .openclaw/attack) that the scanner matches against target directories. Classification drives handling severity: a top-secret asset crossing the boundary triggers the highest-level alert and escalation.
Why the name itself is the leak
The registry pattern works because it encodes a blunt truth: for deep-water assets, disclosure is a spectrum, and naming is already on it. Listing "federated TLA+ verification engine" in a public changelog doesn't reveal the code, but it announces that such an engine exists — which is often enough for a competitor to start looking, or for an adversary to infer the security posture behind it. The registry respects that by treating its own contents as sensitive. The asset names live in the table, the table lives in a private side, and no sync path carries it into anything public.
2. Scan and notify: the sentry must shoot
The registry feeds a scanner that walks target directories, skipping the usual noise (.git, dependency trees, caches, build output) and scanning text-bearing files — code, docs, configs, scripts, templates.
The logic is simple: match file contents against registry keywords and paths; on a hit, record a violation entry with asset, classification, matched snippet, and file type. The exit code says it plainly: 0 means clean, 1 means violations found.
But a sentry that can't shoot is just furniture. On detection, the scanner writes a notification file into an alerts directory; an alert bot picks it up and wakes the owner through the highest-priority channel under the "security violation" tag. This is interception, not post-mortem — waking a human before the file flows into the next pipeline stage.
The scanning surface: what gets checked and what doesn't
A deep-water scanner has to be surgical about its scan surface, because scanning everything makes the signal unwatchable. It walks text-bearing file types — source, markdown, config, YAML/JSON, scripts, templates — and deliberately skips the noise directories that dominate most repositories: version-control internals, node modules, virtualenvs, cache trees, build and dist output. Deep-water assets are almost never generated — they're authored as code and prose — so the scanning surface is small enough to run on every commit without turning CI into a bottleneck.
Matching: keywords and paths, two nets
The registry carries two kinds of fingerprints, and the scanner uses both. Keyword fingerprints catch the asset being discussed — a markdown file that quotes "attack-1m" triggers even if the actual samples aren't present. Path fingerprints catch the asset being present — a reference to a registered sensitive directory (like the .openclaw/attack path) is flagged regardless of whether its contents match any keyword. Running both nets matters because the two failure modes are different: a file can mention the name without containing the thing, and a file can contain the thing without mentioning the name. Either way, a record is written with classification and matched fragment, so a human can triage without re-reading the entire tree.
3. Single-side isolation: the key doesn't hang on the door
This is the least intuitive and most critical rule: the registry itself must stay on the closed side and never sync out with the source repository.
Why? Because the registry is full of asset names. And in the deep-water zone, the name is the key — saying "federated verification engine" is equivalent to telling someone "there's something behind this door, it's valuable, come get it." If the registry lands in a public repo, even with zero code leaked, the asset list alone is already a second-order leak.
This is the street vendor's instinct made engineering: the real goods never reach the counter. Isolation is nested — assets live in the deep water; the inventory of those assets lives in deeper water.
Isolation as a build constraint, not a policy
The isolation can't be a README warning; it has to be structural. The scanner, its registry, and the notification channel live in a private side of the workspace that has no sync path to public-facing outputs. Any attempt to write the registry into a public tree fails at the tooling layer, not at the "please don't" layer. That structural choice is what makes the guard durable — it survives personnel changes, rushed merges, and the general entropy that eventually defeats every convention that depends on people remembering to follow it.
4. Federated Merkle roots: trust without promises
Deep-water assets can't leave the perimeter, but compliance audits are often cross-organization. When multiple parties collaborate, how do you prove "my log was never tampered with" without handing over the log?
The answer is federated Merkle-root aggregation: each organization compresses its internal audit log into a Merkle tree and submits only the root hash — a fixed-length digest — to a federated tree. Any third party holding the federated root can verify offline that an organization submitted a specific record and that the record hasn't changed. No raw logs ever change hands.
That's Sham Shui Po rule three, engineered: disputes settle quietly, keeping some face. Cross-organization trust runs on cryptographic evidence, not handshakes. "You say you didn't change it — don't show me the ledger, show me the root hash."
Audit without disclosure
The federated design matters precisely because the assets underneath the audit are deep-water.
The operational workflow is worth spelling out because it's where most federated designs quietly die. Each organization runs its own scanner and its own ledger — the deep-water names never cross the boundary. What crosses is a single digest per reporting period. If a partner later disputes a delivered dataset, the receiving side asks for a Merkle proof over the relevant entries, verifies it against the published root offline, and the argument is over before it becomes an argument. Nobody subpoenas anyone's repository; the cryptographic evidence is the resolution. In practice this collapses what used to be weeks of cross-company audits into a scheduled exchange of hashes. A conventional audit wants to read your logs; a federated audit wants only your root hash. Each organization folds its entire internal log into a tree, publishes the root to the federation, and retains the ability to produce a Merkle proof for any entry on demand. A third party that has never seen a single raw record can still confirm "organization X attested to these entries, and this entry is among them." For a compliance regime that spans multiple organizations holding proprietary assets, this is the difference between an audit that works and an audit that leaks the very things it was meant to protect.
5. Write the rules into code
One closing note from the notebook.
The old vendors taught me that rules aren't written on the wall; they're worn into the hands. A beautiful compliance notebook beats nothing, but only rules that have become systems — a scanner running daily, alert channels always open, isolation nested layer over layer — survive contact with reality. The value of a rule isn't how well it's written. It's whether it executes without anyone having to remember it.
Written by Lina Chen — security engineer turned data broker, now guarding deep-water assets on the gray line between data compliance and the underground data economy.
Top comments (0)