When an AI Agent Serves a Group, Whose Permission Is It Using?

Imagine a household assistant that turns a school email into a calendar event. One parent shares the message, another parent sees the family brief, and the agent remembers a dietary preference for next week's meal plan. The demo feels seamless. The product question is harder: which person's permission made each step legitimate? If the original sharer leaves the group, can the other parent still see the event, the email excerpt, or the remembered preference?

Google Labs' September 2026 announcement of a group version of CC makes this a timely design problem. Google says each CC has a distinct account; up to six members can collaborate; each member chooses what to share; the agent distinguishes group memory from personal memory; and external action or sharing requires permission. Those are product claims about Google's experiment, not proof that every edge case has been solved. CC is currently described as an experimental, U.S.-only product for adults with personal Google accounts.

For a founder building a team, household, classroom, or client-facing assistant, the core judgment is this: a shared agent needs a permission decision for every movement of information and every external effect, not one broad group consent at onboarding. The agent's own identity helps with accountability, but does not give it authority to merge everyone's private contexts. This article gives you a six-part launch contract, a worked school-registration scenario, test cases, and a compact review artifact. It applies to products that combine private inputs from multiple people. It is not a claim that a small app must reproduce Google's infrastructure or that the design by itself satisfies every privacy law.

A shared account is an identity, not a mandate

The most interesting feature in Google's CC description is the agent's own verified account. A distinct identity means other members can recognize when CC has posted or changed something. It also provides a place to attach permissions and audit events. The claim that CC only sees what members choose to share is central: a group assistant should not inherit one founder's or administrator's entire inbox merely because that person created the group.

Identity and authorization are different terms. Identity answers who is making a request. Authorization answers whether that identity may perform this particular operation on this particular resource now. The OWASP Authorization Cheat Sheet recommends denying access by default and checking permission on every request. A bot with its own address can still be overprivileged; a signed-in group member can still lack permission to see another member's source document.

For product design, represent the agent as a separate principal with limited capabilities. Do not treat it as a universal proxy for the member who invited it. Record the source member, source object, sharing decision, intended audience, action requester, and action approver. When those differ, the system should show the difference rather than silently collapsing them into a generic “group owner.”

This distinction matters in ordinary cases. A calendar entry can be shared while the email that prompted it remains private. A reminder can tell the group that a form is due without revealing a child's medical note attached to the form. An agent can prepare a registration draft while only a parent with the needed authority can submit it. The product should support these narrower outcomes even if a broad “share everything” flow would be easier to build.

Map five boundaries before building the workflow

Draw five boundaries for one representative task. First is ingestion: which person deliberately made which source available to the agent? Second is derivation: what facts can the agent extract and store? Third is audience: who may see each extracted fact in a brief, chat message, calendar item, or search result? Fourth is action: who may authorize an external change? Fifth is retention: what survives a changed permission, removed member, or expired task?

These boundaries are connected, but they are not interchangeable. Permission to read an email is not permission to quote it to six people. Permission to create a draft is not permission to send it to a school. Permission to show a fact today is not necessarily permission to keep it in persistent memory. A revocation that blocks future reads but leaves copied summaries accessible is incomplete from the user's point of view.

Google's announcement gives concrete input modes: members can choose recurring senders, forward a one-off message, share Drive files or folders, or add CC to a Calendar. Those modes have different risk shapes. A one-off forward is naturally bounded to one object. A sender rule is continuing authorization over future, unknown messages. A shared folder can expand as files are added. A calendar connection can expose location, timing, and participant information. Treat these as separate grants in the interface and in the access ledger.

The NIST AI RMF Core asks teams to define human and AI responsibilities, privacy requirements, and oversight in the actual context of use. It does not prescribe this five-boundary model. The model is our practical translation for a product team: make the flow visible enough that a reviewer can point to each decision and its responsible actor.

Consent must describe scope, destination, and duration

“Connect your email” hides three questions. Scope says which messages or categories may be read. Destination says where derived information may appear. Duration says whether the grant covers one event, a recurring sender, or a standing integration. A credible permission screen states all three in user language before collecting the data.

Google's OAuth policy requires apps using its APIs to request the smallest necessary scopes and use data as represented to users. That platform rule is not a complete group-sharing policy. An app could hold a read-only Gmail scope and still make a bad product decision by broadcasting a private message into a shared brief. External API scopes bound what the connector can do; the app must separately enforce audience and purpose at the object level.

A good interface might say: “Share messages from school.example with this household to extract dates and required supplies. New messages will be considered until you turn this off. The full message stays visible only to you unless you share it separately.” A one-off alternative might say: “Use this invitation once to create a group event. Do not save its attachment to group memory.” Those are examples of product copy, not descriptions of CC's actual screens.

