Audit MCP Server Access
An MCP access audit is a structured review of who and what can use a connected server.
The audit should confirm:
- who owns the server;
- which account or credential it uses;
- which tools it provides;
- which tools can read or write;
- which sources and destinations are accessible;
- which Workbench tasks use it;
- which Studio workflows depend on it;
- which schedules call it;
- which external actions it can perform; and
- whether every permission is still needed.
The goal is not only to confirm that the connection works.
The goal is to confirm that access remains necessary, limited, understood, and reviewable.
Why access audits matter
MCP access can expand over time.
A server may gain:
- more tools;
- broader account permissions;
- new source access;
- new destinations;
- additional workflows;
- new scheduled tasks;
- stronger write capabilities; or
- more users.
Without regular review, old access may remain after the original need has ended.
Audit the complete access path
Review the full path:
Feluda
→ AI Model
→ MCP Server
→ Connected Account
→ Source or Destination
→ Tool Result or External Action
Each layer can introduce access.
A narrow Feluda workflow can still rely on an account with broad rights.
A read-only prompt can still have a write-capable tool enabled.
Define the audit scope
Decide whether the audit covers:
- one MCP server;
- one project;
- one workflow;
- one account;
- one team;
- all production servers;
- all local servers; or
- every connected MCP service.
Record the scope before beginning.
Assign an audit owner
One person or team should coordinate the review.
The owner should know:
- why the server exists;
- who operates it;
- which account it uses;
- which tools it provides;
- which workflows depend on it;
- which schedules use it;
- where permissions are managed;
- who can approve changes; and
- how access can be removed.
Gather the server record
For each server, record:
- server name;
- local or remote location;
- endpoint;
- owner;
- service operator;
- account owner;
- authentication method;
- expected tools;
- connected sources;
- connected destinations;
- dependent workflows;
- dependent schedules;
- last successful test; and
- last access review.
Do not record raw passwords, keys, tokens, or private headers.
Open MCP Servers
In Feluda, open MCP Servers from the sidebar.
Review:
- server name;
- endpoint;
- connection state;
- authentication state;
- discovered tools;
- warnings; and
- errors.
Confirm that the visible connection matches the server record.
Confirm the server owner
Ask:
- Who operates the server?
- Who maintains it?
- Who approves updates?
- Who handles outages?
- Who can change the endpoint?
- Who can add or remove tools?
- Who can revoke access?
- Who should be contacted during an incident?
An unclear owner is an audit finding.
Confirm local or remote location
Determine whether the server runs:
- on the same computer;
- on another approved local-network device;
- on an internal organisational service;
- on a remote provider;
- on a hosted cloud service; or
- through another external operator.
Location affects privacy, availability, maintenance, and recovery.
Confirm the connected account
Identify the account the MCP server uses.
Record:
- service;
- account name;
- account owner;
- environment;
- workspace;
- project scope;
- read access;
- write access;
- administrative rights; and
- expiry or review date.
Avoid shared administrator accounts for routine tasks when a limited account is available.
Review account necessity
Ask:
- Is this account still needed?
- Does the same workflow need every permission?
- Could a read-only account replace it?
- Could a project-specific account be used?
- Could test and production accounts be separated?
- Does the account belong to an active owner?
- Is the account used by any unrelated process?
Remove access that is no longer required.
Review authentication
Confirm the authentication method.
It may use:
- an API key;
- an access token;
- an account sign-in;
- a protected header;
- a database credential;
- operating-system access; or
- another supported method.
Private values should remain in Feluda's protected settings and the operating system's secure credential store.
Review credential ownership
Record only:
- credential purpose;
- service;
- account owner;
- permission scope;
- expiry process;
- rotation owner; and
- revocation method.
Do not place the secret value in the audit record.
Review credential age
Ask:
- When was the credential created?
- When was it last rotated?
- Does it expire?
- Has the account owner changed?
- Has the server changed?
- Has the provider changed?
- Has the permission scope changed?
- Is the credential still used?
Rotate or revoke credentials according to the approved process.
Review shared credentials
Shared credentials can make ownership and activity harder to understand.
Confirm:
- who can use the credential;
- which workflows depend on it;
- which team owns it;
- whether it can be replaced with separate accounts;
- whether access can be revoked for one user; and
- whether activity can be traced.
Prefer clear ownership.
Inventory every tool
Record each discovered tool.
For every tool, note:
- name;
- purpose;
- read or write behaviour;
- expected input;
- returned output;
- connected source;
- destination;
- account used;
- permissions;
- workflows;
- schedules;
- normal runtime;
- warnings; and
- errors.
Treat unexpected tools as unreviewed.
Classify tools by action
Group tools into:
| Type | Examples |
|---|---|
| Read | Search, list, retrieve, inspect, read |
| Write | Create, update, send, save, move, delete |
| Mixed | Tools that can read and change information |
| Unclear | Tools whose description does not explain the action |
Investigate unclear tools before regular use.
Review read tools
For every read tool, confirm:
- approved source;
- account scope;
- fields returned;
- personal or confidential data;
- result limits;
- source freshness;
- logging; and
- whether a narrower source is possible.
Read access can still expose sensitive information.
Review write tools
For every write tool, confirm:
- exact destination;
- account;
- environment;
- records or files affected;
- approval requirement;
- reversibility;
- duplicate prevention;
- timeout handling;
- partial-write behaviour; and
- external confirmation.
Write access should receive the strongest review.
Review delete tools separately
Confirm:
- exact items the tool can delete;
- whether deletion is reversible;
- whether an archive option exists;
- whether backups exist;
- who approves deletion;
- whether the tool is enabled by default; and
- whether regular workflows need it.
Remove delete access when it is not required.
Review tool descriptions
A useful description should explain:
- what the tool does;
- what input it needs;
- what source it uses;
- what destination it changes;
- whether it reads or writes;
- what result it returns; and
- any important limitations.
An unclear description is an audit finding.
Review Workbench use
Check whether users enable the server's tools in Workbench.
Review:
- saved instructions;
- commonly used prompts;
- tool combinations;
- read-only tasks;
- write tasks;
- Activity logs;
- repeated tool calls; and
- unexpected tool selection.
Disable unrelated tools during sensitive tasks.
Review Workbench Activity
Workbench Activity can show:
- which tool was called;
- what input was sent;
- what result returned;
- whether a warning appeared;
- whether an error occurred; and
- whether the model repeated the call.
Use recent representative tasks during the audit.
Review unnecessary input
Check whether tool calls include:
- complete documents when one section is enough;
- personal information unrelated to the task;
- private notes;
- old conversation content;
- internal paths;
- unnecessary identifiers; or
- credentials.
Reduce future input to the minimum needed.
Review Studio dependencies
Open every important workflow that uses the server.
Review:
- selected tools;
- model;
- prompts;
- input mappings;
- output mappings;
- no-result paths;
- error paths;
- permissions;
- Emit blocks;
- write approvals; and
- destinations.
Confirm that the workflow still needs the server.
Review RunFlows
Inspect recent representative runs.
Confirm:
- starting input;
- tool calls;
- raw tool output;
- intermediate output;
- selected branch;
- warnings;
- errors;
- final output; and
- external actions.
A workflow may have broader access than its visible final result suggests.
Review Emit blocks
Emit blocks can reveal:
- raw tool results;
- extracted fields;
- approval proposals;
- write parameters;
- error messages; and
- intermediate decisions.
Use them when the audit needs evidence about a workflow's behaviour.
Review scheduled access
Open Schedule Manager.
Record:
- schedule name;
- workflow;
- frequency;
- next-run time;
- source;
- destination;
- read or write action;
- normal runtime;
- owner;
- reviewer; and
- recent failures.
Scheduled access deserves extra review because no person may be watching live.
Review schedule necessity
Ask:
- Is the schedule still needed?
- Is the frequency still appropriate?
- Is the source still current?
- Is the destination still correct?
- Is the server available at run time?
- Does the workflow still need write access?
- Are conflict warnings understood?
- Is a reviewer assigned?
Pause or remove unnecessary schedules.
Review conflict warnings
Schedule conflicts can create:
- overlapping runs;
- repeated reads;
- duplicate writes;
- file conflicts;
- database contention;
- local hardware pressure; or
- unexpected server load.
Increase spacing or pause one schedule when needed.
Review permissions
Audit:
- read access;
- write access;
- account scope;
- workspace scope;
- project scope;
- record scope;
- URL rules;
- IP rules;
- path rules;
- port rules; and
- destination access.
Use the narrowest permission that supports the approved task.
Review Studio Permissions
Open the Permissions panel for affected workflows.
Confirm that allowed access matches:
- the intended URL;
- the intended IP address;
- the intended file path;
- the intended port;
- the intended source; and
- the intended destination.
Remove broad or unused rules.
Review URL access
Check:
- approved domains;
- subdomains;
- paths;
- redirects;
- protocols;
- final destinations; and
- whether broad internet access is enabled.
Prefer a narrow allowlist when the destination is known.
Review IP access
Confirm:
- approved host;
- local or remote status;
- network range;
- local-network devices;
- private addresses;
- blocked addresses; and
- whether a smaller range is possible.
Avoid broad network access for one-host tasks.
Review port access
Confirm:
- port number;
- service using the port;
- local or remote host;
- authentication;
- firewall rules;
- whether the port changed; and
- whether a broad range is enabled.
Allow only required ports.
Review file-path access
Confirm:
- approved input folder;
- approved output folder;
- project directory;
- file ownership;
- read access;
- write access;
- overwrite behaviour; and
- whether the full filesystem is exposed.
Keep source and output paths separate when possible.
Review local-server access
For a local MCP server, check:
- process owner;
- startup behaviour;
- local port;
- firewall rules;
- local files;
- local databases;
- local logs;
- local credentials;
- device users; and
- physical access.
Local access can still be too broad.
Review remote-server access
For a remote MCP server, check:
- provider;
- service owner;
- network path;
- VPN;
- proxy;
- remote account;
- storage;
- logging;
- data location;
- external dependencies; and
- provider support.
Confirm that remote processing remains approved.
Review local and cloud model use
Model location affects where tool input and results are processed.
Review whether workflows use:
- local models;
- cloud models;
- both local and cloud models; or
- fallback between them.
A local model with a remote MCP server is only partly local.
Review fallback behaviour
Confirm whether a workflow can switch:
- from local to remote;
- from one MCP server to another;
- from a read tool to a write tool;
- from test to production; or
- from a preferred source to another source.
Fallback should be visible and approved.
Review external actions
For each write workflow, identify the real external action.
Examples include:
- creating a task;
- updating a record;
- sending a message;
- writing a file;
- moving an item;
- changing a status;
- creating a Journal entry; or
- deleting information.
Review the destination directly.
Verify external destinations
Confirm:
- correct account;
- correct workspace;
- correct project;
- correct record;
- correct folder;
- correct recipient;
- correct environment; and
- correct timestamp.
A successful tool call to the wrong destination is still an access problem.
Review duplicate prevention
Confirm how workflows prevent repeated:
- records;
- messages;
- files;
- tasks;
- Journal entries; or
- status changes.
Review timeout handling before approving repeated writes.
Review recent server changes
Ask whether the server recently changed:
- endpoint;
- authentication;
- account;
- tool list;
- tool names;
- input fields;
- output fields;
- permissions;
- source;
- destination; or
- operator.
Re-audit after important changes.
Review new tools
Treat every new tool as unapproved until reviewed.
Confirm:
- purpose;
- source;
- destination;
- input;
- output;
- read or write behaviour;
- permissions;
- privacy path;
- error handling; and
- owner.
Do not enable new write tools automatically.
Review removed or renamed tools
Search for old references in:
- Workbench prompts;
- Studio workflows;
- RunFlows items;
- schedules;
- Gene-provided flows;
- documentation; and
- team instructions.
Remove broken or obsolete references.
Test a known-good read action
Use a stable non-sensitive test.
For example:
Use only the enabled Internal Knowledge Search tool.
Search for "MCP access audit test".
Return:
1. result title;
2. source identifier;
3. returned summary;
4. last updated date; and
5. any warning.
Do not create or change anything.
Review Activity.
Test a blocked source
When safe and appropriate, test one clearly unapproved source.
Confirm that:
- access is denied;
- no data is returned;
- the model does not use another source silently;
- the workflow follows the permission path; and
- the denial is visible.
Test write access separately
Use:
- a test account;
- a safe destination;
- a reversible action;
- explicit approval;
- destination verification; and
- duplicate checking.
A successful read test does not prove that write boundaries are correct.
Review account activity
When the connected service provides activity records, review:
- sign-ins;
- tool actions;
- created items;
- updated items;
- deleted items;
- source access;
- destination access; and
- unexpected activity.
Compare external activity with Workbench Activity and RunFlows.
Review inactive access
Identify:
- unused tools;
- unused accounts;
- unused credentials;
- unused permissions;
- unused workflows;
- paused schedules with no owner;
- test connections; and
- retired destinations.
Remove access that no longer supports an active task.
Review old test connections
Test connections may remain after migration.
Check for names such as:
- Test;
- Temporary;
- Old;
- Replacement;
- Staging;
- Copy; or
- Backup.
Confirm whether each connection is still needed.
Review user access to the device
Local MCP access may depend on who can use the computer.
Review:
- operating-system accounts;
- administrator rights;
- shared device use;
- screen lock;
- disk encryption;
- local folders;
- secure credential access; and
- physical access.
Device access can become tool access.
Review backup access
Backups may contain:
- workflows;
- Journal entries;
- source data;
- databases;
- server records;
- paths;
- logs; and
- external result data.
Confirm that backup access is limited and that raw credentials are not stored in ordinary archives.
Record findings
Classify findings such as:
- required and appropriate;
- required but too broad;
- unclear ownership;
- unused access;
- unknown tool;
- unnecessary write access;
- expired or old credential;
- missing schedule owner;
- unapproved destination;
- hidden fallback;
- missing error handling; or
- unverifiable external action.
Assign an owner and action to each finding.
Prioritise findings
Address first:
- unknown write tools;
- administrator accounts;
- delete access;
- exposed credentials;
- unapproved remote services;
- wrong destinations;
- repeated writes;
- broad filesystem access;
- broad network access; and
- schedules without ownership.
Lower-risk documentation gaps can follow.
Reduce access carefully
Before removing access:
- identify dependencies;
- pause affected schedules;
- save a known-good test;
- narrow one permission;
- test the read path;
- test required writes;
- test RunFlows;
- verify destinations; and
- resume schedules gradually.
Change one layer at a time.
Remove unnecessary write access
Remove the ability to:
- create;
- update;
- send;
- save;
- move;
- delete; or
- overwrite
when the current workflow only needs read access.
Use separate read and write connections when possible.
Revoke unused credentials
When a credential is no longer needed:
- confirm no workflow depends on it;
- pause schedules;
- revoke or rotate it through the service;
- remove it from protected settings;
- disable the old account when appropriate;
- test the replacement access; and
- record the revocation.
Removing a visible connection may not revoke external access.
Remove unnecessary schedules
Delete or keep paused schedules only when there is a clear reason.
Confirm that:
- no required report depends on them;
- no external write is expected;
- users are informed;
- replacement automation exists when needed; and
- the schedule owner approves removal.
Retire unused servers
When no active process needs a server:
- inventory dependencies;
- pause schedules;
- preserve required records;
- remove workflow references;
- revoke credentials;
- remove permissions;
- remove the connection;
- confirm tools disappear; and
- monitor for missed dependencies.
Use a separate retirement process for important servers.
Re-test after changes
After audit changes, test:
- normal result;
- no result;
- permission denial;
- invalid input;
- server error;
- required write action;
- timeout handling;
- duplicate prevention;
- RunFlows; and
- one-time scheduled execution.
A safer permission set must still support the approved task.
Update documentation
Record the current:
- server owner;
- account owner;
- tool list;
- read and write access;
- sources;
- destinations;
- permissions;
- dependent workflows;
- dependent schedules;
- known-good tests;
- incident contact; and
- next review date.
Remove outdated instructions.
Set the next review date
Review frequency should reflect risk.
Consider:
- quarterly review for important production servers;
- more frequent review for high-impact write tools;
- review after every server update;
- review after account or credential changes;
- review after workflow migration;
- review after incidents; and
- review before retirement or replacement.
Use the schedule required by your organisation.
Final access audit checklist
Confirm that:
- the scope is defined;
- an owner is assigned;
- the server owner is known;
- the connected account is known;
- credentials have clear ownership;
- every tool is inventoried;
- read and write tools are distinguished;
- delete access is reviewed;
- Workbench use is reviewed;
- Studio workflows are reviewed;
- RunFlows evidence is reviewed;
- schedules are reviewed;
- permissions are narrow;
- external destinations are verified;
- fallback behaviour is understood;
- inactive access is removed;
- findings have owners;
- changes are tested;
- documentation is updated; and
- the next review date is set.
An MCP access audit is complete only when every active permission has a clear purpose, owner, and tested workflow.