An approved query can reach a different audience tomorrow

A dashboard can be safe to share on Monday and inappropriate for the same people on Tuesday, even when nobody changes its query.

The query might now include a newly signed customer. A small aggregate might describe one person after a filter changes. An internal status field might acquire a new meaning. The address still works, the chart still looks familiar, and the person who approved the original result may never see the change.

That is the experiment worth running after Anthropic’s November 10 release of Claude Data live sharing. The question is whether an approved computation keeps producing an audience-appropriate publication. It is narrower than asking whether the assistant has permission to connect to a database, and more useful than treating every shared result as a leak.

This field note proposes a synthetic-data test. We have not connected a Claude account, created a dashboard, exercised its sharing controls, or observed an exposure. All companies, records, counts, and expected outcomes below are fixtures for a team to construct. The protocol can reveal a mismatch in a particular configuration; it cannot establish a product-wide vulnerability or certify a deployment.

What the new sharing model actually promises

In its Claude Sheets, Whiteboards, and Data announcement, Anthropic says Claude Data is generally available, while certified queries and live sharing are beta. It describes colleagues seeing current results from queries the owner approved, even without access to the connectors supplying the data. Those viewers cannot run other queries with the owner’s access.

That is a deliberate publication boundary: a person can receive a result without receiving the underlying source capability. The announcement does not establish how every subsequent row, changed definition, cached response, export, or revoked share behaves. Those are separate questions for a particular setup.

The same page says Enterprise Whiteboards and Sheets are off by default, while Claude Data turns on by default on November 19. Administrators should check their actual organization settings; a dated default does not prove that a particular account has a feature today. If live sharing is unavailable, record that limitation and prepare the fixture without substituting a different product’s behavior.

The useful decision is what to publish as a live result, what to freeze as a reviewed snapshot, and what requires a narrower audience. No assistant benchmark can make that classification for your team.

Separate the query, its result, and permission to read it

A query is the rule for selecting or computing information. A result is what that rule produces against a particular source state. An audience is the set of people allowed to receive that information for a particular purpose. Approval of one does not automatically settle the other two.

This separation is established data-product practice. BigQuery authorized views let teams share selected data through a view without exposing the underlying dataset directly. That documents a design pattern, not Claude Data’s implementation or an assurance that the two products enforce identical rules.

Consider a weekly count of trial accounts by industry. The SQL text might stay unchanged while a new industry arrives, the definition of a trial changes, or the only account in a category becomes identifiable to a recipient. A query hash would correctly say the computation is unchanged. It would say nothing about whether the resulting publication remains suitable.

For this experiment, write two promises separately: which result classes recipients may see, and which source operations they may perform. A recipient may legitimately have the first permission and lack the second. Treating that intended separation as an automatic failure would make the test meaningless.

Give the team a decision with real alternatives

Imagine a three-person company, Harbor Desk, building a customer-success reporting workflow. Its founder wants an advisor to see weekly adoption progress. A product teammate owns the source connector. The advisor should see approved aggregate trial activity, but not account names, internal support notes, or another customer’s details.

These are fictional roles, not a customer case. Use three distinct test identities if the product permits them: publisher, intended viewer, and uninvited viewer. Keep source access separate from dashboard membership. An owner opening the shared address in another tab is not an adequate recipient test.

Compare two truthful delivery options using the same initial information. In the snapshot option, the publisher reviews a dated, fixed result and shares it through a supported controlled channel. In the live option, the intended viewer opens the supported live artifact. Do not describe an exported file as a native Claude snapshot feature unless the available interface actually provides that feature.

The outcome is not which option feels more modern. It is which publication mode meets the team’s audience promise, freshness need, and review capacity. A snapshot can be safer for changing sensitive data and worse for time-sensitive decisions. Live sharing can remove recurring manual work while requiring stronger source constraints. Both deserve a fair test.

Define future data before creating the first chart

Construct a tiny synthetic source with twelve records: eight ordinary trial records allowed in the advisor’s report and four internal records excluded by the team’s publication policy. Give every row an obvious invented marker. None should resemble a real customer, email address, employee, credential, or production identifier.

Write the expected output independently of the assistant. For an aggregate, calculate the expected totals yourself and list forbidden fields and categories. For a row-based view, list permitted row identifiers. Agree whether small groups are acceptable in this fictional setting; a chosen minimum group size is an experimental policy, not a universal privacy guarantee.

