Understand MCP Tool Permissions
MCP tool permissions control what a connected tool is allowed to access or change.
Permissions can limit:
- whether a tool reads or writes information;
- which account it uses;
- which records it can access;
- which URLs it may contact;
- which IP addresses it may reach;
- which file paths it may use;
- which ports it may connect to; and
- which external destinations it may affect.
Use the narrowest permission that still allows the approved task to work.
Why permissions matter
An MCP tool can connect Feluda to files, services, records, and external systems.
A permission boundary helps prevent the tool from reaching more than it needs.
For example, a workflow that only reads one project folder should not need access to the entire filesystem.
A tool that only searches customer records should not automatically receive permission to update or delete them.
Read and write permissions
The first distinction is whether a tool reads information or changes it.
| Permission type | What it allows |
|---|---|
| Read | Search, list, retrieve, inspect, or view information |
| Write | Create, update, send, save, move, or remove information |
Read access is usually safer for initial testing.
Write access requires stronger review because it can affect a real destination.
Use read-only access when possible
Prefer read-only access when the task only needs to:
- search;
- retrieve;
- compare;
- inspect;
- list;
- review; or
- summarise information.
Do not grant write access to a connection that only performs lookups.
This reduces the effect of an incorrect instruction or unexpected tool call.
Review write access carefully
A write tool may:
- create a task;
- update a record;
- save a file;
- send a message;
- change a status;
- create a note; or
- remove an item.
Before allowing write access, confirm:
- the exact action;
- the destination;
- the account;
- the record or file;
- whether the action can be reversed;
- whether a person must approve it; and
- whether a safer draft-only process is possible.
Use a draft-first process
For important write actions, ask the workflow or model to prepare the change before submitting it.
For example:
Prepare the proposed customer-record update.
Show:
* the record that would be changed;
* the fields that would be updated;
* the new values; and
* the reason for the change.
Do not perform the update yet.
Review the proposal.
Allow the final action only after confirming the destination and content.
Account permissions
The account used by the MCP connection may control access to:
- records;
- files;
- projects;
- messages;
- customers;
- workspaces;
- actions; or
- connected services.
Use a limited account when possible.
Avoid using a personal administrator account for routine workflow tasks.
Separate accounts by purpose
Separate accounts may be useful for:
- read-only access;
- approved write access;
- test environments;
- production environments;
- different teams; or
- different projects.
Use clear connection names.
For example:
- Customer Records MCP — Read Only;
- Customer Records MCP — Approved Writes;
- Project Service MCP — Test; or
- Project Service MCP — Production.
URL permissions
URL rules control which online locations a workflow tool may access.
A URL rule may allow or block:
- a complete domain;
- a subdomain;
- a specific path;
- an API endpoint; or
- another online destination.
Use URL restrictions to keep the workflow focused on approved services.
URL allowlists
An allowlist identifies locations the workflow may access.
For example, a workflow may be allowed to use only:
https://knowledge.example.com
Or a specific API path:
https://api.example.com/projects
A narrow allowlist is easier to understand than broad internet access.
URL denylists
A denylist identifies locations the workflow must not access.
Denylists can block known unwanted destinations.
However, a denylist alone may still leave many other locations available.
For sensitive workflows, prefer a narrow allowlist when possible.
Review URL redirects
A permitted URL may redirect to another location.
Before approving a source, confirm:
- the final destination;
- whether redirects are expected;
- whether authentication is passed safely;
- whether user-provided URLs are allowed; and
- whether the redirected domain is trusted.
Do not assume the visible starting URL is the only destination involved.
IP address permissions
IP rules control which network addresses a tool may reach.
These can be useful when the workflow should connect only to:
- a local service;
- an internal server;
- an approved host;
- a fixed business system; or
- another defined network location.
Confirm that the IP address belongs to the intended service.
IP allowlists
An IP allowlist gives access only to approved addresses or ranges.
Keep the range as small as practical.
Avoid allowing a large network range when one host is enough.
For example, a local workflow may need access only to:
127.0.0.1
Or one approved internal server.
IP denylists
An IP denylist blocks specific addresses or ranges.
Use it to prevent access to known unwanted locations.
As with URL rules, a denylist may leave many other addresses available.
Use an allowlist when the task has a clearly defined destination.
Localhost access
A tool may connect to a service running on the same computer.
Common local addresses include:
localhost;127.0.0.1; or- another configured local address.
Confirm:
- which service uses the address;
- which port it uses;
- whether the process is running; and
- whether another application could use the same port.
Local access is not automatically safe if the wrong local service is reached.
File-path permissions
Path rules control which files or folders a tool may access.
Use them to limit a workflow to:
- one project folder;
- approved input files;
- a safe output directory;
- a document collection; or
- another specific location.
Avoid giving the workflow access to the complete filesystem when one folder is enough.
Path allowlists
A path allowlist gives access only to approved folders or files.
For example:
/home/user/projects/atlas/reports
Or:
C:\Users\Name\Documents\Feluda\Inputs
Use the smallest useful folder boundary.
Keep input and output folders separate when that improves control.
Path denylists
A path denylist blocks specific files or folders.
Use it to prevent access to:
- credential folders;
- system files;
- unrelated projects;
- private user data; or
- protected records.
A denylist can add protection, but a narrow allowlist is usually clearer.
Input and output folders
Separate input and output folders when possible.
For example:
Input:
/projects/atlas/source
Output:
/projects/atlas/results
This makes it easier to understand:
- what the workflow may read;
- where it may write;
- which files are original; and
- which files were created by automation.
Port permissions
A port identifies a service on a computer or server.
Port rules can limit which services a tool may contact.
For example, a local MCP server or model runner may use one known port.
Allow only the port required for the approved task.
Review the service behind the port
Before allowing a port, confirm:
- which application uses it;
- whether the service is local or remote;
- whether the port is fixed;
- whether another process can take it;
- whether authentication is required; and
- whether the service is trusted.
A port number alone does not explain what service is running there.
Avoid broad port ranges
A broad port range may expose services the workflow does not need.
Prefer one required port when possible.
Review the rule again if the service changes its port.
Do not open additional ports only because a connection test failed.
Source and destination permissions
A workflow may read from one place and write to another.
Review both sides.
For example:
Read:
Approved project folder
Write:
Project report folder
Or:
Read:
Customer record
Write:
Review queue
A safe source does not guarantee a safe destination.
Permission inheritance
A tool may depend on more than one permission layer.
These may include:
- the MCP server connection;
- the connected account;
- the external service;
- the workflow Permissions panel;
- the local operating system;
- file ownership;
- network rules; and
- the selected tool.
A failure may come from any one of these layers.
Workflow Permissions panel
In Studio, review the flow's Permissions panel when a tool reports an access error.
Depending on the workflow, you may see controls for:
- URLs;
- IP addresses;
- file paths;
- ports; and
- other visible restrictions.
Compare the blocked action with the approved source or destination.
Update only the rule required for the intended task.
Do not remove all restrictions
A permission error does not automatically mean every restriction should be removed.
First confirm:
- the tool is correct;
- the source is correct;
- the destination is correct;
- the input is valid;
- the server is trusted; and
- the task is approved.
Then change the narrowest relevant rule.
Test permissions with sample data
Use non-sensitive sample information after changing permissions.
Confirm that:
- the intended source is accessible;
- unrelated sources remain unavailable;
- the correct destination can be used;
- blocked destinations remain blocked;
- write actions require the intended approval; and
- the Activity log shows the expected action.
Do not begin with real confidential data.
Test allowed access
Test one approved source or destination.
For example:
- one allowed URL;
- one approved IP address;
- one permitted folder; or
- one required port.
Confirm that the tool completes the task normally.
Test blocked access
When safe and appropriate, confirm that an unapproved source remains unavailable.
The workflow should return a clear permission error.
It should not silently use another destination or invent a result.
Review permission errors
A permission error may indicate:
- the URL is not allowed;
- the IP address is blocked;
- the file path is outside the permitted folder;
- the port is not allowed;
- the account lacks access;
- the action requires write permission;
- the external service blocks the account; or
- the workflow uses the wrong destination.
Read the complete error before editing the rules.
Separate no access from no result
These are different outcomes.
No access:
The tool was not permitted to reach the source.
No result:
The tool reached the source but found nothing.
Use different messages for these situations.
This helps users know whether to change permissions or improve the search input.
Review Workbench Activity
In Workbench, the Activity log can show:
- which tool was called;
- what input it received;
- what output it returned;
- whether access was denied;
- whether a warning appeared; and
- whether an error occurred.
Use Activity to confirm whether the permission blocked the intended action.
Review RunFlows output
In a workflow, review:
- the starting input;
- intermediate output;
- tool input;
- tool output;
- permission errors;
- selected branches; and
- the final message.
Add an Emit block when the raw tool result needs to be visible during testing.
Protect sensitive destinations
Some destinations require stronger limits.
Examples include:
- customer records;
- employee files;
- contracts;
- financial information;
- security systems;
- production services;
- health information; or
- access-control systems.
Use narrow permissions and human review for high-impact actions.
Keep approval separate from access
Permission to perform an action does not mean the action is approved.
A connection may technically allow a record update.
The workflow should still require human review when the change has important consequences.
Access and approval are different controls.
Scheduled workflow permissions
Scheduled workflows may use permissions without a person watching the live run.
Before scheduling:
- test every allowed source;
- test every write destination;
- confirm blocked locations remain blocked;
- make permission errors visible;
- prevent duplicate writes;
- review runtime;
- avoid overlapping runs; and
- assign a reviewer.
Pause the schedule when permission requirements change.
Review permissions after a server update
A server update may change:
- tool names;
- endpoints;
- ports;
- paths;
- account requirements;
- result formats; or
- write behaviour.
Re-test the permissions after an important update.
Pause dependent schedules until the workflow works normally again.
Review permissions after an account change
A new account or credential may have different access.
Confirm:
- read permissions;
- write permissions;
- record scope;
- project scope;
- file access;
- message access;
- destination access; and
- administrative rights.
Do not assume the replacement account has the same boundaries.
Review permissions regularly
Permissions should be reviewed when:
- a project ends;
- a team changes;
- an employee leaves;
- a server changes;
- a workflow changes;
- a tool is removed;
- a new destination is added;
- repeated access errors appear; or
- a connection is no longer needed.
Remove access that no longer supports an active task.
Remove unused write access
A connection may still have write access after the workflow becomes read-only.
Review old permissions.
Remove unnecessary ability to:
- create;
- update;
- send;
- delete;
- move; or
- overwrite information.
Keep only the permissions required by current workflows.
Document the reason for access
For important connections, record:
- why the permission exists;
- which workflow uses it;
- which source or destination it covers;
- who approved it;
- who owns the connection; and
- when it should be reviewed.
This makes later maintenance easier.
A practical permission review
Use this process:
- Identify the MCP server and tool.
- Decide whether the tool needs read or write access.
- Review the connected account.
- List the required URLs.
- List the required IP addresses.
- List the required file paths.
- List the required ports.
- Confirm the source and destination.
- Apply the narrowest rules.
- Test with non-sensitive data.
- Review Workbench Activity or RunFlows output.
- Confirm blocked locations remain blocked.
- Add human review for important write actions.
- Pause schedules before changing permissions.
- Remove access when it is no longer needed.
MCP permissions should make the approved task possible without exposing unrelated systems or information.