Sources, security, and evidence

Four source access modes#

Live database capture#

When you lock the source list, SOCK performs read-only introspection and writes an evidence package before any analysis begins. From the scan onward only that package is read; the live database is never queried again.

• Depending on engine and permissions, capture can include schemas, tables, keys, views, indexes, routines, sequences, triggers, row counts, grants, and bounded samples.
• One PostgreSQL connection captures one configured database, not every database in the server cluster.
• Sample rows are captured as they are and may contain sensitive business data.
• Row sampling can be constrained or disabled; agree masking and retention requirements before capture.

Transport security#

Read-only and credential handling#

• The capture path is designed not to mutate repositories or databases.
• After authorisation, a revealed credential is held in the signed-in user's local operating-system credential store.
• At extraction time, credentials are passed to the child process through standard input — never command arguments, environment variables, logs, or locked artefacts.
• Generated packages are scanned for handled credential values of at least six characters.
• A match quarantines and fails the source rather than accepting the package.
• A failed source produces a blocker or a named gap, never a silently empty success.

What is scanned before you publish#

Publishing a release runs a secret scan across the source material the archive carries, and reports what it found to the person authorising the publish. The scan records; it does not silently block.

The scan does not cover the generated knowledge tree, whose false-positive profile over narrative text quoting source code is a separate problem. The honest claim is that no raw source bytes ship uncovered — not that nothing unscanned ships at all.

Where processing happens#

MSOCK and harness artefacts run locally on your machine, and deterministic processing runs locally too. AI comprehension, mining, and Ask use the installed, authenticated Claude Code runtime, so content handled by those stages travels to the configured model service.

Do not infer data residency from the desktop installation alone. Confirm the actual model-service configuration, network path, regional controls, and organisational agreement for each deployment.

The SOCK Assistant#

SOCK includes an in-product assistant that can explain progress and artefacts and help raise a problem. It reaches the engine through a closed, allow-listed action channel rather than a shell, and it is bound to the harness you are looking at.

By design it cannot modify a harness, cannot read outside its allowed scope, and cannot explain how SOCK itself is built. If the enforcement surface is missing from an installation, no assistant is offered at all rather than an unfenced one.

Reading someone else's published harness#

A downloaded harness is read-only through every supported MSOCK path: desktop writers, engine commands, and session file-editing tools all refuse changes. Reading a teammate's published knowledge through MSOCK therefore cannot alter that published copy.

Deployment review checklist#

• Approved source locations and data classifications
• Whether source content may be processed by the configured AI model service
• Network, VPN, proxy, TLS, and database allow-list requirements
• Least-privilege repository and database accounts
• Sample-data restrictions or masking requirements
• Operating-system support for the release
• Retention and deletion requirements for local harness artefacts
• Who holds the SOCK Creator and SOCK Knowledge Custodian roles, who can build and release knowledge, and what the deployment requires for team publishing