DEV Community: Adeyemi Femi

Building Offboard: removing access left behind when someone leaves

Adeyemi Femi — Sat, 07 Nov 2026 16:57:31 +0000

After leaving a team, I still had access to its GitHub, Apple, and Vercel accounts. I could still see new code updates after my work there had ended.

No one had to break in. The access was already there because someone had forgotten to remove it.

That experience stayed with me. A departure can be complete in a team's calendar while the person's accounts still work. For a founder or engineering lead, finding those permissions often means checking several services, asking who owns each account, and trying to establish whether a requested removal actually happened.

I built Offboard to connect those steps: discover the remaining access, let a human approve the exact change, remove it, and independently check the result. The conversation, decision, and evidence should tell the same story.

For Flip the Switch, I connected a real Codex agent to a shared team room through Switch. GitHub is the first working provider.

Follow one departure from discovery to removal

The controlled test used a separate GitHub account I own, oluwafemi-akolade, as an ordinary member of Optimus-pro-orgs. The organization owner and integration account, Femtech-web, stayed protected.

I created a departure record with the person's name, departure date, and GitHub username. Offboard then had a specific case to investigate, rather than an ambiguous request to remove someone with a similar name.

The dashboard has four views: Overview, People & Offboarding, Integrations, and Verification Reports. They show the saved case, actual findings, human decisions, and provider checks. The investigation itself begins in the team conversation.

Bring the agent into the team's conversation

I used Switch Console, a Codex agent named offboard, and a Mattermost room called security-offboarding. The human request names the case:

@offboard investigate <case UUID>

The agent reads the shared conversation, inspects the case, and requests a real GitHub check. Its three application tools are deliberately small:

Tool	Purpose
`inspect_case`	Read the person, account, findings, and saved decisions.
`request_scan`	Request a read-only investigation for the named case.
`get_job`	Check its progress and read the resulting report.

The connection checks the actual room, human sender, and permitted case before accepting an investigation request. The agent receives no GitHub credential and has no approval or removal tool.

In the completed run, the scan found the controlled account's organization membership and saved the finding. Codex explained that result in the room, including which permissions had been checked. The dashboard displayed the same records.

This is where Switch matters: the human and agent investigate together in shared context. The agent can do useful work and discuss its findings without gaining the authority to make the removal decision.

Make approval convenient without making it automatic

An investigation should not leave the administrator searching through another screen just to discover that a decision is waiting.

After an eligible scan, Offboard automatically sends a private review email. It shows the person, GitHub account, organization, and proposed change. The recipient can review and decide without another dashboard sign-in; there is no need to connect their Gmail inbox.

Opening the email or link changes nothing. The person still confirms the account association and explicitly approves or rejects the exact removal. The link expires after 15 minutes and permits one decision. The server checks the recipient's current authority and whether the target is still eligible.

The link is private because possession grants that narrow decision. It must not be forwarded, and the agent never receives it. Owners, the integration account, and configured protected accounts cannot be removed through this workflow.

During the test, I approved the new membership proposal through this email review. A chat message did not substitute for that approval.

Check what happened after GitHub said yes

The most useful moment in the test came after the approval.

GitHub accepted the removal request with HTTP 204, but the immediate independent check still detected the membership. Offboard recorded access remains.

A separate read-only follow-up then confirmed that the membership was absent. Offboard saved a new verified removed report and retained the first report. The follow-up did not repeat the deletion.

Event on 7 November 2026	Recorded time, UTC
Investigation found the membership	14:21:42
Human approved the email proposal	14:23:44
GitHub accepted the removal	14:23:48
Immediate check still found access	14:23:50
Separate follow-up confirmed absence	14:23:58

The evidence establishes those observations. It does not establish why the two checks differed.

Afterward, the human asked Codex to review the saved outcome in the original thread. The agent read the authorization, provider operation, and both reports, then explained the result back to the room. It kept the first access-remains result visible and identified what was still unchecked.

The step-by-step GitHub walkthrough includes the genuine Switch screenshots and record references. It can be read without an app login.

Keep the decision and the evidence connected

Offboard's Next.js application runs on Vercel, with Supabase for authentication and PostgreSQL records. Resend sends the review emails. The interface and email templates use Tailwind; Neue Montreal is the application typeface.

A separate local service holds the GitHub credential and polls the application for authorized work. Switch, Mattermost, and Codex also run locally for this demonstration. The hosted dashboard can show saved evidence while those sessions are offline; new investigations require them to be available.

Each approval binds one provider account, organization, permission, and action. Before making the change, Offboard checks the current target and consumes the approval once. It saves the provider response separately from the independent verification.

That separation makes a report useful. It answers who was leaving, what was found, who approved the correction, what GitHub returned, and what a fresh check observed. It also records what remains unresolved.

For this run, GitHub membership removal was verified, while overall case coverage remained partially verified. Enterprise access, pending invitations, other organizations, and other services were outside the checked scope. Deploying the application to Vercel does not implement a Vercel access connector.

