AI coding assistants are becoming capable of doing much more than generating code. In agent mode, GitHub Copilot can inspect project files, search a repository, edit code, execute commands, run tests, and work through several steps to complete a task.
That creates an important engineering question: when should Copilot perform an action automatically, and when should it ask the developer first?
GitHub's current Copilot tooling uses permission and approval mechanisms to make that distinction. In JetBrains, Copilot 1.18.0 introduced assisted approvals in public preview, where lower-risk tool calls can receive automatic approval while higher-risk actions continue to require a decision from the developer.
Understanding how this works is useful because approval behavior affects both developer productivity and the safety of agentic workflows.
What Is a Tool Call?
A tool call is an action an AI agent performs through a development tool rather than simply returning text.
For example, if you ask:
Find the authentication service and add tests for
expired access tokens.
Copilot may need to perform several operations:
Search repository
|
v
Read authentication files
|
v
Read existing tests
|
v
Edit source code
|
v
Edit tests
|
v
Run tests
|
v
Inspect results
Each operation is a potential tool call.
The important distinction is between:
AI suggests an action
and:
AI actually performs the action
Once the agent can perform the action, permissions become part of the development workflow.
Why Copilot Needs an Approval System
Not every operation has the same level of risk.
Reading a source file is different from deleting a file.
Running a unit test is different from executing an unfamiliar shell command.
Searching a repository is different from changing a project configuration.
A simplified model looks like this:
Tool Request
|
v
Permission Check
|
+------------+------------+
| |
Lower Risk Higher Risk
| |
v v
Automatic Approval Ask Developer
| |
+------------+------------+
|
v
Tool Executes
The actual permission model can be more detailed, but this captures the central idea.
Assisted Approvals in JetBrains
GitHub Copilot for JetBrains 1.18.0 introduced AI-assisted tool approvals in public preview.
GitHub describes assisted approvals as a way to reduce approval interruptions for lower-risk tool calls while continuing to prompt developers for higher-risk actions.
This is particularly useful during longer agent sessions.
Without some form of automation, an agent performing routine repository exploration could repeatedly interrupt the developer.
With assisted approvals:
Read file
|
v
Low-risk
|
v
Continue automatically
But an operation requiring greater trust can still stop for confirmation.
This creates a balance between autonomy and developer oversight.
Risk Is More Than the Tool Name
One important point is that the risk of an operation is not necessarily determined only by the name of the tool.
Consider a shell command:
npm test
This is normally a development operation.
Now compare it with:
rm -rf build
Both are shell commands, but their potential effects are different.
Similarly, writing to:
src/UserService.cs
is different from modifying:
production-config.json
The context and parameters of a tool call matter.
GitHub's Copilot CLI documentation describes permission handling in terms of specific tools and command patterns, including the ability to allow or deny particular operations.
A Simple Risk Model
Developers can think about agent operations in three broad categories.
Category | Examples | Typical Handling |
|---|---|---|
Read | Search files, inspect source, read test results | Lower interruption |
Development write | Edit source, update tests | Review required |
Sensitive operation | Delete files, external access, risky commands | Stronger approval |
This is not a universal classification for every environment.
The actual behavior depends on the Copilot product, IDE, configured permissions, organization policies, tool, and operation.
The model is nevertheless useful when designing an agent workflow.
How an Agent Session Can Progress
Consider this request:
Fix the failing UserService tests and update the
implementation if necessary.
Copilot may need to:
Find
UserService.Find the failing tests.
Read the implementation.
Inspect test output.
Modify the implementation.
Modify tests if necessary.
Run the tests.
Inspect the results.
Make another correction.
The sequence could look like:
Developer Request
|
v
Repository Search
|
v
Read Source
|
v
Read Tests
|
v
Modify Code
|
v
Run Tests
|
v
Inspect Result
|
v
Additional Change
The approval system determines where the developer needs to intervene.
Approval and Agent Mode
GitHub's IDE documentation describes Agent mode as a mode where Copilot can autonomously work toward a development task, determine which files need changes, offer code changes and terminal commands, and iterate when issues are encountered.
That is fundamentally different from a simple question-and-answer workflow.
In Ask mode, the developer might request:
Why does this method return null?
In Agent mode, the request might be:
Find why this method returns null,
fix the problem, and run the relevant tests.
The second task requires tool access.
Therefore, approval behavior becomes an important part of the agent's operating model.
Tool Approval vs Code Review
These two concepts are often confused.
Tool approval answers:
Should the agent perform this operation?
Code review answers:
Is the resulting change correct?
They are not interchangeable.
For example, you may approve:
Edit UserService.cs
because the requested task requires it.
The resulting implementation could still be wrong.
It might:
Break an existing behavior
Introduce a race condition
Change an API contract
Reduce error handling
Break a test
Introduce a security issue
Approval only controls the action.
It does not validate the engineering result.
Why Developers Should Review the Final Diff
Git remains one of the most useful safety mechanisms for AI-assisted development.
After an agent completes a task, inspect:
git status
Then review:
git diff
Look for:
Unexpected files
Unrelated changes
Configuration modifications
Dependency changes
Test changes
Generated files
Removed code
New commands or scripts
For example, if you requested a change to:
UserService.cs
but the agent also modified:
appsettings.json
DatabaseMigration.cs
package.json
you should understand why before accepting the change.
Persistent Permissions
Copilot can also support permissions that persist beyond a single approval.
In Copilot CLI, for example, permissions can be saved for a repository or working directory. GitHub documents persisted permissions through permissions-config.json, with separate handling for permanently approved URLs.
This can be convenient.
For example, repeatedly approving a harmless development command can become unnecessary.
However, persistent permission changes the security boundary.
Instead of:
Allow once
you are effectively saying:
Allow this type of operation in this scope
That decision should therefore be made carefully.
Session-Level Approval vs Persistent Approval
The distinction can be summarized as follows:
Approval Type | Scope | Benefit | Consideration |
|---|---|---|---|
One-time | Current operation | Maximum control | More interruptions |
Session-level | Current session | Less repetition | Applies to later calls |
Persistent | Future sessions in a scope | Convenient | Longer-lasting permission |
Deny | Defined operation | Strong restriction | Agent may need another approach |
GitHub's CLI documentation also notes that deny rules take precedence over allow rules.
That precedence is important when multiple permission rules exist.
Allow and Deny Rules
Permission systems become more useful when developers can express specific policies.
For example, conceptually:
Allow:
read
Ask:
write
Deny:
destructive command
This is more controlled than:
Allow everything
GitHub documents tool restrictions that can limit which tools are available to the model and separate controls that allow or deny specific tools. Deny rules take precedence over allow rules.
This allows teams to create more precise boundaries.
Why "Allow Everything" Is Different
GitHub has also provided broader auto-approval options.
For example, GitHub's JetBrains documentation describes a global auto-approve capability that can approve all tool calls across workspaces, including potentially destructive actions such as file edits and terminal commands. GitHub explicitly warns that this setting should only be enabled when the associated risks are understood.
The distinction is important:
Automatic approval for selected safe operations
is not the same as:
Automatic approval for every operation
The second removes more safety checks.
MCP Tools and Approval
Model Context Protocol, or MCP, expands what an AI assistant can interact with.
For example, the GitHub MCP Server can expose repository-related actions inside Copilot Chat in JetBrains IDEs. Developers can use it to retrieve repository information and perform supported GitHub operations.
This creates another permission boundary.
Consider:
Agent
|
v
MCP Server
|
+---- Read repository
|
+---- List issues
|
+---- Create issue
|
+---- Modify repository resource
These operations should not automatically be treated as equivalent.
A read-only action may be appropriate for routine automation, while a write operation may deserve explicit confirmation.
Per-Tool MCP Controls
GitHub has also introduced controls for MCP tools in JetBrains.
Earlier JetBrains updates added MCP auto-approval configuration at both server and tool level.
This allows developers to think in terms of:
MCP Server
|
+---- Tool A -> Allow
|
+---- Tool B -> Ask
|
+---- Tool C -> Deny
That is more precise than treating the entire MCP server as one indivisible permission.
Enterprise Policies Add Another Layer
In an enterprise environment, individual developers may not be the only people deciding how Copilot behaves.
GitHub provides enterprise-managed settings for Copilot, including permission controls and the ability to prevent bypass-style permission modes.
GitHub also introduced enterprise-managed settings for Copilot in JetBrains, including controls for MCP server access and permission modes.
The resulting model can look like:
Enterprise Policy
|
v
IDE Configuration
|
v
User Settings
|
v
Agent Tool Request
|
v
Permission Decision
A developer may therefore encounter a permission rule that cannot be overridden locally.
Why Deny Rules Are Important
Allow rules answer:
What can the agent do?
Ask rules answer:
What requires human confirmation?
Deny rules answer:
What can the agent never do?
That last category is particularly useful for sensitive environments.
For example, an organization may decide that certain operations should never be performed automatically by an AI agent.
GitHub's managed permission model supports deny, ask, and allow rules, with deny taking precedence.
This gives administrators a stronger control mechanism than relying only on developer behavior.
A Practical Example: Database Migration
Consider this request:
Add a CreatedAt column to the User entity
and update the application.
An agent might identify the need to:
Modify entity
|
v
Modify configuration
|
v
Create migration
|
v
Run tests
The dangerous assumption would be:
Create migration = Apply migration to database
Those are different operations.
Creating a migration is a source-code change.
Applying it to a real database can be an external operation with potentially significant consequences.
A well-controlled workflow separates them:
Create Migration
|
v
Review Migration
|
v
Run Tests
|
v
Explicit Decision
|
v
Apply Where Appropriate
The same principle applies to infrastructure, deployment, cloud resources, and production services.
A Practical Example: Dependency Updates
Suppose the agent says:
I need to update the JSON library.
That might involve:
package.json
package-lock.json
or:
.csproj
packages.lock.json
Depending on the ecosystem.
Before approving the change, consider:
Why is the dependency required?
Is the version compatible?
Did the lock file change?
Were unrelated packages updated?
Are tests still passing?
The permission decision is only the first step.
A Practical Example: Running Tests
Running a local unit-test command is often part of normal agent work:
dotnet test
The agent can use the result to identify failures and iterate.
For example:
Run tests
|
v
3 failures
|
v
Inspect failures
|
v
Modify implementation
|
v
Run tests again
This is one of the areas where reducing unnecessary approval interruptions can make agent workflows more practical.
The developer should still review unexpected commands or test operations, particularly in unusual environments.
How Developers Can Think About Approval Decisions
A useful mental model is:
Read
Ask:
Is the agent only observing?
If yes, the operation may be suitable for more automation.
Write
Ask:
What files will change?
Review the result even if the write itself is approved.
Execute
Ask:
What will this command actually do?
Pay particular attention to destructive or externally connected operations.
External Access
Ask:
What system is being accessed, and what permissions does the tool have?
This is especially important for MCP tools and network operations.
Common Mistakes
Approving Based Only on the Tool Name
A familiar tool can still be used with risky arguments.
Giving Persistent Permissions Without Checking Scope
A saved permission may apply to future operations within the configured scope.
Treating Tests as Completely Harmless
Most test commands are routine, but custom scripts can perform additional operations.
Ignoring MCP Capabilities
An MCP server may provide actions beyond simple information retrieval.
Using Global Auto-Approval Without Understanding the Risk
Global approval can include operations such as file edits and terminal commands.
Skipping Final Review
An approved operation can still create incorrect code.
Troubleshooting Unexpected Approval Prompts
If Copilot repeatedly asks for approval, investigate the permission configuration before changing it.
Check:
What tool is being requested?
What operation is being performed?
Is the tool covered by an existing allow rule?
Is there a deny rule?
Is an organization policy controlling the behavior?
Is the permission persistent or session-specific?
Is the operation considered higher risk?
In enterprise environments, a managed rule may intentionally require approval or deny an operation.
Do not assume that changing a local setting is always the correct solution.
Best Practices for Teams
Start With Conservative Permissions
Allow routine development operations while keeping sensitive operations behind explicit approval.
Separate Development and Production
Do not give a local coding agent unnecessary access to production credentials or systems.
Prefer Narrow Permissions
A permission for one tool or command is easier to reason about than unrestricted access.
Review Persistent Permissions
Periodically remove permissions that are no longer necessary.
Use Enterprise Policies for Shared Guardrails
Central controls provide consistency across development teams.
Keep Code Review Independent
Do not treat an approval decision as a replacement for source-code review.
Test Every Meaningful Change
The compiler and test suite remain essential validation tools.
Advantages
Fewer Unnecessary Interruptions
Low-risk actions can proceed without repeatedly asking the developer.
Better Agent Productivity
Long-running tasks can progress more naturally.
Granular Control
Tool, command, and MCP-level permissions can provide more precise boundaries.
Enterprise Governance
Organizations can define policies for allowed, denied, and approval-required operations.
Better Developer Visibility
Approval prompts provide an opportunity to inspect potentially important actions before they occur.
Disadvantages and Limitations
Permission Systems Can Be Complex
Multiple layers can make troubleshooting difficult.
Auto-Approval Can Increase Risk
The broader the automatic permission, the greater the potential impact of an unexpected action.
Policies May Differ Between Environments
A developer's local behavior may differ from an enterprise-managed environment.
Approval Does Not Guarantee Correctness
A permitted action can still produce defective code.
MCP Expands the Permission Surface
External tools can introduce capabilities beyond ordinary source-code editing.
A Recommended Workflow
For most development tasks, the following pattern is practical:
Define the task narrowly.
Allow the agent to inspect relevant project files.
Let routine read operations proceed with appropriate automation.
Review write operations when they affect important code or configuration.
Inspect commands before approving unfamiliar or sensitive operations.
Review MCP operations separately from local file operations.
Check the final Git diff.
Run targeted tests.
Run broader validation when necessary.
Commit only after reviewing the complete change.
This keeps the agent productive without turning every development session into an unrestricted automation environment.
What Developers Should Remember
GitHub Copilot does not need every tool call to be treated identically.
The useful distinction is between what the agent is doing, what it can affect, and how much trust that operation deserves.
A repository search and a production deployment command should not have the same approval requirements.
Likewise, reading an issue through an MCP tool and creating or modifying an external resource should be treated differently.
The goal of an effective permission model is therefore not to eliminate approvals.
It is to put approvals where they provide meaningful protection while allowing routine development work to continue without unnecessary interruption.
Summary
GitHub Copilot's tool approval model is becoming an important part of agentic software development. In JetBrains, assisted approvals are designed to reduce interruptions for lower-risk tool calls while keeping higher-risk decisions with the developer.
The broader Copilot permission model can also distinguish between allowed, approval-required, and denied operations, while MCP-specific controls and enterprise policies add additional layers of governance.
For developers, the practical approach is straightforward: automate routine operations, review meaningful changes, restrict sensitive capabilities, and keep code validation separate from tool approval.
As AI agents gain more ability to interact with development environments, understanding permission boundaries becomes an essential part of using them safely and effectively.
Join the conversation! Your thoughts help the community grow.