Who owns an agent skill when someone leaves
By Randy Olson, Co-Founder & CTO, Goodeye
A skill in Goodeye belongs to exactly one user account, and there is no administrator who can reclaim it after that account is gone. Ownership moves only by a transfer the current owner starts and the new owner accepts, so offboarding has to happen while the departing person can still run a command. Grants are not a substitute for ownership.
Somebody on your team spent months building the runbooks your agents follow. They wrote the skill that drafts your release notes, the one that reviews migrations, the one that turns an incident transcript into a postmortem. Now they are leaving.
The code they wrote is in the repository. The documents are in the shared drive. The skills are on their account, and that is a different kind of thing.
Most teams find this out in the wrong order. The skills keep working after the person goes, because access already granted keeps resolving, so nothing breaks on their last day. The gap surfaces weeks later when somebody needs to publish a fix and discovers the only account that can approve it belongs to a person who no longer works there.
A skill belongs to one account, not to the team
Every skill has exactly one owner, and that owner is a user account rather than a company, a team, or a workspace. Sharing does not change it. You can grant a skill to five people and a whole team at admin role, and every one of those grants describes what somebody may do with a skill that still belongs to the person who published it.
That single owner is what makes the offboarding question real, and it is worth saying plainly what follows from it.
There is no administrator who can take it back
There is no organization-level ownership and no administrator override. Nobody can reach into a departed colleague's account and reassign what is there. The only path ownership takes off an account is a transfer that the owner starts.
A teammate holding an admin grant can manage access while the handover happens, which is useful, but that is the limit of it. An admin grant does not let anyone assign the skill to themselves.
So the practical answer to "who owns the skill when they leave" is: they still do, unless you did something about it first. Everything below is about doing it first.
List what they own while the account still works
Start from their account, not yours. Only they can see the full set:
goodeye skills list --filter mine
That is the working list for the rest of the offboarding. Expect it to be longer than anyone predicted, and expect two or three entries on it to matter more than the person realises, because the skills a team leans on hardest are usually the ones nobody has thought about since the week they were written.
Transfer the ones the team depends on
goodeye skills transfer-ownership release-notes @newowner
This returns an invitation. It does not move anything yet. Ownership changes when the recipient accepts:
goodeye invitations list --filter received
goodeye invitations accept <invitation_id>
Two consequences follow from the invitation step, and both of them bite people who run the transfer at the last moment.
The first is timing. A transfer started on somebody's final afternoon and accepted the following week is fine. A transfer started on their final afternoon and never accepted leaves the skill exactly where it was, and the account it is waiting on may already be closed. Start early, and verify acceptance rather than assuming it.
The second is dependencies. When the new owner accepts, every verifier and image generator the skill references is copied into their account, so the checks the skill relies on keep running under the new ownership. The originals stay where they are and keep working. If the skill references a verifier that has since been revoked or deleted, acceptance fails and the invitation stays open until the reference is fixed, which is a good reason to run the transfer while there is still time to sort that out.
Grant to the team, not to the person
Transfers handle the skills that already exist. The way to stop the next departure costing you an afternoon is to make team membership, rather than a list of individuals, the thing that carries access:
goodeye skills grant release-notes @platform-team edit
Every current member of that team inherits the role, and so does every future member. Somebody joining next quarter gets access by being added to the team, and somebody leaving loses it by being removed, with no per-skill bookkeeping in between.
A grant carries a version floor, which by default is the version current when you shared it. If the new team should be able to read the whole history rather than everything from today forward, say so when you grant:
goodeye skills grant release-notes @platform-team edit --include-history
Teams have a single owner too, so the same question applies one level up. goodeye teams transfer-ownership platform-team @newowner moves it, again through an invitation, and the previous owner becomes an ordinary member once it is accepted.
Know what removing someone actually does
goodeye teams remove-member platform-team @alice
This ends team-derived access immediately, because team grants are resolved against current membership every time they are checked rather than copied out at grant time. It is also the whole of what it does, and the rest is easy to assume and wrong.
Direct grants survive. Anything granted to Alice personally is still granted to her after she leaves every team you have. Those come off one at a time:
goodeye skills revoke-grant release-notes alice@example.com
Skills she owns stay hers. Removing somebody from a team does not touch ownership, which is the whole reason the transfer step exists.
Removal is not silent, either: the person is notified by email. That is usually what you want, and it is worth knowing before you run it during a sensitive departure.
Check access before and after
goodeye skills grants release-notes --table
goodeye skills grants release-notes --json
The table is for reading, the JSON adds granted_by and granted_at. You need admin on the skill to see either.
Two limits matter if you are treating this as an audit. It reports current access only, so a grant revoked last month leaves nothing you can query: if your policy needs a durable record of who could read what and when, keep that record where you keep the rest of your access reviews. And a person can hold access through a team rather than directly, shown by is_via_team, which is the row that revoke-grant alone will not clear.
Where to start
Do not wait for a resignation. Run goodeye skills grants on the two or three skills your team would most hate to lose, and look at who owns them. If every one of them is owned by the same person, you already know what your next offboarding looks like.
Then move the access those skills depend on onto a team grant, so the next change is a membership edit rather than a scramble. If the handover also involves a skill whose behavior has drifted, roll back a bad agent skill update covers getting a known-good version back in front of the team while you work out what changed.
Frequently asked questions
What happens to an AI agent skill when its owner leaves the company?
Nothing automatic happens, which is the problem. A skill belongs to one user account, and it stays on that account after the person stops working for you. Access other people were granted keeps working, so the loss is invisible at first: the team goes on running the skill and only discovers the gap when somebody needs to publish a change and finds that the account which can approve it is gone. Ownership moves only through a transfer the current owner starts and the recipient accepts, so the window to fix this closes when their account does. Treat listing and transferring what they own as an offboarding step alongside returning the laptop.
Can an administrator take over a skill owned by a departed employee?
No. Goodeye has no organization-level ownership and no administrator override. A skill is owned by an individual user account, and the only route off that account is goodeye skills transfer-ownership, which the owner has to run. A teammate holding an admin grant can manage who else has access, which is genuinely useful during a handover, but the skill still belongs to the original owner and an admin grant does not let anyone hand it to themselves. This is worth knowing before you need it rather than after, because the remedy after the account is gone is to rebuild the skill from the copy on somebody's disk.
How do I transfer ownership of an agent skill to someone else?
Run goodeye skills transfer-ownership my-skill @newowner from the account that owns it. That returns an invitation rather than moving anything, and ownership changes only when the recipient runs goodeye invitations accept <invitation_id>. Check that they did, because a transfer started on somebody's last afternoon and never accepted leaves the skill exactly where it was. On acceptance, every verifier and image generator the skill references is copied into the new owner's account so the checks keep running, and the originals stay in place. If a referenced verifier has been revoked or deleted, acceptance fails and the invitation stays open until you fix the reference.
Does removing someone from a team revoke their access to its skills?
It revokes team-derived access only, and that part is immediate: team grants are resolved at read time against the caller's team membership, so goodeye teams remove-member platform-team @alice ends everything Alice could reach through that team. Any grant made to her directly survives untouched, and so does every skill she personally owns. A complete offboarding is therefore three passes, not one: remove her from teams, run goodeye skills revoke-grant for each direct grant, and transfer anything she owns that the team depends on. The removed member is notified by email, so this is not a silent operation.
How do I see who has access to a shared AI agent skill?
Run goodeye skills grants my-skill --table for a readable list, or --json when you want the detail. Each row names the grantee, whether it is a user or a team, the role, who granted it, and when. You need the admin role on the skill to read it. Two limits are worth knowing before you rely on this for an audit. It shows current access only, so a grant that was revoked last month leaves no trace you can query. And a person can appear through a team rather than directly, which the is_via_team field tells you, and that is the row you cannot fix with revoke-grant alone.