Protect Data When Using MCP Tools

Protect Data When Using MCP Tools

MCP tools can connect Feluda to files, internal systems, online services, business records, and other information sources.

These connections can be useful, but they also create a data path that should be understood before sensitive information is used.

Protecting data means knowing:

• what information the tool receives;
• where the MCP server runs;
• whether another service is involved;
• what the tool is allowed to do;
• where credentials are stored;
• what activity is recorded; and
• how results are reviewed.

Use the smallest amount of information and access needed for the task.

Understand the complete data path

A Feluda task may involve several separate parts.

For example:

User Input
→ AI Model
→ MCP Tool
→ Connected Service
→ Tool Result
→ AI Response

Each step may process or receive information.

Review the complete path instead of looking only at the AI model.

A local model does not make the complete task local when it calls a remote MCP server.

Model location and tool location are different

The AI model and MCP server may run in different places.

A workflow may use:

• a local model and a local MCP server;
• a local model and a remote MCP server;
• a cloud model and a local MCP server; or
• a cloud model and a remote MCP server.

Each combination has a different data path.

Confirm both where the model runs and where the tool runs.

Local models

A local model runs on your own computer through a compatible provider such as Ollama or LM Studio.

Model processing can remain on the device when:

• the model is local;
• the source is local;
• the MCP server is local;
• the tool uses only local data; and
• the result remains local.

If the local model calls a remote tool, information required by that tool leaves the device.

Cloud models

A cloud model processes the information sent to its provider.

Before using one with MCP tools, review:

• which source text is sent to the model;
• whether the complete document is necessary;
• whether personal information can be removed;
• which MCP tool receives additional data;
• where the final result is stored; and
• whether the provider is approved for the task.

Use local models when local processing is required and the complete tool path can also remain local.

Local MCP servers

A local MCP server runs on your computer or an approved local network.

It may connect Feluda to:

• local files;
• local applications;
• internal services;
• local databases; or
• other on-device tools.

A local endpoint does not automatically make every connected source local.

Review whether the tool itself contacts another service.

Remote MCP servers

A remote MCP server runs outside your computer.

It may be operated by:

• your organisation;
• a software provider;
• a trusted third party;
• a hosted internal service; or
• another approved operator.

Information sent to its tools may leave your device.

Confirm where the server runs and what it does with the information.

Review the server owner

Before connecting an external MCP server, ask:

• Who operates it?
• Why is it needed?
• Who maintains it?
• Where is it hosted?
• Which tools does it expose?
• What information can those tools receive?
• Can the server store tool input or output?
• Does it use other services?
• What happens when the connection is removed?

Use servers from sources you understand and trust.

Review every tool separately

One MCP server may provide several tools.

Each tool may have different:

• input requirements;
• data access;
• permissions;
• destinations;
• actions;
• risks; and
• review needs.

A search tool and a delete tool should not be treated as equivalent.

Review tools individually before enabling them.

Read and write tools

A read tool retrieves or views information.

It may:

• search;
• list;
• retrieve;
• inspect;
• compare; or
• read a supported source.

A write tool creates, changes, sends, or removes information.

It may:

• update a record;
• create a task;
• save a file;
• send a message;
• change a status;
• create a note; or
• remove an item.

Write tools require more review because they can affect an external destination.

Use the least access required

Give the connection only the access needed for the task.

When supported, prefer:

• read-only access;
• limited accounts;
• approved sources;
• specific destinations;
• restricted records;
• narrow file paths;
• selected network locations; and
• separate test environments.

Broad access increases the effect of a wrong instruction or tool call.

Limit which tools are enabled

In Workbench, enable only the tools needed for the current conversation.

In Studio, enable only the tools required by that LLM step.

This helps:

• reduce accidental calls;
• limit data exposure;
• simplify Activity review;
• make model choices clearer; and
• prevent unrelated write actions.

Disable tools after testing when they are no longer needed.

Minimise the information sent

Give the tool only the information required for the action.

Before sending source content, ask:

• Does the tool need the complete document?
• Can names be removed?
• Can identifiers be shortened?
• Can one section be used instead of the full file?
• Can the task use a summary?
• Can sensitive fields be excluded?
• Can sample data be used during testing?

More information is not always better.

Remove unnecessary personal information

When the task involves personal information, remove fields that are not required.