The latest completed checks passed 80 offline tests and 132 transactional PostgreSQL safety checks, with database fixtures rolled back. Unauthorized approval and removal requests were refused in live checks. The completed provider journey was tested separately against the controlled accounts.

The controlled removal happened before deployment; the hosted dashboard now shows those same saved records. A later read-only investigation also passed through the hosted app and returned its report link in Switch. It was a separate check, rather than another removal.

Set up the same workflow

Start with Node.js 24, a Supabase project, an organization you administer, and a separate ordinary-member account for the test. Resend is needed for email review. Install Switch Console with Docker running and configure its Codex provider.

After cloning the repository, install the application and create the local configuration file:

nvm use
npm ci
cp .env.example .env

Fill in your own values and create a confirmed Supabase administrator as described in the setup guide. Then check the configuration, apply the migrations, and start the app:

npm run env:check
npm run db:migrate
npm run dev

In a second terminal, start the provider service. This example uses an existing authorized GitHub CLI sign-in:

npm run worker:run -- --github-cli-auth

In Switch Console, create the offboard agent and add it to the Mattermost room security-offboarding. Configure the three-tool MCP adapter with the matching room, human sender, and case scope. Keep permission bypass off and review the tools that actually loaded. The Switch setup section contains the exact configuration and room instructions.

Connect the authorized organization in Offboard, create the case, and send the investigation request in the room. Read the findings, review the email proposal, and make the human decision. After execution, inspect both the provider response and verification report, then ask the agent to explain the saved result in the same thread.

What I learned while building with Switch

Switch let me bring an existing Codex agent into a real shared conversation. Mattermost provided a local team-chat environment without requiring a company Slack workspace. The useful part was being able to discuss a case and have the agent investigate the same records that appeared in the application.

Tool configuration needed careful checking. In the tested Switch Console 0.40.1 setup, Auto mode and project trust affected whether the reviewed tools loaded. An expired provider sign-in also required recovery, and a later request stopped on an account usage limit. A running agent process did not necessarily mean it could accept work.

For another builder, I would start by getting one room request and one restricted tool call working before adding more actions. Verify the effective tools, confirm that a real source message reaches the application, and keep the human approval boundary outside the model. Clearer tool-loading feedback, sign-in recovery, and capacity indicators would make this setup easier.

The agent also noticed a real state bug: rediscovered access still carried an earlier verification date. I fixed the transition so a fresh positive scan clears that old date while preserving historical reports. That was a useful reminder that evidence needs to describe a particular observation, rather than become a permanent success label attached to an account.

What comes next

The next provider work is Vercel, followed by Jira, Trello, and custom site integrations for organizations and teams. Those are planned; GitHub is the working connector in this build. As providers are added, one person's departure should collect their confirmed accounts in one case, with each permission checked and verified separately.

I also want to add administrator invitations, make recovery easier when local services are unavailable, and automate verification receipt emails. Proposal emails already send automatically. A redesigned result receipt was tested separately and rendered correctly in Gmail, but reached Spam, so inbox placement still needs attention.

The problem that started Offboard was simple: my work had ended, but my access had not. The goal is to help teams close that gap and leave a record they can inspect afterward.

You can try Offboard, inspect the actual GitHub run, or read the repository and setup instructions.

Building Parius: keeping freelance agreements, lessons and payments connected

Adeyemi Femi — Sat, 07 Nov 2026 16:39:31 +0000

A freelance project can become difficult long before anyone refuses to pay. A client asks for another feature in chat. Feedback arrives from a second person. Someone promises to pay after the next revision. Each decision may seem small, but by the time the work is ready, the freelancer has to reconstruct what was included, what changed and what is still owed.

The problem is not always missing information. It is information spread between conversations, agreements, files and invoices, with no dependable connection between them. I built Parius to bring those decisions into one shared workspace and carry useful experience into the next request.

Follow one project from agreement to handoff

In the demonstration project, a freelancer and client agree on a portfolio website. The freelancer publishes the deliverables, price, revision limit and final-file conditions. Both people approve the same version. That version becomes the baseline for the work; another chat message cannot silently change the agreed price.

Later, the client asks for a new feature. Instead of trying to remember every earlier conversation, the freelancer selects Review scope. Parius compares the request with the approved agreement, shows the relevant quotation and prepares a reply. The freelancer reads and edits it before deciding what to send. If the work should change, both people still need to approve a new agreement version.

The same project contains milestones, previews, final files and invoices. A client can inspect a milestone preview before accepting the work. An issued invoice makes the amount requested visible. When a final file has acceptance and payment conditions, its download remains locked until those conditions are satisfied and the freelancer explicitly releases it. Locking the final does not prevent the client from paying.

These parts matter together. A payment receipt without the agreement does not explain what was promised. A completed milestone without its invoice does not tell the freelancer what has been collected. Parius keeps each record distinct while showing how it relates to the rest of the project.

Remember a useful decision, with permission

An approved agreement describes the work, but it does not capture every preference a freelancer develops while working. One useful lesson might be to ask for a separately priced proposal before accepting an extra feature. Another might be to keep client replies concise and end with one concrete next step.

