Password rotation for shared logins
Rotate the shared logins nobody wants to touch.
Vendor portals, OEM consoles, and legacy admin accounts run on shared passwords. They get rotated when someone remembers, and the new value ends up in a chat thread.
What the rest of the stack cannot reach.
StitchOps rotates the password in the portal and updates your vault in the same run. The workflow references the credential by name, the worker resolves it, and the model never sees a value.
Rotate on a schedule
Monthly, quarterly, or after an offboarding. The workflow logs in, changes the password, and confirms the change on screen.
Update the vault in the same run
1Password, Keeper, or the StitchOps vault gets the new value. No spreadsheet, no chat message.
Confirmation gate before the change
A rotation is destructive if it goes wrong. Put a gate in front of it and get asked before the worker proceeds.
Evidence per rotation
Step-level status and evidence references show the rotation happened and when.
How it works with your stack.
Step 1
The schedule or the event fires
A scheduled run, an offboarding event, or a request from your assistant.
Step 2
StitchOps rotates in the portal
The agent on your worker VM logs in with the current credential, sets the new one, and verifies it.
Step 3
The vault is updated and evidence is logged
The new value lands in your vault. Nothing leaves the worker but status and timing.
How it runs
Described once. Replayed every time.
Tell Stitch the task, review the typed steps, and save it. The agent runs it on a worker VM in your environment with a vaulted credential, and logs every step.
See the platform →What you can finally automate.
Rotate a shared portal password and update the password manager
Rotate every shared login a leaver knew, the day they leave
Rotate OEM console credentials across rooftops on a schedule
Verify a rotation took effect and capture the evidence
Governance
Ask for it in plain language.
Claude, ChatGPT or Copilot can run these from your existing assistant. The model picks from typed tools; the agent owns the credentials and stops for confirmation on anything destructive.
Connect your assistant →I found a saved workflow for this. Running it on worker-01.
tool call
workflow_offboard_closed_apps
{ "email": "j.doe@example.com" }
Confirmation required
Step 5 deactivates the user in vendor-portal. This cannot be undone by the workflow.
completed in 5.2s
3 portals · 6 steps · evidence: step_05.png, step_11.png, step_17.png
Done. The user is removed from all three portals. Evidence is attached to run_01j8k.
Start with one workflow that never had an API.
Fifteen minutes on your top three manual processes. We tell you which one to run first.