Editorial status: Source-researched draft. Confirm current product controls and commercial terms in the linked official documentation before publication.
Quick answer
GitHub documents permission prompts for local agentic execution and an ephemeral, firewalled environment for cloud-agent sessions. Neither removes the need to review generated code, dependencies, secrets, and external integrations.
A sensible starting point
- Use least-privilege repository access
- scrutinize destructive CLI commands
- require tests, code review, secret scanning, and dependency analysis before merge.
The safest first task is small, reversible, and contained in a clean Git branch or disposable repository. Do not begin with production credentials, customer data, deployment access, or a repository containing unrelated secrets.
Security questions to answer
Before adoption, verify what the agent can read, which commands it can execute, whether outbound network access is restricted, how credentials reach tools, and which actions require approval. Check whether local, editor, command-line, and cloud modes use different security boundaries.
Also identify the recovery path. Git helps recover file changes, but it does not reverse a leaked credential, a message sent to a third party, a deployment, or a purchase. Those external actions should remain separately permissioned and auditable.
How to evaluate it fairly
Use the same representative task for every candidate. Record setup time, completion quality, manual corrections, test results, network destinations, requested permissions, and total model or platform usage. Avoid declaring a winner from vendor demos or a single benchmark.
Bottom line
Choose the smallest permission set that completes the real workflow. Expand access only after a denied action demonstrates a legitimate need, then document the exception so other users do not have to guess.