Parius can suggest a lesson after an eligible scope review. The freelancer can confirm it, edit it or dismiss it, and can also enter a lesson manually. Only a confirmed lesson enters the storage queue. Project-specific lessons stay within that project; using a general preference across projects requires an explicit choice.

Walrus Memory provides persistent storage and recall for those lessons. Parius tracks the storage job and only shows Stored on Walrus after completion with a blob reference. A later review recalls relevant lessons from the remote service and checks them against the freelancer's eligible references. The application verifies the returned memory identity, blob and exact lesson text rather than trusting any similar-looking search result.

This is retrieval of confirmed experience, not a claim that Parius trains a new model or continuously monitors every conversation. The person chooses what should be remembered, and the later review shows what it actually used.

What changed in a later review

We stored and directly verified ten distinct project memories on the production Walrus Memory service. Every recorded job returned done, its blob matched the saved application reference, and its owner and namespace matched the expected context. The public storage report records the exact lesson text and references. Check that the repository is public and this branch URL is correct before publishing the article.

The later browser test used a new client request: “Could we add a members-only area where customers sign in? Please explain what we need to decide next.” After the tester reported signing out and back in, Parius recalled five confirmed lessons and cited two. One concerned proposing separately priced extra work. The other asked for one concise paragraph, no emoji and a concrete next step without inventing a price or promising approval.

The comparison produced the same scope conclusion with and without memory: the requested functionality was additional work. The baseline reply used a longer email format with name placeholders and a closing. The memory-enabled reply was one paragraph and ended by asking whether the freelancer should draft the change proposal.

The useful difference was that Parius followed the freelancer's confirmed communication preference. We did not need the model to reverse a correct scope decision to demonstrate learning. Equally, different wording alone would not establish an improvement. The cited preference and the resulting structure explain the specific benefit observed in this example.

The browser evidence summary and a separate fresh-process comparison record these checks. They are separate runs and should not be presented as the same event. A limitation also appeared: one explanation overstated an inference as an explicit exclusion. Checked source quotations do not guarantee every sentence of generated prose is accurate, which is why the advice remains reviewable rather than authoritative.

Verify a payment instead of trusting a message

Payment promises and received money have different meanings. In Parius, a promise reported by the freelancer stays unconfirmed until the client confirms it. It never reduces the invoice balance. A follow-up draft uses saved invoice and promise facts; AI assists the wording, while the person reviews and explicitly sends the final message.

For Sui USDC payments, the client verifies a sending wallet, reviews the exact network, token, recipient and amount, then signs the transfer in their wallet. Tatum supplies the transaction evidence. Parius checks the transfer's success, sender, recipient, canonical asset, amount and time window against the reviewed instructions.

The freelancer then reconciles that verified receipt against the invoice. If the same payment was already entered manually, the matching manual record can be replaced rather than counted twice. Reconciliation records a payment that already happened; it does not send more money. The freelancer separately releases the final file when its conditions are met. In our two-account walkthrough, the client successfully downloaded the final TXT after payment and release.

Walrus Memory uses Mainnet. The invoice and agent payment demonstrations use Sui Testnet and matching Tatum Testnet configuration. These are separate integrations, and deploying the website does not change either network automatically.

Let an agent help with one reviewed payment

Parius also exposes a MCP interface. A short-lived, revocable key gives a compatible AI client access to one project's permitted context. The tools can read the project, inspect a delegated payment handoff and check its status. They cannot read private lessons, send messages, approve terms, reconcile receipts or release final files.

For one explicitly reviewed invoice request, a dedicated local Testnet wallet can complete an MPP payment. The service returns an HTTP 402 challenge bound to the request, sender, amount, recipient, asset and expiry. The local runner previews those details before execution, saves the signed transaction before broadcasting, and returns the payment proof. Parius verifies the transfer through Tatum. The freelancer still handles reconciliation and final release.

A separate live QA run paid 0.01 Testnet USDC, completed verification and reconciliation, and returned the saved result on retry without initiating another transfer. The Sui transaction and acceptance record provide the evidence. This was a separate payment run, not the payment for every screen shown in the website story.

The integration demonstrates bounded agent assistance. It does not give an AI unrestricted access to a person's wallet or permission to make financial commitments based on a client message.

What I want to improve next

The next work is to make the existing journey easier to rely on: clearer next actions around payments, stronger hosted recovery checks, and better visibility into the gap between completed work and invoicing. I also want to evaluate which remembered preferences help across realistic requests and which need correction or exclusion.

Parius does not hold funds in escrow, resolve formal disputes or offer fiat cash-out. Notifications and broader agent capabilities remain roadmap work. Remote memory deletion requires account-owner handling after local exclusion. Those limits are part of describing the product honestly, rather than implying that one shared workspace solves every problem in freelance work.

You can try Parius, read the user documentation, and inspect the repository. The implementation and evidence are there to make the workflow understandable: what was agreed, what the assistant remembered, what was delivered and what was actually paid.