A pilot works because its creator connected every tool using their own accounts. Then the creator changes teams and nobody can say which connections should survive. The working integration hid an ownership decision the buyer still has to make.

For each credential, name the business owner, technical custodian, authorized users, permitted actions, and revocation path. Decide whether the workflow acts on behalf of a person or as a company service. Setup convenience should not make that choice by accident.

The MCP enterprise practitioner discussion identifies personal and enterprise credential mismatches. The purchasing question is whether identity stays attributable from request to connected action.

Choose ownership around the work#

A personal delegation fits an action that should carry that person’s authority and stop when their access ends. A service identity fits a recurring company process with its own owner and permission boundary. Neither supplies the right scope on its own:

For a read-only account briefing tool, a user connection restricts results to accounts the requester can read, and a broad service account silently expands access.
For a scheduled reconciliation job, tying execution to a departing employee creates avoidable interruption.

Keep credential custody separate from business authorization. The administrator who can rotate a secret lacks authority to approve a refund, and the business owner who approves the refund needs no access to the secret. A shared password combining both powers creates ambiguity later logs cannot repair.

Question	Decision to record
Who owns the process?	Role accountable for its continued business use
Whose authority does it exercise?	Named user delegation or defined service identity
Who manages the connection?	Team able to rotate and revoke it
Which targets are reachable?	Accounts, projects, objects, and environments
Who can invoke it?	Authorized requesters and any required approvals
What ends the authority?	Role change, expiration, cancellation, or incident action

Follow one staffing change#

Take a weekly account review created by a sales operations analyst. It reads customer records and saves internal briefs. When the analyst leaves, the workflow owner decides whether the process continues and the identity team removes the analyst’s personal access.

If the job must continue, reconnect it under the approved ownership model and test representative access. Do not preserve the analyst’s account to keep the automation alive. Rotating a secret does not repair attribution either, because requests can still lack the initiating user or the reason for access.

Test a task submitted before the role change and resumed afterward, including queued work and delegated helpers. Does it recheck authority, or does an old approval still allow a new action? This matters for work that waits overnight.

Ask what the agent can read directly#

A control around one connection does not cover credentials exposed through local files, environment variables, browser sessions, or another tool. Have the operator list the ways the agent can reach the destination, and claim only demonstrated paths.

The MCP security guidance explains why forwarding tokens without the intended validation creates security problems. Ask for a diagram and test showing which component receives which credential and how the destination verifies it.

Run a revocation test with synthetic data against a non-production target:

Start a permitted task.
Remove the relevant authority.
Try both a fresh action and a resumed one.
Record what stops immediately, what expires later, and what needs a separate action.

One successful test does not show revocation across unrelated tools.

Make ownership a continuing operating task#

Keep an inventory that points to the credential management system and holds no secrets. Review it when a workflow changes owner, gains a new destination, or starts writing where it previously only read. Change triggers the review, not an annual spreadsheet.

Deixic’s agent identity instructions and connection setup guide give the operator starting points, and Trust frames credential rotation and revocation questions alongside action controls.

The result is a process whose authority outlives one employee without becoming anonymous: a replacement operator knows who can invoke it, what it can do, and how to remove access.