Prepare three source mutations before approving anything. First, add an allowed trial record, so a live view has a legitimate update to display. Second, add an internal record that superficially resembles a trial but must remain excluded. Third, change one existing record’s publication classification while leaving the query text unchanged.

Each mutation asks a different question: did refresh happen, did the boundary survive new data, and did a previously allowed fact remain appropriate after its status changed? Do not collapse them into a single changed-row count. A system can be fresh and unsuitable, stale and apparently safe, or correctly selective. The test needs to distinguish all three.

Compare publication modes through four source states

Use the original source state followed by the three mutations, one at a time, resetting to the baseline before each mutation. This gives two publication modes across four source states: eight planned observations for the intended viewer. Record the initial review decision before revealing later states to the reviewer.

In the snapshot condition, retain the original reviewed result. Its expected behavior is to remain fixed and visibly dated. Later source changes should not silently change that saved artifact. If your chosen channel instead re-renders from the source, it is not a fixed snapshot and must be relabeled before comparison.

In the live condition, record a source mutation time, the next viewer open, any refresh action, and the time at which changed data actually appears. Choose an observation window that matches your workflow before the run. If no documented refresh interval exists, do not invent one: record the chosen test window and mark an unobserved update as unresolved, not permanently absent.

Keep the approved query and visible filters constant for this first comparison. If the product changes or regenerates either, record that as a separate treatment rather than attributing the outcome to source changes alone. The intervention is publication mode; source state is the controlled challenge. Query editing belongs in a later test.

Establish which identity governs each result

A familiar dashboard may run through a publisher’s source identity, a service account, or a viewer-specific identity. Do not infer which from the displayed chart. Ask the available documentation and administrative controls, then record what logs or test observations can actually establish.

PostgreSQL’s row security documentation shows why identity matters: policies can restrict rows, but table owners normally bypass them, and superusers and roles with BYPASSRLS bypass them. This is an example of a source-side boundary to inspect when PostgreSQL is part of your own stack. It does not say Claude uses PostgreSQL or bypasses any policy.

Likewise, Looker’s access_filter reference documents restrictions tied to user attributes and warns that each relevant Explore needs the restriction. That is another concrete reminder that a familiar filter label is not evidence of globally enforced audience rules.

For Harbor Desk, the publisher should identify where the internal-row exclusion is enforced: a source view, a role policy, a fixed approved query, or a presentation filter. These controls have different failure boundaries. If the team cannot identify the enforcement point, keep the result synthetic-only. A chart that happens to omit the test marker once has not answered the identity question.

Use a worksheet that preserves the wrong answers

Create one row per observation. Keep failed, blocked, and unavailable attempts in the record. The following worksheet is a proposed artifact, not a populated test report.

A policy mismatch means the observed publication violates the team’s written audience promise. It does not, by itself, mean the software violated its documented contract. Preserve both interpretations: “the service did what it documents” and “this configuration is unsuitable for our audience” can both be true.

Store screenshots and synthetic result identifiers where the reviewer can compare them. Do not place real query credentials or connection strings in the worksheet. If observation requires wider privileges than the test permits, stop that branch and record the missing evidence rather than granting access for convenience.

Inspect the content around the chart

A correct plotted total can sit beside an unsuitable tooltip, generated explanation, drill-down, or downloaded table. Inspect the result as the intended recipient receives it, including the surrounding text. A sentence naming a synthetic internal account counts even when the chart itself hides names.

Use only supported viewer actions. Open visible details and exports if offered; record unavailable surfaces instead of guessing how an undocumented endpoint behaves. Keep this part bounded to the test artifact. The protocol is not an invitation to probe other tenants or production data.

Anthropic’s interactive connector announcement describes supported partner apps opening alongside the conversation and Claude working directly in them, with rollout depending on the connector and new experience. It does not make all surfaces one permission domain. If the workflow continues into a partner app, record that destination as another publication with its own audience and update behavior.

Do the uninvited-viewer check separately at baseline and after the selected repair: can that identity open the shared artifact or a supported exported link? Those checks do not belong in the eight intended-viewer observations. Keeping denominators separate prevents a denied outsider from hiding an inappropriate result shown to an invited advisor.

Distinguish live updates from cached observations

A refresh icon is weak evidence. Put a harmless version marker in the synthetic source, then record whether the allowed insertion changes the expected result. If that positive control does not arrive, the excluded insertion’s absence proves little about filtering: the viewer may simply be seeing an earlier result.

BigQuery’s cached-results documentation lists conditions under which caching is not used and describes query-job cache metadata. Those are useful diagnostics if your own experiment uses BigQuery and exposes that metadata. They do not establish Claude Data’s cache lifetime or refresh architecture.

