A credential is not the whole permission model
Suppose you ask a cloud coding agent to inspect a repository and run its tests. You may want it to read that project, while keeping private documents and other projects unavailable. Later, the same agent may need to edit a file. A single allow-agent switch cannot express those changing task boundaries clearly.
ADC separates resource access from caller authority and local device limits. Owning a device, holding an Agent credential and exposing a folder answer different questions. Work proceeds only where those permissions overlap. This also makes a denial diagnosable: identify the narrow layer instead of guessing which broad role to enable.
Follow a request through the boundaries
First, the account must own the device or receive valid shared access. Next, the Agent grant selects the permitted device, folders and tools. Device policy can independently make a folder read-only or disable execution. The local Connector exposes the actual roots and capabilities, and validates the target path before executing.
For file.read on the repository README, every layer must allow the target and read tool. If the grant allows file.edit but the local root is read-only, editing is still denied. If the local device allows writes but the grant contains only read tools, editing is also denied. An online device alone grants nothing.
Shared devices add the owner's sharing and member policy to the same evaluation. An invitation does not transfer ownership or automatically authorize every agent. The recipient accepts the share and creates their own Agent access; all narrower restrictions still apply.
Approve an allowed action
Approval answers whether an otherwise permitted operation needs a human decision. It cannot make a denied path or missing tool available. For example, running a configured test template can require approval while reading the README does not. If both the caller's access and the device owner require approval, both decisions are needed.
Review the target, working directory and command before approving. Templates restrict the command choice, but the configured program may still write files or contact services. General shell access is broader: a working directory check is not an operating-system sandbox and does not confine all subprocess access to that directory.
Apply this to everyday work
Start by selecting the device and project folder, then choose tools for the actual task. Add a fixed template for a repeated test, or explicitly grant shell execution for tasks that need arbitrary commands. When a request fails, inspect the grant, device policy, root and advertised capability in that order, together with the recorded denial.
Narrowing or revoking access affects new work and is rechecked for active work during lease renewal. Cancellation remains cooperative and cannot undo an already completed write. Least privilege limits future authority; receipts and resource-specific recovery are still needed to understand earlier effects.