GitHub is letting a language model decide which of Copilot’s shell commands, file-system accesses and URL fetches are safe enough to run without asking the developer first. The option, called assisted permissions, became generally available Monday in GitHub Copilot CLI, the GitHub Copilot app and Visual Studio Code, GitHub said in a changelog post.
Without assisted permissions, developers working with Copilot’s agent choose between answering approval prompts one at a time and granting blanket permission, which removes oversight of individual actions. GitHub’s documentation calls the new mode “a middle ground between manual approval and granting broad permissions with an allow-all option.” A model reviews each eligible request and approves the ones it judges safe in the context of the task. Anything it isn’t confident about goes to the developer, as it would under manual approval.
What the reviewer model actually sees
Existing rules are checked first. Deny rules and enterprise restrictions still apply, and requests a user’s permissions already allow skip both the prompt and the model review. Assisted permissions doesn’t review other tool calls that enterprise rules require a person to approve, or requests to bypass local sandboxing. If a safety review is unavailable or can’t evaluate a request, the request falls back to the session’s normal permission handling.
Copilot picks the review model itself, and it can be different from the one a developer chose for the conversation. Developers who use their own model provider get their session’s active model as the reviewer.
In the CLI, /permissions assisted turns the mode on for the current session, and setting defaultPermissionMode to “assisted” in ~/.copilot/settings.json makes it the default for new interactive sessions. Unattended jobs such as CI/CD workflows use the --assisted-approval flag or the COPILOT_ASSISTED_APPROVAL environment variable. In those runs nobody is around to answer a prompt, so a request the review won’t approve is denied, and the explanation is passed back to Copilot so it can try a different approach.
The flag has a catch that build engineers will want to check. Once enabled, it takes precedence over --allow-all-tools but leaves --allow-all-paths and --allow-all-urls alone, so pairing it with --allow-all or its alias --yolo can still leave path and URL access unrestricted. If enterprise settings block assisted permissions, the CLI writes a warning to standard error and keeps any separate --allow-all-tools option in force.
Where admins draw the line
Enterprise administrators can block Allow All while keeping Assisted available, or switch off Assisted on its own, through enterprise-managed settings. The relevant keys are permissions.disableBypassPermissionsMode: "disable" and permissions.disableAssistedPermissionsMode: true. Admins can also set the default mode for new sessions, and if that default is unavailable or prohibited by policy, the session starts with manual approval.
Security teams that use enterprise “ask” rules as a human checkpoint should know that in Copilot CLI, those rules for shell commands, file reads, file writes and URLs can be satisfied by model approval when a request is eligible for review, so they don’t always produce a prompt. Enterprise deny rules still apply.
Copilot is also one of the agents that already support Microsoft Execution Containers, the OS-level sandbox Microsoft made generally available on Windows 11 on Oct. 7. GitHub’s documentation also carries a warning. “The model can make mistakes and approve dangerous or unintended actions,” it says, adding that the feature “is not a substitute for sandboxing or access restrictions.”
from WebProNews https://ift.tt/KaFzTxY
No comments:
Post a Comment