OS Access Controls — Audit & Forward-Looking Design
2026-03-04
Current State
What exists today
The dashboard lives on Vercel behind Google OAuth, restricted to @daisyai.ai emails. Once you're in, you see everything — fundraising, clients, network, personal logs. Two people, full trust, no roles.
Where credentials live
| Credential | Location | Committed to git? |
|---|---|---|
| Neon DB (DATABASE_URL) | .env.local, Vercel env | Yes (in history) |
| Neon MCP token | .mcp.json | Yes |
| Linear API key | .mcp.json | Yes |
| Google Workspace MCP OAuth | .mcp.json | Yes |
| Google OAuth (dashboard) | .env.local, Vercel env | No |
| Anthropic API key | .env | Yes (in history) |
| Apollo API key | .env, .env.local | Yes (in history) |
| AUTH_SECRET | .env.local, Vercel env | No |
Risk: .mcp.json and .env are tracked in git. Anyone with repo access can read all keys from commit history. Fine for two founders in a private repo. Not fine with 5+ people.
Services connected
| Service | What it does | Access level |
|---|---|---|
| Neon Postgres | Forum, gallery, graph data | Full DB owner |
| Linear | Issue tracking | Full workspace |
| Google Workspace MCP | Gmail, Drive, Calendar, Docs, Sheets | Core tier (read/write) |
| Apollo | People search, contact enrichment | Full API |
| Vercel | Dashboard hosting | Team admin |
GitHub (daisyai-ai/OS) | Source of truth | Private org repo |
| Slack | Agent notifications → #daisy-agents | Webhook (write-only) |
| Google Meet | Meeting polling via service account | Domain-wide delegation |
Dashboard data exposure
Once authenticated, a user can:
- Read any file in the repo (fundraising pipeline, investor notes, client details, personal logs)
- Use the chat tool (Claude with full OS context)
- Post to forum/gallery under any name (no server-side identity attribution)
- Search Apollo contacts (costs credits)
- Delete CRM accounts
What changes at different scales
5 people (first hires)
Problem: Everyone sees everything. New engineer sees investor term sheets and client pricing. Not great.
Minimum viable changes:
- Move all secrets out of git. Use Vercel env vars + a
.mcp.json.exampletemplate. Each person configures their own MCP locally. - Rotate every key that's been in git history (Neon, Linear, Anthropic, Apollo, Google OAuth).
- Forum/gallery: attribute posts to the authenticated session user, not a free-text name field.
Nice to have:
- Role-based dashboard sections. Simple:
adminvsmember. Admins see fundraising + client financials. Members see everything else. - Per-person Linear API keys instead of a shared org key.
10 people (small team)
Problem: You need actual roles. An engineer shouldn't see investor pipeline details. A BDR shouldn't have access to modify the product roadmap in Linear.
Changes:
- Google Workspace groups → map to dashboard roles (e.g.,
eng@daisyai.ai,gtm@daisyai.ai,leadership@daisyai.ai) - Dashboard middleware checks group membership, gates sections:
| Section | Leadership | Eng | GTM |
|---|---|---|---|
| Dashboard | Yes | Yes | Yes |
| Clients | Yes | Read-only | Yes |
| Fundraising | Yes | No | No |
| Network | Yes | No | Yes |
| Huddles | Yes | Yes | Yes |
| Forum/Gallery | Yes | Yes | Yes |
| Personal logs | Own only | Own only | Own only |
| Chat (Claude) | Full context | Eng context | GTM context |
- Secrets management: move to something real (Vercel env vars for dashboard, 1Password/Doppler for shared dev secrets).
- GitHub: branch protection on main, PR reviews required.
50 people (company)
Problem: This markdown-based OS probably doesn't scale to 50 people as-is. But the access model still matters.
Changes:
- SSO (Google Workspace SAML or OIDC) with SCIM provisioning
- RBAC with actual permission system (not just "admin vs member")
- Audit logging (who accessed what, when)
- The OS becomes more of a leadership tool; most employees use Linear, Slack, Docs directly
- API routes need per-endpoint authorization, not just "authenticated = full access"
- Data classification: investor data is confidential, client data is restricted, public content is public
External access (investors, advisors)
Never give them dashboard access. The OS contains competitive intel, client details, and internal strategy they shouldn't see.
Instead:
- Investors: Share specific materials via Google Drive links with expiry. Use the data room pattern — curated folder with financials, deck, product demo. Read-only.
- Advisors: Case by case. Some advisors (like a clinical advisor) might get access to specific client context. Create a read-only view or just share specific docs.
- Board members (eventually): Dedicated board portal or a filtered dashboard view showing only board-relevant metrics and materials.
Immediate action items
These aren't urgent but should happen before the next hire:
- Add
.mcp.jsonto.gitignore, create.mcp.json.examplewith placeholder values - Rotate keys that have been in git history (Neon password, Linear key, Anthropic key, Apollo key)
- Attribute forum/gallery posts to authenticated session email instead of free-text name
- Remove
OAUTHLIB_INSECURE_TRANSPORT=1from committed config
Design principle
Start open, narrow as you grow. The cost of premature access control is friction and complexity when you're moving fast. The cost of too-late access control is a security incident or an awkward conversation with an employee who saw something they shouldn't have.
Right now: two founders, full trust, everything visible. That's correct. Just be ready to tighten when the first hire happens.