The scope should be editable and inspectable later. The user should see which sources are active, when they were last used, which outputs they produced, and how to stop future processing. A grant that is easy to create but hard to locate is not meaningfully controllable. If the underlying connector changes its own scope or the product adds a new output destination, re-present the relevant choice instead of treating old consent as a blank check.

A school-registration scenario exposes the real decisions

Consider a hypothetical product, Household Desk. Maya forwards a school email about a Saturday swimming class. The message lists a deadline and a PDF registration form; its attachment also contains a private note about a child's health condition. Her partner Lin belongs to the same household group. The assistant proposes a shared calendar reminder, pre-fills the PDF, and writes “avoid peanuts” into group meal preferences after seeing a separate note from Maya.

At ingestion, Maya's forward authorizes the assistant to process that one message for a stated purpose. It does not automatically authorize scanning the rest of her inbox. At derivation, the class deadline may become a group task if the intended audience is the household. The health note needs a more restrictive label: it may be necessary for the form, but it should not be inserted into the group brief. At action, pre-filling is a draft; submitting the PDF or sending it outside the group requires a separate approval by the person with authority to do so. At memory, the dietary note should be attributed to Maya, assigned a visibility level, and given a review or expiry rule.

Now run a change: Maya withdraws the forwarded email and leaves the group. What happens to the calendar event, the attached PDF, the extracted deadline, and the dietary preference? A sensible system can preserve a group-authored calendar event if it has a separate, explicit group basis, while deleting or hiding private source text and facts derived solely from the withdrawn grant. The exact retention choice depends on the product promise and applicable obligations. The important point is to make that dependency explicit before launch; a database deleted_at column added later cannot recover provenance that was never recorded.

This example is deliberately not a claim about Google CC. It is a test fixture for any shared assistant. The scene is useful precisely because a pleasant outcome and a privacy failure can coexist. The family may still get a correct reminder while the brief leaks a sensitive note or while the assistant submits a form no one reviewed.

Group memory needs provenance and an audience label

Google says CC has shared memory and can distinguish household facts from individual facts in its launch post. That is an important product promise because persistent memory changes the consequences of a one-time disclosure. A fact that seemed harmless in one conversation can reappear in another person's answer weeks later.

Treat a memory item as a record with more than text: source object, source member, extraction time, purpose, audience, confidence, review date, and deletion dependency. Provenance means the ability to trace a stored fact back to the input and permission that justified it. An item with no provenance should not be promoted to durable shared memory. Otherwise you cannot distinguish “Lin told the group our preferred restaurant” from “the model inferred a preference from Maya's private receipt.”

Create explicit memory classes. A personal fact can help its owner but should not appear in group output by default. A shared fact is explicitly approved for the group. A task fact exists until a named task completes or expires. An unverified inference can be offered for confirmation but should not silently become policy or profile. Model confidence is not a substitute for the person's choice of audience.

The OWASP 2025 LLM risk list identifies sensitive information disclosure, prompt injection, and excessive agency as separate risks. For group memory, these can interact. A malicious document may instruct the agent to save a false “family preference”; a private fact may be made available to the wrong member; and a tool can act on that fact. The practical response is to keep untrusted source instructions out of authority decisions, label memory before use, and test retrieval under multiple member identities.

Action approval belongs to the effect, not the chat turn

An assistant may ask “Should I handle it?” in a conversation, but an approval must bind to the actual effect. It should specify the target service, recipient or resource, data fields, price or commitment if relevant, and the exact version of the draft. If the agent changes any material field after approval, the approval should no longer authorize the new action.

The OWASP excessive-agency guidance illustrates how an agent with email access and forwarding ability can be redirected by malicious incoming content. A friendly household email can also contain irrelevant commands. The safe architecture checks permissions at the action boundary in ordinary code, independent of whether the model says the action is appropriate. OWASP's business-logic guidance similarly recommends rechecking resource ownership and security-relevant values server-side on each request.

Separate three states in the UI: proposed, approved, and confirmed by the external system. A pre-filled form is proposed. A parent's click on a stable form digest is approved. A submission receipt from the school portal is confirmed. The assistant's text “Done” is not confirmation. If the portal times out after a submission attempt, show uncertainty and reconcile before trying again; a blind retry can create duplicate registrations or payments.

For low-impact tasks, a group may opt into a narrow standing grant, such as adding draft reminders to a shared list. For disclosures to outsiders, payments, medical forms, or irreversible updates, ask a named human to approve the exact action. This is a product policy recommendation, not a universal legal rule. Teams should adapt thresholds to their domain and actual consequences.

Revocation is a workflow, not a settings toggle

Members change their minds. A child changes schools; a contractor leaves a client group; a co-founder departs; an email sender once trusted begins sending sensitive material. Revocation should stop new collection immediately, invalidate outstanding approvals that depended on the grant, and trigger a review of derived material. It should also be testable: after revocation, attempt the same query and action under each remaining member identity.

