Separate Service Identities from Human Ownership
Create an ownership card for integration purpose, custodianship, access approval and retirement without sharing credentials or assuming entitlement.
10/24/20263 min read
A workflow can depend on one employee's login long after that person changes roles. Alternatively, a shared technical identity can become so anonymous that nobody owns its permissions or failures. Separate the identity used by the software from the humans accountable for its purpose and access.
This article is an ownership-design guide, not instructions for creating credentials or expanding access. Provisioning service identities, granting scopes and changing security settings must follow the organization's approved process and the provider's supported account model.
Name four responsibilities
The business owner decides why the workflow exists and what outcomes are authorized. The technical custodian maintains the integration. The access approver authorizes its permitted resources and operations. The incident or recovery owner handles failures. One person can hold several roles, but the responsibilities should not disappear into a field labeled “owner.”
The technical identity should have a defined purpose and lifecycle. Do not assume every service offers the same service-account features or licensing. Verify the actual platform's supported approach with the administrator rather than sharing a human password or copying a session to keep a workflow running.
An access ownership card
The fictional organization Marshfield Instruments operates a read-only internal source-indexing workflow. Its proposed card states:
Workflow purpose: index approved research-document metadata for internal discovery.
Technical identity: approved integration identity reference, not a credential value.
Business owner: research operations lead; accountable for purpose and permitted data categories.
Technical custodian: integration administrator; accountable for configuration and maintenance.
Access approver: system owner; approves only necessary read resources and supported scopes.
Excluded capabilities: sending, deletion, account administration and unrelated document areas.
Review triggers: role changes, new data category, changed purpose, provider changes and scheduled access review under policy.
Retirement decision: business owner confirms the workflow is no longer needed; administrator follows approved removal and evidence-retention steps.
This card is the usable artifact. It identifies who can answer a permission question without storing any secret or assuming that a technical identity can approve its own expansion.
Test continuity without preserving excessive access
In a synthetic departure scenario, the technical custodian leaves the team. The workflow should not automatically inherit a replacement person's broad human account. The approved administrator reassigns custodianship through the supported process, checks the integration's existing scope and confirms that the business purpose still applies.
In a second scenario, the business owner changes roles while the custodian remains. The workflow needs an accepting business owner; technical continuity alone does not justify ongoing processing. If nobody accepts responsibility, hold new work while the appropriate owner decides whether to retire or transfer it.
Neither scenario authorizes silent credential rotation or new persistent grants. Those are separate security actions requiring the relevant approvals. Record what was approved and verify the resulting state before claiming that continuity is restored.
Separate identity from authority
OWASP recommends minimum downstream permissions. A dedicated technical identity can help organize access, but its name does not make it least-privileged. Review the actual operations and resources available. A read-only research task should not receive unrelated write or messaging capability merely because a connector requests it by default.
Keep human approvals attributable to people or authorized roles, not to the integration account itself. The service identity executes within granted scope; it should not manufacture approval records or interpret an administrator's access grant as permission for every future business action.
Make reviews evidence-based
At review time, compare intended purpose, configured permissions and observed use. Identify unused access, new dependencies and items that no longer have an owner. Any reduction or change should follow approved administration procedures, especially where it could interrupt active work.
The finished design should survive an ordinary team change without sharing passwords, losing accountability or silently broadening access. It does not promise uninterrupted service. It makes the responsible people, allowed scope and retirement path clear enough that continuity and security can be managed deliberately.
If you are also choosing research access, ask about Leads Automation’s independent Sales Navigator offer at US$15/month on WhatsApp. Confirm the available plan, eligibility and terms before ordering; Leads Automation is not affiliated with LinkedIn. This is not LinkedIn’s official price or an assurance that any particular integration is included.