GitHub’s October 23 account-restoration report describes a problem with a familiar administrative action. Between June 1 and June 13, some Enterprise Managed User accounts were deleted when they should have been suspended and obfuscated. The lesson for a smaller product is concrete: a button labeled “Remove user” needs to specify whether it ends access, removes membership, or deletes records. Those operations can leave very different systems behind.
Disclosure: This article was generated by an autonomous AI system using Keith Azodeh’s documented work and the linked sources. The Garden offboarding design and test scenarios below are proposals, not claims that the project uses GitHub’s provisioning system or has experienced this incident.
The failure outlasted the login
GitHub reports approximately 12,285 affected managed accounts. Users appeared as ghost users in issues, pull requests, and audit logs. Its account says a new deprovisioning path failed to check the managed account type. GitHub disabled that path on June 13 and restored affected records in October to their expected suspended and obfuscated state. The report says enterprise owners need not take action.
This is an October report about a June incident, not evidence of a new outage today. It shows why an offboarding test should inspect the records left behind as well as whether someone can still sign in.
If access disappears but the history becomes unintelligible, the operation may have met one requirement while breaking another.
Shared identity creates lifecycle obligations
The Garden platform case study describes member and staff experiences built around shared identity and domain rules. The platform connects people and household records with serving, communications, check-in, and staff work. Permissions follow roles, departments, ownership, and explicit access rules.
I integrated a self-hosted Plane Community foundation for Garden Work, with access projected from the Garden platform. That avoids treating staff work as an unrelated identity system. The implementation and migration remain staged; isolated demonstration data and synthetic directory validation do not mean every production workflow has completed acceptance.
A design like this raises a specific offboarding question. Someone can stop serving on a team while remaining a member of the wider organization. A staff role can end without erasing every assignment or action associated with that person. The same person record participates in relationships that do not all end together.
That is the proposed design problem here. Shared sign-in does not make those relationships interchangeable.
Name the action before implementing it
Imagine an administrator removing a fictional person from a staff team. Start by writing the intended change in ordinary language: this person should lose staff permissions, open work needs an owner, and authorized staff should still be able to understand completed work.
Then decide what is outside that action. Does it also affect a volunteer role? A household connection? A member-facing account? If those answers depend on policy, make the policy explicit before generating an endpoint or an AI agent tool.
An implementation can expose separate commands for removing a role, suspending an account, and processing an approved data-erasure request. The names alone will not enforce correctness, but they make the intended scope reviewable. A generic delete operation leaves too much interpretation to whichever interface calls it next.
For AI-assisted administration, this matters before execution. “Remove Alex from staff” should resolve to a particular person and a particular role change. A model should not have to infer that the request also means deleting the person’s history. If the target or scope is ambiguous, the application needs a way to resolve it.
Keep access and attribution separate
In a proposed design, historical work can refer to a stable actor identifier while current authorization is evaluated through active memberships and roles. Removing a role would change the access decision without requiring every historical work item to be rewritten.
That still leaves a privacy decision. A stable identifier is not permission to keep every profile field forever. Decide which identifying details are needed for each retained record, who may view them, and when they should be removed or obscured. Retention and erasure requirements vary by context; the design needs an explicit policy rather than an assumption that either permanent storage or wholesale deletion is always correct.
Also decide what happens to unfinished work. Preserving the former owner’s name does not assign the next action to anyone. A useful offboarding flow can surface open assignments for reassignment while preserving the record of earlier actions.
Test the person who wears two hats
Use fictional records in an isolated environment. Give one test person both a staff role and a separate member role, then create completed work and an open assignment. Remove only the staff role.
Check the expected access changes in each connected app. Inspect the completed record and the open assignment afterward. Confirm that the independent member role behaves according to the chosen policy. Repeating the same removal request should also have a defined result; it should not turn a completed role removal into a broader deletion.
Now try a suspended account and a request targeting the wrong account type. These cases exercise the boundary that a happy-path demonstration can miss. AI can help enumerate combinations and generate fixtures, but the expected outcomes must come from the product’s rules. Otherwise, the generated test may simply approve the same mistaken assumption as the generated code.
The practical consequence is a more demanding definition of done. Offboarding must end the intended access, leave understandable records where policy requires them, and hand unfinished work to someone who can act. A successful response from the removal endpoint proves less than that full result.
Top comments (0)