The system needs to distinguish source withdrawal from group artifact ownership. If Maya withdraws a source email, the product may need to erase its extract and prevent future retrieval. A group calendar event that Maya separately approved for the group could have a different basis. Do not assume the correct outcome from the data type alone; track the grant that made each derivative available. If a task record combines private and group facts, rebuild it from the remaining authorized facts or hide it until a human resolves it.

API-level revocation is also only one layer. Google's OAuth policy discusses removing unused scopes and tokens. The product still needs to handle cached text, embeddings, summaries, notifications already sent, and external actions already completed. Some effects cannot be undone. Show the user the difference between “future access stopped,” “stored copy removed,” and “past message delivered.” Promise only the controls you can demonstrate.

If your app uses mailbox change notifications, note the operational detail in Google's Gmail watch documentation: a watch can be restricted by labels; without such filters, changes are not narrowed that way. That API option does not replace per-message policy, but it is another opportunity to avoid ingesting unnecessary change events.

A reusable permission contract for one workflow

Before launch, have the product owner, engineer, and privacy reviewer fill out one row per workflow. This is a design artifact, not a claim that a spreadsheet alone enforces security. The examples below use the hypothetical school scenario.

Attach a short decision record to each row: owner, current behavior, evidence from a test, open limitation, and ship/limit/hold verdict. Do not mark a row green because the model phrased its answer well. Ask whether the unauthorized read, disclosure, memory promotion, or action was technically blocked. In NIST's Generative AI Profile, managing risk is a lifecycle activity; this table turns that general principle into a reviewable release conversation for a shared agent.

Test the combinations that a happy-path demo misses

A basic test with two cooperative members is weak evidence. The same flow should be exercised with a new member, a removed member, a revoked source, a changed attachment, an untrusted instruction inside a forwarded email, and an external service that reports an ambiguous timeout. Include a case where one member grants an object but refuses to share a derived fact. Include one where the agent has an API credential broad enough to reach the object, but the app's own audience policy must still deny it.

Use two test oracles. The authorization oracle checks the application's decision record: source, requester, audience, current grants, and action scope. The outcome oracle checks authoritative state: who actually received the brief, which calendar was changed, whether the form was submitted, and which memory entries remain retrievable. A model-generated explanation is neither oracle. This separation catches a particularly dangerous case: the assistant politely says it cannot share a secret while a background summary job already sent that secret to the group.

Make the pass condition behavioral. For example: “After Maya revokes the forwarded message, Lin cannot retrieve its attachment or any unapproved extract through chat, search, daily brief, or exported calendar description.” Then test each surface. If the product cannot support full deletion of a delivered external message, state that limit in the interface and test that no further copies are sent.

An early team can begin with a small, hand-reviewed suite instead of an elaborate automated benchmark. Keep the scenario and expected outcome stable, run it after changes to connectors, prompts, memory code, and membership logic, and retain the receipts. Expand when a real incident or support request reveals a missing boundary. The point is to verify a customer promise, not to produce an impressive test count.

Ship, limit, or hold: the founder decision

Ship a narrow pilot when every tested source has a visible grant, shared outputs enforce audience labels, high-impact actions bind approval to an exact effect, revocation stops future access, and independent outcome receipts match what the interface says. The pilot can still limit the number of connectors, members, and action types. A narrow reliable workflow is more useful than a broad assistant whose permission story depends on trust in the prompt. Limit the feature when the core value is real but one boundary remains uncertain. Perhaps the app can create drafts and reminders but cannot reliably prove what a third-party portal accepted. Keep submission manual. Perhaps group memory cannot yet be revoked precisely. Keep memory session-only, or require a person to approve every shared fact. Tell users which step still needs their review. Hold the launch if one member can cause the assistant to reveal another member's unshared source, if a revoked grant remains retrievable through a secondary surface, if external action occurs without a bound approval, or if the UI says “done” without an external receipt. These are product failures even when the model's answer sounds reasonable.

The larger lesson from Google's CC announcement is not that every founder needs a household agent. It is that the moment an assistant serves more than one person, “helpful” must be defined per person, per source, per audience, and per effect. A shared agent can make coordination easier only when people can tell what it knows, why it knows it, who will see it, and what it is allowed to do next.

References

• Google Labs, “The new CC, an AI agent built for families”
• NIST, AI Risk Management Framework Core
• NIST, Generative AI Profile
• OWASP, Authorization Cheat Sheet
• OWASP, Business Logic Security Cheat Sheet
• OWASP, Top 10 for LLM Applications
• OWASP, Excessive Agency
• Google, OAuth 2.0 Policies
• [Google, Gmail API users.watch](https://developers.google.com/workspace/gmail/api/reference/rest/v1/users/watch)