improvement(access-control): wire tool and model permissions into copilot editing - #7080

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 25, 2026 10:10pm

Greptile Summary

The PR applies workspace tool and model permissions consistently across Copilot editing and capability discovery.

• Adds shared tool and model access gates used by client and server paths.
• Filters denied tools from Copilot schemas, metadata, VFS output, and integration-tool discovery.
• Rejects disallowed tool and model values during workflow editing while retaining permitted existing values.
• Keys cached integration schemas by the effective permission policy and updates generated API contracts.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Permission-group config] --> B[Shared tool and model gates]
  B --> C[Copilot discovery projection]
  B --> D[Workflow edit validation]
  C --> E[VFS and metadata]
  C --> F[Integration tool schemas]
  D --> G[Persisted permitted workflow]
  D --> H[Skipped-item response]

_{Reviews (4): Last reviewed commit: "fix(access-control): key the copilot sch..." | Re-trigger Greptile}

On the deferred schema cache (payload.ts) — leaving this as-is deliberately, reasoning below.

The cache key is [userId, workspaceId, schemaSurface, visSignature], so it already varies with the viewer. Two users under different policies never share an entry; the only staleness is time-based, for the same user, bounded by the 5s TTL.

Three things make that acceptable:

• It is advisory, not authoritative. executeTool calls assertPermissionsAllowed({ toolId }) before every tool run, and that path is uncached. A tool advertised during the TTL window still cannot execute — the model would just get a permission error instead of never seeing it.
• The staleness is not new. allowedIntegrations was already gated inside this same cached function before this PR. This change widens what the cached projection covers, not whether it can be briefly stale.
• Keying on policy would cost more than it saves. getUserPermissionConfig is a DB-backed read with no cache of its own, so folding a policy signature into the key means loading it before the cache lookup — a query on every payload build, which is the cost this 5s cache exists to avoid.

If we want the window closed, the right fix is caching getUserPermissionConfig itself (the way block visibility is already memoized), which would benefit every caller rather than just this one — worth doing separately, not in this PR.

@greptile

@greptile

Reconsidered the schema-cache point and fixed it in 9438339 — my earlier reasoning was wrong on the cost.

I had argued that keying on policy would mean a DB read per payload build, defeating the cache. That mis-weighed what the cache is actually for: the expensive part of the entry is a user-tool schema built per exposed integration tool, not the permission lookup. Moving the config read out of the cached section and in front of the key keeps essentially all of the benefit, and the file already establishes exactly this pattern — visibilitySignature is resolved before the key and threaded into the builder for the same reason.

So the key now carries an integrationGateSignature (sorted allowedIntegrations + deniedTools) alongside the visibility signature, and the config is passed through instead of being loaded again inside. An admin's change takes effect on the next build rather than when the entry expires.

Added a test that denies a tool between two builds for the same viewer and surface, so only the policy component of the key can force the rebuild — verified it fails when that component is removed.

@greptile