[superlog] Add manage:websites scope to insights service auth

[superlog-app]

Summary

The insights agent's goal auto-update feature fails with FORBIDDEN: API key missing required scope: manage:websites on every scheduled run that triggers a goal mutation.

The insights agent is initialized with capabilities: ["investigation", "mutations"], giving it tools like update_goal, create_goal, create_funnel, and create_annotation. These tools call withWorkspace(context, { websiteId, permissions: ["update"] }) in the RPC layer. Because a websiteId is always passed, withWorkspace resolves the effective resource as "website", which maps the "update" permission to the "manage:websites" scope via RESOURCE_SCOPE_OVERRIDES. The service auth in runInsightsAgent only declared ["read:data"], so every mutation call is rejected.

The fix adds "manage:websites" to the insights service auth scopes so that the agent can perform all website-scoped mutations it already has tools for.

Alternative approach: instead of widening the service auth scope, goal/funnel/annotation mutations could be extracted to a separate worker call that uses full user credentials. This would be more restrictive but adds significant complexity. The current service-auth pattern already exists for internal service calls and widening it to manage:websites is the minimal correct fix given how withWorkspace resolves the resource.

Incident on Superlog

---

Was this PR helpful? Leave feedback — goes straight to the Superlog team.

---

Summary by cubic

Adds the manage:websites scope to insights service auth so the agent can run website-scoped mutations. Fixes FORBIDDEN errors during scheduled goal auto-updates.

• Bug Fixes
  • Updated runInsightsAgent service auth to include ["read:data", "manage:websites"].
  • Aligns with withWorkspace(..., { permissions: ["update"] }) resolving to website resource which requires manage:websites.

^{Written for commit fbc1007. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
databuddy-status	Ready	Preview, Comment	Jun 12, 2026 6:20am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
dashboard	Skipped		Jun 12, 2026 6:20am
documentation	Skipped		Jun 12, 2026 6:20am

[unkey-deploy]

The latest updates on your projects. Learn more about Unkey Deploy

Name	Status	Preview	Inspect	Updated (UTC)
api (preview)	Ready	Visit Preview	Inspect	Jun 12, 2026 6:20am

[greptile-apps]

Greptile Summary

Adds "manage:websites" to the serviceAuth scopes in runInsightsAgent so that scheduled runs of the insights agent can execute website-scoped mutations (goal updates, funnel creation, annotations) without hitting a FORBIDDEN error.

• The one-line change aligns the declared service auth scopes with the permissions that withWorkspace actually requires when a websiteId is present — RESOURCE_SCOPE_OVERRIDES maps create/update/delete on the "website" resource to "manage:websites", so the previous ["read:data"]-only auth was always too narrow for any mutation tool the agent invoked.
• manage:websites is broader than goals/funnels/annotations alone; it also covers the website entity itself (domain changes, deletion, etc.). The insights agent's actual tool set is the effective limiter here, but any expansion of that tool set in the future will automatically inherit this wider scope without a corresponding auth change.

Confidence Score: 4/5

Safe to merge; fixes a real auth gap that was blocking every scheduled mutation in the insights agent.

The fix is correct and minimal. The manage:websites scope is slightly wider than the current tool set strictly needs (it also covers raw website entity management), so any future tool additions to the insights agent would inherit this broader authority automatically without requiring a matching auth review.

No files require special attention beyond the single changed line.

Important Files Changed

Filename	Overview
apps/insights/src/generation.ts	Adds manage:websites to the insights agent's service auth scopes; fixes the FORBIDDEN error on all website-scoped mutations. The scope is correct but broader than the current tool set strictly requires.

Sequence Diagram

sequenceDiagram
    participant Scheduler
    participant InsightsWorker as Insights Worker (runInsightsAgent)
    participant ToolLoopAgent as ToolLoopAgent (AI)
    participant RPC as callRPCProcedure
    participant ServiceAuth as createServiceAuth
    participant WithWorkspace as withWorkspace
    participant ScopeCheck as requiredScopesForResource

    Scheduler->>InsightsWorker: Trigger scheduled run
    InsightsWorker->>InsightsWorker: "Build AppContext serviceAuth.scopes = [read:data, manage:websites]"
    InsightsWorker->>ToolLoopAgent: run(tools, context)
    ToolLoopAgent->>RPC: update_goal(websiteId, ...)
    RPC->>ServiceAuth: createServiceAuth(orgId, scopes)
    ServiceAuth-->>RPC: synthetic apiKey with scopes
    RPC->>WithWorkspace: "withWorkspace(ctx, { websiteId, permissions: [update] })"
    WithWorkspace->>WithWorkspace: "effectiveResource = website (because websiteId present)"
    WithWorkspace->>ScopeCheck: requiredScopesForResource(website, [update])
    ScopeCheck-->>WithWorkspace: [manage:websites]
    WithWorkspace->>WithWorkspace: hasKeyScope(apiKey, manage:websites) OK
    WithWorkspace-->>RPC: Workspace
    RPC-->>ToolLoopAgent: success

Loading

_{Reviews (1): Last reviewed commit: "[superlog] Add manage:websites scope to ..." | Re-trigger Greptile}

[greptile-apps]

manage:websites scope is wider than the current mutation tools require

manage:websites is the correct scope to unblock goal/funnel/annotation mutations (per RESOURCE_SCOPE_OVERRIDES), but it also grants authority over the website entity itself — domain name changes, deletion, etc. Right now the actual tool set is the effective limiter, but if a new tool is later added to the "mutations" capability (e.g. delete_website, update_website_domain) it would silently inherit this scope without any corresponding auth review. Consider documenting the intent here (e.g. a comment listing the specific mutation types this scope is intended to cover) so future contributors know to re-evaluate the scope if the tool set expands.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!