When a developer leaves, add AI tooling to the checklist: remove their assistant seat, revoke any model API keys they created, rotate credentials in MCP server configs, and check repositories and dotfiles for agent settings that carry tokens tied to them. These credentials are easy to miss because they sit outside traditional access reviews.
Why this is a new offboarding item
Developers now run coding assistants in the editor and terminal, connect them to tools through Model Context Protocol servers, and sometimes give them tokens so they can read tickets, query databases or open pull requests. Each of those connections can carry a credential, and many are created by the individual, not by IT.
I am not claiming a specific tool's behavior here. The point is procedural: wherever a person created a credential for an AI tool, it should be on the leaver list. Check your own tools' documentation for how seats and keys are managed.
Where AI related credentials hide
| Location | What may be there |
|---|---|
| Vendor admin consoles | Per user seats and invitations |
| Model provider accounts | API keys created by the person, billed to the company |
| Local config files | MCP server definitions with environment variables and tokens |
| Repository settings | Shared agent config or instruction files committed to the repo |
| Ticketing and chat integrations | OAuth tokens granted to an agent on the person's behalf |
| CI jobs | Keys used to run automated review or generation steps |
Offboarding steps
- Seats first. Remove the person from every AI tool they were licensed in, and check for pending invitations.
- API keys. List keys by creator in each provider you use. Revoke those the person created and reissue under a service owner where the work continues.
- MCP configs. Review shared configuration files in repositories for tokens, URLs and server lists. Rotate any credential that appears. Ask the person about local configs, since those live on a laptop.
- Delegated tokens. Revoke OAuth grants that let an agent act as the person in ticketing, chat or source hosts.
- Agent identities. Where an agent runs under the person's account, move it to its own named identity with scoped permissions and an owner who is still employed.
- Logs. Review recent agent activity tied to the person's credentials for anything unusual.
- Record each action in the leaver ticket.
Design so it is easier next time
- Give agents their own identities, not a person's credentials.
- Keep MCP server definitions in version control without secrets, loading secrets at runtime from a manager.
- Register approved MCP servers centrally, so you know what is in use.
- Set expiry on any token an agent needs.
- Add "AI tools and keys I created" to the handover document.
Try it yourself
The MCP server setup demo shows how a server is configured and what a guardrail can control.
Click through it at your own pace, or open it full screen.
Quick check
Do AI assistant seats count as access?
Yes. They can expose code and prompts to the vendor on the person's account, so remove them as you would any tool.
Who should own an agent's credentials?
A named team or service owner, not the individual who set it up.
Safeguard's MCP Guardrail and agent identity capabilities are built for this, giving agents their own identities and policies you can review. A free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
