Separate Human and Bot Accounts

Automation that signs in as an employee inherits human permissions, recovery factors, and audit identity. When the employee leaves, the team may keep the login alive to protect the job. That is a fragile access model. Give the automation a separate service identity where the provider supports one.

Inventory the bot's actual work before changing credentials. List scheduled tasks, APIs called, resources touched, and failure alerts. OWASP's authorization and secrets guidance supports distinct principals and least privilege. A new bot account is not safer if it receives the same broad admin role and no owner.

Identity migration card

Check provider terms and supported account types. Some services do not offer service accounts. In that case, use a documented alternative or hold the automation; do not conceal a shared human login under a bot display name.

Cutover test

Create a service identity in an owned test environment. Run the normal automation with synthetic data and confirm its expected result. Try an unrelated admin action and require denial. Move the production job only after the team has a rollback and alert plan. Then revoke the automation's personal token or shared session at the provider and verify it no longer works.

Keep the employee's personal access separate. Offboarding should not break the bot, and bot rotation should not force a human password reset. Record the provider-side identity ID, scope, job health, and old credential revocation. If the provider does not support independent revocation, document the residual risk. Confirm at the provider that the bot identity can be revoked independently of each human account.