Beamreach

Custom autonomous systems · Mock demo

Quartermaster: joiner and leaver access across every system

When HR records a new starter or a leaver, Quartermaster works out exactly which access goes with the role, provisions the routine parts, asks the right owner about the sensitive parts, and keeps a record of all of it. On the way out, it finds the accounts nobody remembers, including the ones outside single sign-on.

The metric at the centre: access gaps. Every account that doesn't match what the person's role should have, missing or left behind. Quartermaster acts until it reads zero.

Mock demo · fictional company and data

Access gaps
0
Accounts that don't match what the person's role should have.
Target: 0, every day

Press Restart, then Next (or →). The run stops when it needs your approval: you play the human.

#it-access Kestrel Insurance (fictional) in Microsoft Teams
Wednesday · 09:10
👤
WorkdayHR system
New hire: Priya N., Data Engineer, Claims Analytics
start date Monday · manager Tom R. · location Lisbon · employment: permanent
🧭
Quartermasteragent
Joiner

Access plan for Priya N.: 11 routine items, 1 needs approval

from the Data Engineer role template, checked against 4 current team members' access
Plan
✓Routine, provisioned on Monday 08:00 automatically11 items▸
oktagroups: employees, eng-data, lisbon-office
googlemailbox, claims-analytics@ group, team shared drive (editor)
teamsClaims Analytics team, #data-eng, #it-access
githubteam claims-analytics (write) · 2 repos
awsSSO permission set DataEngineer → analytics-dev account
!Read access to production claims data needs the data owner's approvalApproval▸
policyaccess-policy v7 §3: prod data containing personal data → data-owner approval, max 90 days
peers3 of 4 Claims Analytics engineers hold Snowflake role CLAIMS_PROD_READ
You're the data ownerApprove for 30 daysDecline
Routed to the owner of claims data· nothing sensitive is granted without the owner
🧭
Quartermasteragent
Priya N. is set up: 11 routine items plus CLAIMS_PROD_READ (approved by the data owner, expires in 90 days). I checked each one by reading it back from the target system. Welcome message with links sent to Priya and Tom R.
Friday · 15:30
👤
WorkdayHR system
Leaver: Daniel K., Platform Engineer
last working day today, access ends 17:00 · manager Sara L.
🧭
Quartermasteragent
Leaver

Found 14 accounts and credentials for Daniel K., 2 of them outside single sign-on

searched Okta, Google, Teams, GitHub, 6 AWS accounts, Snowflake, PagerDuty, Jira
Plan for 17:00
✓Disable SSO, revoke sessions and tokens, transfer ownership12 items▸
oktadeactivate user, clear sessions (covers 9 SSO apps)
githubremove from org, revoke 2 personal access tokens
googletransfer 38 owned docs and 1 shared drive to Sara L.
pagerdutyremove from platform on-call; next week's shift has a gap, flagged to Sara L.
!Legacy IAM user dkowal-deploy has an access key still in use by a build serverDecide▸
cloudtrailkey AKIA…7QX last used 2 h ago from 10.20.4.17 (jenkins-legacy-01): s3:PutObject to release-artifacts
impactdeleting it now would break the nightly release build
Suggested
  • Run the routine plan at 17:00 as scheduled.
  • Move the Jenkins job to an IAM role (draft: PR #431), then deactivate the key on Monday. Until then, alert on any use outside jenkins-legacy-01.
You're his managerDisable key nowAssign to platform team
AI-generated plan· the manager and the platform team confirm· every step logged
🧭
Quartermasteragent
Offboarding complete: 12 of 12 routine items done and verified. Key AKIA…7QX is under watch until PR #431 merges. The access review record is ready.
🧾Access record: Daniel K. offboarding audit log · access-reviews/2026/leavers/daniel-k.json

Timeline

15:30Leaver event received from Workday. 15:3314 accounts and credentials found; plan posted. 15:41Plan accepted by the manager. 17:00Okta deactivated; sessions cleared; GitHub tokens revoked. 17:01Ownership of 38 docs and 1 shared drive transferred. 17:02Each step verified by reading the target system back.

Open items

  • IAM key AKIA…7QX: deactivate after PR #431 (owner: platform team, due Monday).
  • On-call gap next week (owner: Sara L.).

Each joiner, change and leaver gets a record like this, with who approved what and when. Your access reviews start from evidence, not spreadsheets.

🧭
Quartermasteragent
PR #431 merged: the nightly build now uses an IAM role. Last night's build passed, so I deactivated key AKIA…7QX and confirmed nothing has tried to use it since. Daniel K.'s offboarding is closed; the record is updated.

Why it matters

Day one
new starters have the access their role needs, without a chain of tickets
0
forgotten accounts left behind, including keys and tokens outside SSO
Every
grant and revocation recorded with its approver, ready for access reviews

This is a mock scenario. The figures are design targets, not measured results.

What it solves

  • Slow, ticket-driven onboarding. A new engineer waits days for access that a role template could grant on the first morning.
  • Access nobody remembers granting. Leavers keep tokens, keys and accounts outside single sign-on long after they've gone.
  • Offboarding that breaks things. Deleting a credential a system still depends on causes an outage. Quartermaster checks usage first.
  • Access reviews built from spreadsheets. Every grant, approval and revocation is already on record.

Key features

  • Triggered by HR events from Workday, BambooHR, Personio or your HR system
  • Role templates that learn from what peers on the same team actually hold
  • Connects to identity, collaboration, code and cloud: Okta or Entra ID, Google Workspace or Microsoft 365, Slack or Teams, GitHub, AWS
  • Policy-driven approvals: sensitive access goes to the data or system owner, with time limits
  • Discovery of accounts and credentials outside SSO, with usage checks before removal
  • Every step verified by reading the target system back
  • Audit records for every joiner, mover and leaver

How it stays safe

Quartermaster only runs routine steps on its own: the ones defined by a role template your team approved, which can be checked afterwards and undone. Anything sensitive, unusual or destructive waits for the owner. It works with the least privilege each connected system allows, and every action is logged with the evidence behind it. The same verifiable, reversible, contained rule decides what runs unattended.