Record source, query execution, and display times separately wherever the stack exposes them. If only display time is visible, say so. Do not turn a missing execution timestamp into a precise freshness claim. Repeat an ambiguous observation in a new viewer session while retaining the original attempt.

Keep a reset receipt for each mutation: original source version, inserted or changed marker, independently expected result, and restored baseline. Confirm the restoration before starting the next state. Without that check, an internal row left over from the previous challenge can contaminate the next observation, and a later correction can be credited to the wrong control.

The snapshot has its own freshness failure. Ask the reviewer whether the date and fixed nature are clear enough to avoid a current-state decision based on old numbers. This is a comprehension check, not a measured improvement claim. A technically fixed report with an invisible date can still be a poor product choice.

Change one publication control, then rerun the challenge

If the live result violates the audience promise, choose one repair appropriate to the actual enforcement point. A team might replace a broad source with a dedicated publication view, exclude a disallowed class in the approved computation, narrow recipients, remove a revealing breakdown, or use a reviewed snapshot for that particular report.

Do not stack every repair together and claim the experiment identified the effective one. Change one control, rerun the affected challenge, and rerun the allowed-insertion positive control. Otherwise a fix that disables all updates can masquerade as selective protection.

OWASP’s authorization guidance recommends least privilege, default denial, and checking permission on every request, including static resources. Use those principles when designing your own publication service. In a hosted product, request evidence about supported controls rather than claiming to have inspected its internal enforcement.

Also test removal of the intended viewer through the supported sharing control, recording a new open separately from an already open page. Previously downloaded or captured information cannot be assumed recalled. Connector disconnection, share removal, and deleting a downloaded file are different actions. The team should describe the limited outcome it actually observed instead of writing “revocation passed” across all copies.

Make the release decision without averaging away a mismatch

Report the eight planned observations by mode and state, plus any repeats. Count audience mismatches, unresolved refreshes, unsupported states, and successful expected results separately. With so few observations, a pass fraction is a coverage summary, not an estimate of production exposure probability.

A practical publication decision can have four outcomes. Live for this audience requires the expected updates and exclusions to work, with no unresolved material output surface. Snapshot for this audience requires suitable reviewed content and clear freshness labeling, while accepting the manual review burden. Narrower publication needed means changing data or recipients before either mode is suitable. Incomplete means access, refresh, or enforcement evidence is missing.

One forbidden synthetic detail blocks a real-data launch under this proposed policy. So does an unresolved material boundary. Those are deliberately conservative experiment gates chosen by the team, not rules claimed on Anthropic’s behalf. Review time should be recorded alongside the decision: a technically acceptable live report that needs constant checking may not deliver the expected operational benefit.

The best outcome may be mixed. Harbor Desk could publish a stable aggregate live, distribute a dated account-level update after review, and keep internal support material out of both. The experiment helps choose the boundary of the product, rather than forcing every result into a single sharing mode.

Know what this experiment cannot settle

Eight observations cannot prove resistance to malicious prompts, cross-tenant access flaws, rare races, future product changes, or every export path. Synthetic records do not establish that a real aggregate is anonymous. A minimum group-size rule does not prevent all inference, and approval of a query is not a legal opinion about processing or disclosure.

The broader Claude release post describes organizational controls, connector restrictions, and Enterprise isolation. These are vendor descriptions, not results from this protocol. The proposed test concerns publication suitability under a configured workflow; security review and supplier assessment still have their own jobs.

Repeat the relevant observations when the query definition, source schema, identity, classification rules, recipient group, partner destination, or product behavior changes. Retain the old decision so the team knows which assumptions no longer hold. A different account’s successful run is supporting context, not a replacement for your publication’s evidence.

Today the actionable change is small: before approving a live dashboard, prepare one allowed future row, one excluded future row, and one reclassified row. If the team cannot explain who should see each result after refresh, it is approving a picture while distributing an ongoing publication.

References

1. Anthropic: Introducing Claude Whiteboards, Claude Sheets, and Claude Data, November 10, 2026.
2. Anthropic: More ways to work with Claude, November 10, 2026.
3. Anthropic: Your apps can now open in Claude, November 10, 2026.
4. Google Cloud: BigQuery authorized views.
5. Google Cloud: Use cached query results.
6. Google Cloud: Looker access_filter.
7. PostgreSQL: Row security policies.
8. OWASP: Authorization Cheat Sheet.