06-reference/research

spcs brigade external access anthropic reachability

2026-09-26·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
spcsexternal-access-integrationsnowflakephdataorganizational-intelligence

Yes, raw brigade-in-SPCS needs an external access integration and a third account-level grant (CREATE INTEGRATION) — but only if the brigade calls api.anthropic.com itself, and BIND SERVICE ENDPOINT stopped being an ask in May

The question

"SPCS brigade enablement — pin the exact minimal grants: the preview-feature identifier string for SYSTEM$ENABLE_PREVIEW_ACCESS (App Runtime only, not all previews), and whether raw brigade-in-SPCS needs external access integrations for Anthropic API reachability beyond CREATE COMPUTE POOL / BIND SERVICE ENDPOINT."

The first half is a dead premise and was retired before this brief started. App Runtime went GA on 2026-09-01, so SYSTEM$ENABLE_PREVIEW_ACCESS is no longer in the path and there is no per-feature identifier string to pin. See [[2026-09-25-spcs-app-runtime-client-account-enablement-gate]]. Everything below researches only the surviving half, plus the two questions that brief left open: whether the P3 C1 gate moves now that the runtime is GA, and whether BIND SERVICE ENDPOINT really defaults to PUBLIC.

What we already know (from the vault)

What the web says

All Snowflake pages below read 2026-09-26. Evidence grade is stated per bullet: verified = primary docs.snowflake.com page fetched directly; primary-via-summary = primary page surfaced through a search summarizer rather than fetched, so the substance is Snowflake's but the exact wording is not quoted.

Convergences and contradictions

Synthesis for RDCO

Direct answer: yes, and the "beyond" is one extra account-level grant plus a runtime reference. If the brigade process inside the container calls api.anthropic.com itself, CREATE COMPUTE POOL and BIND SERVICE ENDPOINT are not sufficient, because those two govern compute provisioning and inbound endpoint exposure. Outbound is a separate, deny-by-default control plane. The minimal delta is: CREATE INTEGRATION ON ACCOUNT for the role that will create the external access integration (ACCOUNTADMIN not required for the public-internet case, which is a better ask than the parent brief implied), a NETWORK RULE with MODE = EGRESS / TYPE = HOST_PORT / VALUE_LIST = ('api.anthropic.com'), an optional SECRET for the API key, an EXTERNAL ACCESS INTEGRATION binding the two, USAGE on that integration for the deploy role (plus READ on the secret and USAGE on its schema if a secret is used), and EXTERNAL_ACCESS_INTEGRATIONS = (<eai>) named in CREATE SERVICE. The schema-level creation privileges for the network rule and secret are the one part of the list I could not pin from primary docs and should not be recited to a client admin as settled.

The more useful answer is that the whole ask collapses if we pick the runtime deliberately. The brigade only needs an Anthropic-host EAI if the brigade is the thing making the model call. Run it on the GA CoCo CLI inside the container and inference goes through Cortex, so there is no api.anthropic.com in the network rule and no vendor-host allowlist conversation at all - the admin ask becomes CORTEX_ENABLED_CROSS_REGION plus a Cortex database role that arrives through PUBLIC by default. That reframes C1 from "will your security team allowlist an AI vendor's API" (a question that invites a no) to "are you comfortable with cross-region inference routing" (a residency question with a documented answer). Residual egress needs do not vanish - git remotes, non-Snowflake MCP servers, package installs - but those are boring hosts, not an LLM vendor, and a reviewer treats them differently. So C1 is not resolved by App Runtime GA; it is resolved by a runtime decision, and the decision is already available.

Two things get struck from the enablement ask, and that matters more than it sounds. BIND SERVICE ENDPOINT should come off the request list and move onto a verify list: since BCR-2321's 2026-05-18 rollout it is granted to PUBLIC by default, so asking for it signals we have not read the current docs, and asking an ACCOUNTADMIN for privileges they already hold is exactly the friction that makes the next ask harder. The preview toggle is likewise gone. What is left of the original "minimal blast radius" ask for the brigade leg is genuinely small: one un-delegable grant (CREATE COMPUTE POOL, ACCOUNTADMIN-only by design, for cost control), one conditional grant (CREATE INTEGRATION, only if we need non-Cortex egress), one account parameter (CORTEX_ENABLED_CROSS_REGION, only if models are not in-region), and an image repository. That is a one-screen request, and every line has a primary doc behind it.

Practical consequence for the matrix and for any SOW. The P3 row should stop carrying C1 as a single blocker and split it into two independently-checkable cells: model path (Cortex-routed = no Anthropic EAI; direct-API = EAI required, CREATE INTEGRATION needed) and non-model egress (git, MCP, packages - EAI required either way, hosts enumerable up front). Written that way, C1 stops reading as "some clients will say no" and starts reading as a two-question discovery item, which is what it actually is. The one honest caveat: none of this has been run on an account we do not control, and the schema-level grant list plus the per-account BIND SERVICE ENDPOINT state are both facts to check rather than assume.

Why this is in the vault

It closes the last open follow-up of [[2026-07-12-spcs-app-runtime-enablement-partner-managed]] and the C1 follow-up of [[2026-09-25-spcs-app-runtime-client-account-enablement-gate]], and it changes the P3 row of [[2026-07-07-hex-deployment-matrix-v2]] in two concrete ways: BIND SERVICE ENDPOINT moves from the ACCOUNTADMIN ask list to a per-account verify list (BCR-2321), and C1 splits into a model-path cell and a non-model-egress cell, which is the difference between P3 reading as blocked and P3 reading as a two-question discovery item in a client conversation.

Open follow-ups

Related

Sources