How access is evaluated
01Workspace membership02Company availability03Person consent04Connection policy05Runtime enforcement
Removing membership, a catalog item, a connector grant, or a tool approval changes the effective runtime policy. The next request is checked against current authority rather than relying only on what was true when the app first connected.
Workspace roles
| Role | Access |
|---|---|
| Owner | Manage resources, model policy, access, budgets, reviews, and administrators |
| Admin | Manage resources, model policy, access, budgets, and reviews |
| Publisher | Publish catalog resources and contribute knowledge |
| Member | Use available resources and contribute knowledge |
Runtime enforcement
| System | Responsibility |
|---|---|
| MCP.computer | Configuration, reconciliation state, and customer-visible history |
| LiteLLM and gateway | Model, key, budget, MCP-server, tool, and parameter enforcement |
Requests are checked against the effective gateway policy at runtime.
Reconciliation status
- Active: the desired revision is enforced.
- Provisioning: reconciliation is still in progress.
- Needs attention: the desired revision could not be applied.
Data handling
- Inference and tool-execution bodies do not traverse the Vercel control plane.
- Provider credentials and reusable gateway secrets are not stored in the product database.
- One-time connection secrets are shown once; durable records keep identifiers and hints.
- Activity records contain metadata such as actor, app, action, decision, latency, and outcome—not prompts or tool bodies.