Review MCP Credential Ownership
MCP servers may need credentials to connect to accounts, sources, databases, or external services.
These credentials may include:
- API keys;
- access tokens;
- passwords;
- database credentials;
- protected headers;
- service accounts; or
- another supported authentication method.
Every credential should have a clear owner, a defined purpose, limited permissions, and a known process for rotation and revocation.
Why credential ownership matters
A credential can remain active long after the original user, workflow, or project no longer needs it.
Unclear ownership can lead to:
- access that no one reviews;
- credentials that are never rotated;
- shared secrets with no accountable owner;
- disabled accounts breaking important workflows;
- old credentials remaining active after migration;
- broad permissions being reused for unrelated tasks; or
- recovery delays when no one knows how access was created.
Clear ownership makes access easier to maintain and remove safely.
What ownership means
Credential ownership should answer:
- Who requested the credential?
- Who approved it?
- Who controls the connected account?
- Who can rotate it?
- Who can revoke it?
- Which server uses it?
- Which tools depend on it?
- Which workflows and schedules depend on it?
- What happens when the owner changes?
- How is access recovered after device loss?
Ownership is more than knowing who first entered the secret.
Keep secret values protected
Feluda stores supported secrets through the operating system's secure credential store.
Depending on the operating system, this may use:
- Windows Credential Manager;
- macOS Keychain; or
- a Linux keyring.
Secret values should not be placed in:
- Workbench prompts;
- Studio instructions;
- Journal entries;
- ordinary notes;
- screenshots;
- plain-text files;
- workflow output;
- support messages; or
- unencrypted backup archives.
The AI model should never need to see the raw secret.
Create a credential record
Keep a non-secret record for every important MCP credential.
Include:
- credential name;
- connected service;
- account owner;
- business purpose;
- MCP server;
- environment;
- permission scope;
- workflows that depend on it;
- schedules that depend on it;
- creation date;
- expiry process;
- rotation owner;
- revocation method;
- recovery method; and
- next review date.
Do not record the raw credential value.
Use a clear credential name
A clear name should identify:
- service;
- environment;
- purpose; and
- access level.
For example:
Customer Records — Production — Read Only
Or:
Local Project Database — Test — Write Access
Avoid names such as:
key1
Or:
new token
Identify the account owner
The account owner should be known and active.
Confirm:
- person or team;
- contact details;
- organisational role;
- service responsibility;
- approval authority;
- rotation responsibility; and
- revocation responsibility.
An account without an owner should not support important automation.
Separate credential owner from workflow owner
The person who owns the credential may not own the workflow.
For example:
- IT may own the service account;
- a business team may own the workflow;
- security may approve the access;
- a project owner may review the output.
Record each responsibility separately.
Identify the connected service
Confirm exactly where the credential is used.
It may connect to:
- an MCP server;
- a business application;
- a database;
- cloud storage;
- messaging;
- an internal service;
- a local application;
- a local database; or
- another approved provider.
A credential should not be reused across unrelated services without a clear reason.
Identify the environment
Confirm whether the credential belongs to:
- development;
- test;
- staging;
- production;
- a personal account;
- an organisational account;
- a local device; or
- a shared service.
Use clear separation between test and production.
Review credential scope
Scope defines what the credential can access.
Review:
- read access;
- write access;
- delete access;
- administrative access;
- project scope;
- workspace scope;
- record scope;
- file access;
- database access;
- source access;
- destination access; and
- network access.
Use the narrowest scope that supports the approved task.
Prefer read-only access when possible
Use a read-only credential for workflows that only need to:
- search;
- retrieve;
- inspect;
- list;
- compare; or
- read information.
A read-only workflow should not rely on a credential that can create, update, send, move, overwrite, or delete.
Separate read and write credentials
When possible, use one credential for read access and another for write access.
This makes it easier to:
- limit routine workflows;
- review write activity;
- revoke write access separately;
- test safely;
- reduce accidental changes; and
- assign different owners.
Review administrator access
Administrator credentials should not support routine MCP tasks unless the task truly requires them.
Ask:
- Does the tool need administrator rights?
- Can a project account be used?
- Can a limited service account be created?
- Can delete access be removed?
- Can the credential be restricted to one environment?
- Can write access be approved separately?
Broad administrator access is a high-priority review finding.
Review service accounts
A service account can be useful for repeatable workflows.
Confirm that it has:
- a clear owner;
- a clear purpose;
- limited scope;
- no unnecessary interactive access;
- a documented rotation process;
- a documented revocation process;
- activity that can be reviewed; and
- no use outside the approved workflows.
Review personal accounts
A personal account may create risk when the owner:
- leaves the organisation;
- changes role;
- loses access;
- changes a password;
- enables additional security;
- removes the integration; or
- no longer owns the workflow.
Important shared automation should not depend on an unreviewed personal account.
Review shared credentials
Shared credentials make it harder to know who used them.
Confirm:
- who has access;
- why sharing is necessary;
- which servers use the credential;
- which workflows use it;
- whether activity can be traced;
- whether separate accounts are possible;
- how access is removed for one person; and
- who approves continued sharing.
Replace shared access when a clearer model is available.
Review credential reuse
One credential should not automatically be used for several:
- MCP servers;
- workflows;
- teams;
- projects;
- environments;
- sources; or
- destinations.
Reuse can make revocation difficult.
Confirm that each use is necessary and understood.
Map dependencies
For every credential, identify:
- MCP server;
- MCP tools;
- Workbench instructions;
- Studio workflows;
- RunFlows items;
- scheduled workflows;
- Genes;
- local applications;
- databases;
- sources;
- destinations; and
- external services.
Do not rotate or revoke an important credential before mapping its dependencies.
Review MCP Servers
Open MCP Servers in Feluda.
For each relevant connection, confirm:
- server name;
- endpoint;
- authentication method;
- account;
- connection state;
- expected tools;
- warnings; and
- errors.
The visible connection should match the credential record.
Review tool access
For every tool that uses the credential, record:
- tool name;
- purpose;
- read or write behaviour;
- source;
- destination;
- required scope;
- workflows;
- schedules; and
- external action.
A credential may be broader than any single tool requires.
Review Workbench use
Confirm whether users enable tools that depend on the credential.
Review:
- saved prompts;
- common instructions;
- tool combinations;
- Activity logs;
- repeated calls;
- write actions;
- unexpected tools; and
- unnecessary input.
Credentials should remain hidden from the model and user-facing activity.
Review Workbench Activity
Activity can help confirm:
- which tool was called;
- what parameters were used;
- what result returned;
- whether a warning appeared;
- whether an error occurred; and
- whether the call repeated.
The raw credential value should never appear.
Review Studio workflows
Open dependent workflows and review:
- selected MCP tool;
- model;
- prompt;
- input mappings;
- output mappings;
- permissions;
- error paths;
- approval steps;
- write destinations; and
- schedule use.
Confirm that the workflow still needs the account and scope.
Review RunFlows
Use recent representative runs to confirm:
- the tool still works;
- the intended account is used;
- the expected source is accessed;
- the correct destination is changed;
- warnings are visible;
- errors are visible; and
- no unsupported fallback occurs.
Review schedules
Open Schedule Manager.
Record schedules that depend on the credential.
Confirm:
- workflow;
- frequency;
- source;
- destination;
- read or write behaviour;
- next-run time;
- owner;
- reviewer;
- recent failures; and
- pause process.
Scheduled workflows can fail suddenly when credentials expire or are revoked.
Review expiry
Determine whether the credential:
- expires automatically;
- requires manual renewal;
- depends on an account session;
- depends on an external identity provider;
- requires periodic rotation; or
- remains active until revoked.
Record the renewal process before expiry.
Review rotation frequency
Use the rotation schedule required by the service and your organisation.
Also rotate after:
- suspected exposure;
- account-owner change;
- server replacement;
- provider change;
- employee departure;
- permission reduction;
- environment migration;
- device loss; or
- an incident involving the credential.
Prepare for rotation
Before rotating:
- identify every dependency;
- pause important schedules;
- stop active write actions;
- save a known-good read test;
- confirm the new scope;
- confirm rollback options;
- issue the new credential;
- update protected settings; and
- keep the old credential active only for the approved transition period.
Rotate one credential at a time
Do not rotate several important credentials without checkpoints.
After each rotation:
- confirm the MCP connection;
- confirm the expected tools;
- run the known-good read test;
- review Workbench Activity;
- test affected workflows;
- test required writes;
- verify destinations; and
- use a one-time scheduled test.
Re-enter credentials securely
Enter new values only through Feluda's protected settings or the operating system's approved secure credential interface.
Never place them in:
- chat messages;
- workflow inputs;
- plain-text migration files;
- Journal entries;
- screenshots;
- support tickets; or
- ordinary backup files.
Verify rotation
Confirm that:
- the new credential works;
- the intended account is used;
- the correct scope is active;
- expected tools work;
- write destinations are correct;
- schedules pass; and
- the old credential is no longer needed.
Then revoke the old credential.
Revoke old credentials
Removing a visible connection does not always revoke external access.
Revoke through the connected service when:
- the credential is replaced;
- the server is retired;
- the account is no longer needed;
- the owner changes;
- access is too broad;
- the device is lost;
- exposure is suspected; or
- the provider relationship ends.
Verify revocation
Confirm that:
- the old credential no longer authenticates;
- the old account no longer has unnecessary access;
- no schedule still depends on it;
- no other server uses it;
- no fallback uses it;
- external activity has stopped; and
- revocation is recorded.
Do not test by exposing the secret value.
Remove unused credentials from Feluda
After revocation:
- remove the unused connection value;
- remove obsolete MCP connections;
- remove unused provider keys;
- remove temporary test credentials;
- remove duplicate secrets;
- update documentation; and
- confirm that required workflows use the replacement.
Respond to suspected exposure
When a credential may be exposed:
- stop affected access;
- pause schedules;
- disable risky write tools;
- revoke or rotate the credential;
- inspect account activity;
- identify affected workflows;
- identify affected destinations;
- contact the security or privacy owner;
- issue a replacement with limited scope; and
- test recovery safely.
Do not copy the exposed value into the incident record.
Review account activity
When the connected service provides activity records, review:
- sign-ins;
- tool actions;
- created records;
- updated records;
- deleted records;
- source access;
- destination access;
- timestamps; and
- unexpected locations.
Compare external activity with Workbench Activity and RunFlows.
Review credential failure
A credential problem may appear as:
- authentication error;
- permission denied;
- missing tools;
- empty results;
- partial results;
- wrong account;
- wrong environment;
- failed writes; or
- repeated retries.
Confirm the account and scope before replacing the credential.
Distinguish expiry from permission loss
An expired credential cannot normally authenticate.
A valid credential with reduced permissions may connect but fail on specific tools or fields.
Review:
- connection state;
- tool list;
- account scope;
- Workbench Activity;
- RunFlows errors; and
- external account settings.
Plan secure recovery
A recovery process should explain how to restore access after:
- device failure;
- operating-system reinstall;
- computer migration;
- credential loss;
- service-account replacement;
- server replacement; or
- disaster recovery.
The process should not depend on a plain-text copy of the secret.
Record recovery requirements
Record:
- service owner;
- account owner;
- approval process;
- account-recovery method;
- credential reissue method;
- required permissions;
- required MFA or identity steps;
- testing process; and
- revocation of old access.
Test recovery without exposing secrets
Use a controlled process to confirm that an authorised person can:
- identify the correct service;
- contact the owner;
- request new access;
- configure the protected value;
- reconnect the MCP server;
- run a known-good read test;
- test required writes; and
- restore schedules safely.
Do not reveal the current credential during the exercise.
Review device migration
When moving Feluda to another computer:
- do not copy secrets into migration notes;
- re-enter protected credentials securely;
- verify the new device's user account;
- test MCP connections;
- test workflows;
- test schedules;
- revoke old-device access; and
- clean up the old device after cutover.
Review staff changes
When a person changes role or leaves:
- identify credentials they own;
- identify accounts they control;
- identify workflows they maintain;
- transfer ownership;
- rotate shared credentials when appropriate;
- remove personal access;
- update recovery contacts; and
- verify important schedules.
Do not leave critical credentials assigned to an inactive owner.
Review team changes
When a project or team ends:
- identify its MCP servers;
- identify credentials;
- identify workflows;
- identify schedules;
- preserve required records;
- revoke unused access;
- retire unnecessary accounts; and
- document continued ownership for anything retained.
Review third-party ownership
A provider-managed server may use credentials controlled partly outside your organisation.
Confirm:
- provider;
- service terms;
- support contact;
- account ownership;
- data location;
- credential-revocation process;
- export process;
- service-end process; and
- replacement plan.
Review local credentials
Local servers may use:
- operating-system accounts;
- local database accounts;
- local tokens;
- file permissions;
- local application profiles; or
- protected headers.
Local credentials need the same ownership and review as remote ones.
Review backups
Ordinary backups should not contain raw credentials.
Confirm that backup records include:
- credential purpose;
- service;
- owner;
- scope;
- reissue method;
- recovery contact; and
- revocation status.
Keep secret recovery separate and protected.
Review duplicate credentials
Duplicate or forgotten credentials may remain after:
- server migration;
- device migration;
- testing;
- provider changes;
- account changes;
- failed rotations; or
- emergency recovery.
Identify and revoke credentials that are no longer required.
Review temporary credentials
A temporary credential should have:
- a clear purpose;
- limited scope;
- an owner;
- an expiry date;
- a removal date;
- no unapproved production use; and
- confirmation of revocation.
Temporary access should not become permanent by accident.
Test a known-good read action
After ownership or credential changes, use a safe read-only test.
For example:
Use only the enabled Internal Knowledge Search tool.
Search for "MCP credential review 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 Workbench Activity.
Test required write access separately
Use:
- a test account;
- a safe destination;
- a reversible action;
- explicit approval;
- external verification; and
- duplicate checking.
Confirm that read access cannot perform the write.
Use a one-time schedule test
Before resuming recurring schedules after a credential change:
- use a safe one-time run;
- confirm authentication at run time;
- review Schedule Manager;
- review RunFlows;
- verify the result;
- verify the destination; and
- check for duplicates.
Record review findings
Classify each credential as:
- required and appropriate;
- required but too broad;
- required but ownership unclear;
- shared without sufficient control;
- expired;
- unused;
- duplicated;
- temporary but overdue for removal;
- tied to an inactive owner; or
- ready for revocation.
Assign an owner and action to every finding.
Prioritise high-risk findings
Address first:
- exposed credentials;
- administrator credentials;
- delete access;
- production write access;
- inactive owners;
- unknown shared access;
- credentials used across environments;
- credentials with no revocation process;
- old credentials that remain active; and
- credentials stored outside protected settings.
Set a recurring review date
Review important credentials:
- at a regular interval;
- before expiry;
- after rotation;
- after incidents;
- after server updates;
- after server replacement;
- after device migration;
- after staff changes;
- after permission changes; and
- before server retirement.
Follow your organisation's required schedule.
Final credential ownership checklist
Confirm that:
- every credential has a clear name;
- the connected service is known;
- the account owner is active;
- the credential owner is known;
- the business purpose is current;
- the environment is clear;
- the scope is limited;
- read and write access are separated when possible;
- administrator access is justified;
- shared access is reviewed;
- dependencies are mapped;
- expiry is understood;
- rotation is documented;
- revocation is documented;
- recovery is documented;
- the value is stored securely;
- raw secrets do not appear in prompts or files;
- old and duplicate credentials are removed;
- schedules are tested after changes; and
- the next review date is set.
Credential ownership is clear only when someone is responsible for the access from creation through rotation, recovery, and final revocation.