Project-scoped reader account for shared content ingestion

Family

credential-tenancy

Status

proposed

Complexity

low

Advances

PL4-least-privilege PL1-stakeholder-context PL1-real-world-feedback PL2-agent-audit-trail

Prerequisites

—

Project-scoped reader account for shared content ingestion

Purpose

Extend the “narrow credential tenancy” principle to personal-SaaS tools (meeting recorders, note-takers, inbox-shaped services) that don’t expose a formal bot or service-account primitive. The mechanism: a dedicated account that never originates content and is used strictly as a recipient of content deliberately shared in by collaborators. Converts the default credential blast radius — “access to everything the account holder has ever been in” — into “access only to what was deliberately shared.”

Architecture

• Create a dedicated account under a project-scoped identity (e.g. <project>-notes@...). Free tier usually suffices.
• The account is strictly a recipient: it never records, generates, or originates content. Its own activity surface stays empty.
• Collaborators share project-relevant content into the account’s visibility using whatever primitive the platform offers: shared folder, per-item share, workspace-member invitation, collection access.
• The platform’s desktop or web client logs in as this account on a dev machine or dedicated host. Credential is extracted from the local app’s auth path (typically a file the app writes) and handed to the MCP.
• The MCP reads via that credential. The agent sees only content that has been deliberately shared in — the sharing-act itself is the opt-in primitive for content entering agent context.

Distinct from the bot-token credential tenancy recipe by platform constraint: bot-token applies where the platform offers a first-class bot/service-account (Slack apps, GitHub Apps, GCP service accounts); this recipe applies where the platform only offers user accounts and relies on the “dedicated idle account” pattern to get equivalent tenancy narrowing. Same family, different mechanics.

Criteria advanced

• PL4-least-privilege IAM scoped read-only by default — direct level-2 contributor. Credential reach is structurally bounded by what has been shared, not by a revocable permission list. A sharing rollback narrows reach; a permission revocation on a user token still leaves whatever was cached.
• PL1-stakeholder-context Client / stakeholder context — direct level-2 contributor when stakeholder meetings / notes are shared into the account. Turns “stakeholder context” from something curated by hand into something structurally captured by the sharing act.
• PL1-real-world-feedback Real-world feedback loop — direct level-2 contributor for the meeting-note / transcript signal type. Provides a clean ingestion path for structured stakeholder signal without introducing an enumeration surface over unrelated content.
• PL2-agent-audit-trail Agent action audit trail — partial contributor. Platform-level share history records who shared what and when; a clean audit trail emerges naturally from the mechanism, separate from agent-action instrumentation. Not sufficient alone for level-2 — that needs decision-level reasoning at the agent layer — but provides the content-provenance half.

Prerequisites

Platform-capability prerequisites, not rubric-criterion prerequisites:

• Multi-account identity — two accounts can coexist on the same device or workspace without one clobbering the other.
• Some sharing primitive — shared folder, per-item share, member invitation, or equivalent that lets content cross from one account’s visibility into another’s.
• Agent-readable credential path — typically the platform’s desktop app writes a token to local config that an MCP can read. Platforms that refuse to expose a token to anything but their own client don’t support this recipe.

Failure modes

• Scope creep via sharing-happy collaborators. Someone mass-shares their entire history into the project folder “just in case,” inflating the account’s reach beyond what anyone actually meant. Mitigation: document the sharing convention explicitly (“share only meetings materially relevant to this project”); periodic share-audit as part of the quarterly staleness sweep.
• Plan-tier gating of agent-critical features. Free tier may cap retention window, number of shared items, or specifically the API / MCP surface the agent needs (e.g. Granola’s transcript-fetch tools gated to paid plans). Mitigation: first step in any deployment is empirically verifying the free-tier surface matches the design; fall back to paid seat or different substrate if not.
• Orphan account on owner departure. If the account email belongs to an individual who leaves the org, account recovery can be awkward or impossible. Mitigation: create the account under an org-owned shared email alias from day one; document recovery path.
• Session hijacking via the local token. The desktop app’s local token grants full account reach. Mitigation: treat it as a first-class secret — gitignored storage, rotated on exposure, CLAUDE.md-class handling.
• Sharing-as-consent ambiguity. Collaborators may share content without realising it becomes agent-readable. Mitigation: document the expectation on the account’s sharing-convention note; include it in onboarding when a new stakeholder first shares content.
• Personal-SaaS service changes. Personal-SaaS vendors iterate fast; free-tier features move behind paywalls, API surfaces deprecate, account creation gets new friction. Mitigation: quarterly integration sweep verifies the mechanism still works; contingency plan names an alternative substrate.

Open design questions

• Succession. How is account ownership transferred when the email-owner leaves? Shared-email alias from the start is the cleanest, but adds a setup prerequisite.
• Per-project vs. shared-across-projects. One project account per client engagement? Or one account with per-project tags / folders serving multiple projects? The first is stricter; the second amortises setup cost. Choice depends on how much cross-project leakage is tolerable.
• Convention for multi-project content. A meeting that spans two client projects — does it get shared into both accounts? Neither? The project where it originated? Needs a default convention before the first cross-project case.
• Content that should stay out even if project-relevant. Some meeting content carries third-party confidentiality (client’s client data, competitor mentions, personnel discussions). Sharing convention needs to name what not to share, not just what to share.

Cost estimate

Low. Account creation, desktop app install, token extraction, MCP wiring: typically a few hours. Ongoing cost is proportional to onboarding friction for new collaborators (teaching the sharing convention), which amortises quickly. Compares favourably to alternatives like running the agent under a user credential (higher ongoing blast-radius cost) or ingesting transcripts manually (higher per-meeting cost).

Related recipes

• Same family as: bot-token credential tenancy — the first-class-bot variant of the same tenancy-narrowing principle. Use bot-token where the platform supports it; use this recipe where it doesn’t.
• Composes with: two-layer MCP scoping (credential layer plus tool-layer enforcement — e.g. enumeration-tool denial on the MCP side).
• Composes with: tool-level enumeration denial — particularly important here, since personal-SaaS MCPs often expose list_* / query_* tools that broaden the effective reach even when the account tenancy is narrow.
• Alternatives to: running the agent under a user-owned credential (weaker: blast radius is the user’s full library); manual transcript paste (higher per-meeting cost; no structural discipline).