Execution boundaries come before capability
Agent capability does not expand without limit. Every project folder has an explicit device and directory scope; file, terminal, and browser tools can only execute inside it. Remote access needs a separate grant and is not acquired automatically by signing in.
Repository allowlist
Paths outside the project must be listed explicitly before the Agent can read or write them; unlisted paths stay blocked.
Project budget
You can set a maximum budget per project; when it is reached, new turns stop instead of consuming more.
Device boundaries
Local, remote, and cloud devices each have different resources and do not share implicit file system permissions.
Permissions stack layer by layer
For an operation to run, product permissions, project authorization, tool policy, and device capability must all be satisfied. If any layer fails, you get an explicit denial or a pending approval, not a silent bypass.
| Layer | Question it answers |
|---|---|
| Account and plan | Is this account allowed to use this capability? |
| Project authorization | Is this user allowed to access this project or device? |
| Tool policy | Does this tool need approval? Which targets and parameters are allowed? |
| Device capability | Does the current computer actually provide this tool? |
Remote access and Grants
When you need to reach a project from another device or from the cloud, use a remote access grant. A Grant describes its scope explicitly and can be revoked at any time; once revoked, new commands and subscriptions stop immediately without waiting for the next sign-in.
- Prefer read-only or single-project scope over the entire workspace.
- Set a validity period for remote access and revoke it when the task ends.
- When a remote project is offline, the workbench should show why it is unavailable instead of pretending execution succeeded.
- Sharing an account is not the same as sharing permissions; authorize each member separately by role and project.
Audit and traceability
Action records
Key administrative actions, grant changes, and tool approvals can be recorded for security review and troubleshooting.
Execution evidence
Tool calls, diffs, test results, and Reviewer conclusions in the conversation form an execution chain you can review later.
Minimal exposure
The secrets interface shows only status and a fingerprint; sensitive values should not appear in logs, exports, or error messages.
Separation of duties
Planning, execution, and review can be owned by different roles, so one Agent is less likely to change code and certify its own work.
Audit records are not necessarily in one system: the portal / cloud account service records administrative actions and grant events, tool calls and detailed execution logs stay on your computer, and usage records live with the model service. Each type follows its own retention policy.
Enterprise rollout checklist
Activation codes, plans, and channel scope are isolated per product, so quota and entitlements do not mix across products. This is product-level isolation, not organization-level tenant isolation.
- Project folders, devices, and the repository allowlist are configured with least privilege.
- Provider keys and project Secrets are separate, and production keys are not shared with every project.
- Remote Grants have explicit scope and expiry, and members who leave are revoked promptly.
- Project budgets, model choices, and tool approval policies have been verified.
- The team knows how to review execution records, checkpoints, and audit events.