For example, a status lookup may need:

• a reference number; and
• an approved account identifier.

It may not need:

• a home address;
• a personal phone number;
• private notes;
• a complete message history; or
• unrelated customer details.

Keep the tool input focused on the task.

Use sample data during testing

Test a new MCP server or tool with non-sensitive information.

Confirm:

• the server is reachable;
• authentication works;
• the tool appears;
• the selected model calls it correctly;
• the expected data is sent;
• the result has the expected format;
• the Activity log is understandable; and
• no unintended action occurs.

Move to real information only after the test is successful.

Protect credentials

MCP servers may require:

• access tokens;
• API keys;
• account credentials;
• private headers; or
• another authentication value.

Store these only in the intended protected settings.

Feluda uses protected operating-system storage for supported secrets and provider values.

The AI model should not need to see the raw credential.

Never place credentials in prompts

Do not paste credentials into:

• Workbench messages;
• Studio instructions;
• Input blocks;
• Journal entries;
• source documents;
• screenshots;
• support messages; or
• normal notes.

A prompt may be included in logs, history, or tool input.

Use protected settings instead.

Keep credentials separate by purpose

When possible, use separate credentials for:

• read-only access;
• approved write access;
• test environments;
• production environments;
• different teams; or
• different services.

This makes access easier to limit and revoke.

Use clear connection names so users know which account or environment a tool affects.

Review credential age and ownership

A connection can remain active long after the original setup.

Review:

• who owns the account;
• who can rotate the credential;
• whether it has expired;
• whether the original user still needs access;
• whether permissions have changed; and
• whether the connection is still required.

Replace or revoke credentials when responsibilities change.

Review Workbench Activity

The Workbench Activity log shows tool activity.

Review:

• which tool was called;
• what input was passed;
• what output returned;
• whether a warning appeared;
• whether an error occurred; and
• whether repeated calls were made.

This helps you confirm what information left the conversation and what came back.

Do not rely only on the model's final answer.

Review RunFlows output

In a workflow, use RunFlows output to review:

• starting input;
• intermediate results;
• tool calls;
• tool input;
• tool output;
• warnings;
• errors;
• selected branches; and
• final output.

Add Emit blocks when the raw tool result needs to be visible during testing.

Understand logs

Activity and workflow output can contain:

• search terms;
• identifiers;
• file paths;
• tool parameters;
• returned records;
• warnings; and
• error details.

Avoid sending unnecessary sensitive information simply because logs are useful for troubleshooting.

Use approved retention and access practices for important activity records.

Review flow permissions

Studio workflows can include permission controls.

If a tool uses a network address, file path, or port, review the workflow's Permissions panel.

Depending on the workflow, this may include:

• URL allowlists or denylists;
• IP allowlists or denylists;
• path allowlists or denylists;
• port allowlists or denylists; and
• other visible restrictions.

Allow only the destinations required for the approved task.

URL restrictions

URL rules can control which online locations a workflow tool may access.

Use them to limit the workflow to approved sources.

Before allowing a URL, confirm:

• the domain;
• the exact service;
• the path when relevant;
• whether redirects are involved;
• whether user-provided URLs are allowed; and
• whether the source is trusted.

Avoid broad rules when a specific domain or path is sufficient.

IP restrictions

IP rules can limit which network addresses a tool may reach.

Use them when a workflow should connect only to:

• a local service;
• an internal server;
• an approved host; or
• a defined network location.

Confirm that the address belongs to the intended service.

Do not allow large address ranges without a clear need.

Path restrictions

Path rules can limit file access.

Use them to restrict a tool to:

• one folder;
• one project directory;
• approved input files;
• a safe output folder; or
• another defined location.

Avoid giving a workflow access to the complete filesystem when one folder is enough.

Port restrictions

Port rules can limit which local or remote services a workflow may contact.

Confirm:

• the intended service;
• the correct port;
• whether the port changed;
• whether another application uses it; and
• whether the connection is local or remote.

Allow only the port required for the approved server.

Account permissions

The connected account may control which:

• records;
• files;
• projects;
• messages;
• customers;
• workspaces;
• actions; or
• destinations

the tool can access.

Use an account with limited access when possible.

Avoid personal administrator accounts for routine workflow tasks.

Review write destinations

