Product · Organisations that commission software, and the agencies that build it.
Every supplier works inside an engagement with a scope and an end date. Their people propose changes and never approve one, their access ends with the engagement, and the handover pack proves it did.
- The problem
- A contractor finishes, keeps their access for months, and nobody can show which changes they made, who approved them, or that their keys stopped working.
- What it does
- Records each engagement, gives the supplier’s people identities that can propose but never approve, holds any change to CI for a named person, and revokes and re-checks every credential when the work ends.
- The result
- When the engagement closes you can show every change their people proposed through Aspian and who approved it, and prove each credential is refused, in a pack anyone can verify.
Northgate Digital → Kestrel Pay
Engagement ENG-014 · merchant onboarding · ends 30 Nov
Handover pack, from the records
- Repositories in scope
- Held by Kestrel Pay’s own GitHub installation
- Changes proposed through Aspian
- 214, each with who approved it
- What is running
- Production and staging, as last observed
- Audit trail
- Chain verified; pack signed, checks offline
Offboarding, biggest blast radius first
- Merge rights removedWaiting
- Deploy tokens revokedWaiting
- Agent keys revokedWaiting
- Workspace sign-in endedWaiting
A credential that still works, or that no provider can check, is shown as unproven, and the pack stays open.
An engagement, from the first day
You record the supplier, the repositories and paths in scope, the data involved, whether it is regulated, the risk level and the start and end dates. The scope and dates are fixed: an extension is a new engagement, so the record shows what was agreed when.
- GitHub access can only be recorded for a repository in the scope.
- The supplier’s agent keys can never outlive the engagement.
- Your rulebook applies to them as it does to your own staff and agents, and writes their agents’ rule files.
Propose, never approve
A supplier identity can open changes and ask for approval. It can never approve one, theirs or anyone’s, and it can’t hold an approver or admin role. The database enforces this, so no screen or script can get round it.
- A change to a CI workflow or deploy configuration always needs a named person’s passkey, so a contractor can’t edit the pipeline to skip the tests.
- On the end date their sign-in and agent keys stop working, and the engagement is closed for you, so every credential is revoked and checked even if nobody remembers.
Offboarding, biggest blast radius first
Closing an engagement revokes every agent key and workspace sign-in its people hold, and the GitHub access and deploy tokens recorded for it. Each outside credential is recorded only once GitHub or Vercel confirms it works. Then each old credential is tried again: GitHub must report no access and the old token must be refused. Every step goes into the signed, hash-chained audit trail.
- A credential that still works, that its provider never confirmed, or that we have no revoker for yet (today: anything but GitHub and Vercel), is reported as unproven, never as done.
- The handover pack lists every change their people proposed through Aspian and who approved it, what is running, which repositories your own GitHub installation holds, and the revocation checks. Changes pushed straight to a repository aren’t in it. It is signed with Aspian’s published key and verifies offline.
For agencies
A governed engagement is proof of your quality. Your client sees approvals and a clean handover without asking for screenshots.
See what shipped without approval in your last 90 days.
Install the GitHub App and the scan arrives in minutes: every repo scored, every unreviewed merge and unapproved deploy named. Nothing is blocked until you choose.
Ship like a startup. Prove it like a bank.