06-reference/research

brigade snowflake connection profile governed rollout

2026-09-14·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
snowflake-cocoagent-brigadesecrets-hygienegoverned-rolloutphdata

Does a Snowflake connection profile make the Brigade both client-governed and secret-free? Partly. It is a good distribution channel but not a governance control, and the credential risk sits in the profile, not the manifest.

The question

"Does shipping the Brigade via a Snowflake connection profile satisfy client-governed rollout AND the no-secrets-on-disk rule (MCP creds via OAuth / env expansion, never in the manifest)?" This is the fifth open follow-up from [[2026-07-05-brigade-skills-snowflake-cortex-code]], which pitched connection-profile distribution as the governed path for deployment profile P3. [[2026-09-13-cortex-code-client-deployable-surface-p3-p4]] later settled the runtime question. This brief is a delta: it covers only governance and credentials.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Verdict: connection-profile shipping satisfies the no-secrets-in-manifest half outright, and satisfies client-governed rollout only as distribution, not enforcement. Whether the whole deployment meets "no secrets on disk" depends on the profile's authenticator, which the manifest does not control. Snowflake's plugin guidance ("keep MCP credentials out of the manifest") matches RDCO's rule word for word. CoCo's MCP layer moves CLI-supplied secrets into the OS keychain and writes nothing when no keychain exists. The Brigade's manifests carry no MCP servers and no credentials today. So the manifest is not where the risk is.

The risk sits one layer down, in connections.toml. A profile that uses password = or an unencrypted private_key_file puts a long-lived secret on disk, and shipping plugins through it does not change that. For a client deployment, RDCO's 1Password-wrapper rule becomes three client-side patterns. (1) For human seats, use authenticator = "externalbrowser" against the client's identity provider (IdP), so the only thing stored is a cached token in the OS keychain. (2) For the service loop in SPCS, use the platform-issued rotating token at /snowflake/session/token, which cannot leave SPCS and is not a stored secret. (3) For any non-Snowflake MCP credential, supply it through ${VAR} expansion from an environment the client's platform injects. The usual way to do that is a Snowflake SECRET object exposed as an environment variable in the SPCS service spec. That pattern is well known but was not re-verified at a primary source in this brief. Two traps to avoid: never use Claude Code userConfig sensitive values in a Linux container, because they fall back to a plaintext ~/.claude/.credentials.json; and never put a confidential OAuth client_secret in a manifest, because CoCo now accepts one. Pass it through ${VAR} instead.

For the governance claim, change the pitch. Do not tell a client's Snowflake admins that the profile "governs" the Brigade. What they actually control is (a) which roles can use the profile's connection, and through it Cortex inference, set with Snowflake grants; (b) whether any plugin or user MCP servers run at all, set with areUserMcpServersAllowed; and (c) who can read the profile. A more accurate phrase for statement-of-work (SOW) language is "admin-distributed baseline, governed by Snowflake RBAC." Add the Sept 13 caveat as well: plugin distribution is Preview, so the GA-safe package is loose skills, subagents and hooks, and a profile-shipped plugin should only go to clients that accept Preview features.

What this implies for the Brigade. The Brigade has no credentials in its manifests today because it has no MCP servers yet. The first one arrives with the shared remote MCP server that the restructure brief puts behind every port crossing. That is when the rule becomes testable. The cheap safeguard is to make Gate-A's deterministic lint fail on any literal credential-shaped value in plugin.json or .mcp.json, and on any userConfig field marked sensitive in a plugin built for container deployment. Then the rule is enforced in code rather than remembered.

Why this is in the vault

It closes the governance-and-credentials cell for P3 in the Organizational Intelligence (OI) deployment matrix ([[2026-07-07-hex-deployment-matrix-v2]]). It also corrects the parent brief's "governed distribution" wording before it reaches a client admin or a Snowflake account executive (AE). And it gives the Brigade's Gate-A lint a concrete no-secrets rule to encode before the remote MCP server lands.

Open follow-ups

Related

Sources