Before enabling a write tool, confirm:

• the exact destination;
• the account;
• the workspace;
• the record;
• the file path;
• the recipient;
• the content;
• whether the action can be reversed; and
• whether approval is required.

A safe tool connection can still cause harm when the destination is wrong.

Use a draft-first process

For an important write action, ask the model to prepare the proposed change first.

For example:

Prepare the 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 submit the update yet.

Review the draft.

Request the final action only after confirming the destination and content.

Confirm external actions

After a write tool runs, inspect the connected service.

Check:

• the created record;
• the updated field;
• the saved file;
• the message recipient;
• the task;
• the note; or
• the changed status.

A successful tool call does not prove that the correct information or destination was used.

Avoid duplicate actions

A timeout or delayed confirmation may make a successful write look like a failure.

Before retrying:

1. review Activity or RunFlows output;
2. inspect the external destination;
3. compare timestamps;
4. confirm whether the item already exists; and
5. retry only when the first action did not complete.

This prevents duplicate messages, files, tasks, notes, and records.

Separate test and production access

Use separate connections when test and live systems must remain distinct.

Name them clearly.

For example:

• Customer Records MCP — Test;
• Customer Records MCP — Production;
• Project Service MCP — Read Only; or
• Project Service MCP — Approved Writes.

Confirm the environment before every write action.

Protect scheduled workflows

A scheduled workflow may call an MCP tool when no one is watching the live run.

Before scheduling:

• test the tool manually;
• confirm the data path;
• review authentication;
• use narrow permissions;
• handle empty results;
• make errors visible;
• prevent duplicate writes;
• confirm the destination;
• avoid overlapping runs; and
• assign a reviewer.

Pause the schedule when the server, account, or trust level changes.

Review scheduled results

After a scheduled run, check:

• whether the correct tool was used;
• what input it received;
• what output it returned;
• whether sensitive fields were included;
• whether an error occurred;
• whether a write action completed;
• whether the destination is correct; and
• whether a duplicate was created.

Automatic execution does not remove the need for review.

Handle remote service changes

A remote service may change:

• its endpoint;
• authentication;
• tool names;
• permissions;
• result format;
• data handling;
• storage practices; or
• availability.

Pause dependent automation after an important change.

Re-test the connection and review the new data path before resuming.

Remove unused connections

Remove or disconnect an MCP server when:

• it is no longer needed;
• its owner is unknown;
• it is no longer trusted;
• the service was retired;
• another approved server replaced it;
• repeated failures will not be repaired; or
• no workflow depends on it.

Before removal, identify dependent Workbench tasks, Studio workflows, and schedules.

Revoke access when appropriate

Removing a connection from Feluda may not revoke the credential at the external service.

When access should end:

• remove the connection;
• revoke or rotate the external credential;
• review recent activity;
• inspect important write actions;
• update dependent workflows; and
• confirm that the server can no longer be used.

Follow the server owner's access-removal process.

Respond to a trust concern

If you no longer trust a server:

1. stop using its tools;
2. pause dependent schedules;
3. disable or remove the connection;
4. revoke credentials when appropriate;
5. review recent Activity;
6. inspect important external actions;
7. identify information that may have been sent; and
8. use an approved alternative only after testing.

Do not continue using the server while the concern remains unresolved.

Keep human review for high-impact tasks

Human review is especially important when MCP tools affect:

• customers;
• employees;
• money;
• contracts;
• legal rights;
• health;
• safety;
• security;
• access to services; or
• important business records.

The model and tool can prepare or perform a supported step.

A person should remain responsible for important decisions and approvals.

A practical data-protection routine

Use this process before regular use:

1. Identify the MCP server owner.
2. Confirm where the server runs.
3. Review every tool separately.
4. Map the model, tool, service, and destination.
5. Remove unnecessary input.
6. Store credentials only in protected settings.
7. Use the least access required.
8. Enable only the needed tools.
9. Test with non-sensitive data.
10. Review Workbench Activity or RunFlows output.
11. Confirm write actions at their destination.
12. Add narrow workflow permissions.
13. Protect scheduled automation.
14. review the connection regularly.
15. Remove and revoke access when it is no longer needed.

MCP tools can extend Feluda with valuable connected capabilities.

Clear data paths, limited permissions, and careful review keep those capabilities under control.