06-reference/research

si object curation managed vs client agent visibility

2026-09-24·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
snowflake-coworkcortex-agentsrbacmanaged-servicesdelivery-design

The CoWork curation object cannot partition a managed engagement. Agent OWNERSHIP can.

The question

In a shared-services / managed engagement, can the Snowflake Intelligence Object curation model express phData-managed vs client-managed agent visibility (who controls which agents appear in the client's CoWork)?

Open follow-up #5 from [[2026-07-08-cortex-agent-cowork-skill-native-publish]], auto-promoted 2026-07-22. It is a mechanism question: is there a grant, ownership, or metadata primitive that distinguishes a partner-managed agent from a client-managed one inside the client's own CoWork agent list?

What we already know (from the vault)

What the web says

Primary sources, fetched 2026-09-24 from docs.snowflake.com. All quotes are from those pages.

Convergences and contradictions

Synthesis for RDCO

The answer is no at the layer the question names, and yes one layer down. The Snowflake Intelligence Object cannot express phData-managed vs client-managed visibility. It is a single account-level container with one undifferentiated MODIFY privilege governing the entire list. Whoever holds MODIFY can add or remove any agent, including the other party's. There is no scoping of MODIFY to a subset of agents, no per-role or per-group view of the curated list documented anywhere, and no provenance attribute on an agent object beyond free-text comment and display name. If a managed-services design depends on "phData curates its shelf, the client curates theirs," that design does not exist in the product as of 2026-09-24.

What does exist, and is documented, unlabeled-preview (i.e. treat as GA but verify), is the ordinary agent-object RBAC split: OWNERSHIP + MODIFY held by a phData-controlled role, USAGE (and optionally MONITOR) granted to client roles. That expresses the substantive half of the distinction — the client can run a phData-managed agent and read its traces but cannot alter it, and the reverse holds for client-built agents phData is not on the hook for. Pair it with separate databases or schemas per owner and a managed-access schema so grant issuance centralizes on the schema owner rather than leaking to individual agent owners. Caller's-rights execution means the phData agent still runs inside the client's data-access envelope, which is the right answer in a security review and should be led with rather than discovered.

The residual risk is entirely concentrated in MODIFY on the single CoWork object, and that is the thing to write into the SOW. Because it is all-or-nothing, one of three shapes has to be chosen explicitly and named in the engagement: (a) client retains MODIFY, phData requests list changes through a change ticket — slowest, cleanest accountability; (b) phData holds MODIFY during the managed term with a contractual no-touch on client-owned agents — fastest, and the guardrail is contractual, not technical, which must be stated plainly rather than implied; (c) a joint operations role both parties assume, with ALTER SNOWFLAKE INTELLIGENCE statements pushed through version control so the audit trail lives in Git rather than in Snowflake grants. Option (c) is the one that survives a client security review and the one worth defaulting to, but it requires phData to own the deployment pipeline, not just the agents.

For a harder boundary — a client who wants technical, not contractual, assurance that phData's agents are untouchable and phData cannot touch theirs — the mechanism is the Native App packaging path, not curation. That moves the boundary from a grant to an application container: the client installs, the agent surfaces in their CoWork, the contents are opaque. The costs are real and should be priced: the Marketplace listing and security-review gate, the loss of ad-hoc iteration during delivery, and the documented restriction that the direct-share variant cannot carry procedures, skills or MCP connectors. That trade — governance rigidity bought with delivery agility — is a genuine architecture decision to put in front of a client rather than a detail to resolve in build.

Finally, one guard. The "Required / cannot be uninstalled" per-group enforcement that makes this problem look solved is a Claude Cowork feature. Snowflake CoWork has no equivalent. Anyone who has seen both surfaces in the same week is one sentence away from promising a client a lock that does not exist.

Why this is in the vault

It settles the RBAC and ownership section of any phData shared-services / managed-CoWork statement of work: specifically, who holds MODIFY on the client's single SNOWFLAKE INTELLIGENCE object for the managed term, and whether the phData-vs-client agent boundary is sold as a technical control (Native App packaging) or a contractual one (agent OWNERSHIP split plus a no-touch clause). It also pre-empts the Claude-Cowork-enforcement mix-up in a client security review.

Open follow-ups

Related

Sources

Primary (docs.snowflake.com, fetched 2026-09-24) — strong evidence:

Secondary (vault briefs citing primary sources) — medium evidence; Native App GA date rests on a release note read via index rather than direct fetch:

Not consulted / flagged: no analyst blogs or secondhand summaries were used. No source was paywalled or blocked. Nothing here was verified against a live Snowflake account — every "verify in the client account" note above is an untested docs reading.