CONTEXT(CLONE)
Sign in

Access recertification across every account and role

For: IT security manager or identity owner running the periodic access review

Pattern: Map, verify, reduceNeeds scaleDesigned for 40 to 1,000 agents
Get early accessSign in to use

The pain today

Managers receive a spreadsheet of entitlements and approve all of it, because nobody can judge that many rows. Leavers, role changes and toxic combinations pass through every cycle.

The ask

“I attached the entitlement exports from our systems, the staff roster with roles and leavers, and our access policy. For every person, tell me which access does not fit their role, which accounts belong to nobody, and which combinations break segregation of duties. Show the rows.”

Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.

What you attach or connect

  • Entitlement exports per system
  • Staff roster with roles, managers and leavers
  • Access policy and role baselines
  • Segregation-of-duties rules

The unit of work

One worker task per one person or service account with its entitlements.

Why a swarm fits

Each identity is judged from its own rows, its role and the policy. Nothing about one person is needed to judge another, so the floor can match the roster.

Not for

A small team on one system: the admin console's own report is enough.

The decision tree

5 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

  1. Planner, while planning

    Scope checkA choice among options

    Before work starts on a unit

    Does this account match exactly one person or registered service on the roster?

    Sees only: One account's export rows and the candidate roster entries

    Why: Orphans are listed rather than guessed, and leaver accounts go straight to a person.

    • One clear matchthenAccept
    • Several possible matchesthenEscalate to a strong model
    • No match on the rosterthenMark unresolved
    • Matches a leaverthenAsk a person

  2. Before workers, before a task runs

    Small worker or strong modelYes or no, with a probability

    Before a task runs

    Does this identity hold administrative, payment approval or production entitlements that warrant the strong reviewer?

    Sees only: The identity's entitlement names

    Why: Most identities are routine; the dangerous ones get the careful read.

    • Yes: 0.50 or higherthenEscalate to a strong model
    • Unsure: 0.20 up to 0.50thenEscalate to a strong model
    • No: below 0.20thenAccept

  3. After workers, the judge checks

    Evidence checkYes or no, with a probability

    After a worker answers

    Does the quoted policy rule exclude this entitlement for the role on the roster row, rather than simply not mention it?

    Sees only: The export row, the roster row and the quoted policy rule

    Why: A flag a manager cannot trust gets the whole pack approved unread.

    • Yes: 0.85 or higherthenAccept
    • Unsure: 0.50 up to 0.85thenMark unresolved
    • No: below 0.50thenReject and retry

  4. Reconciler, while merging

    Conflict checkYes or no, with a probability

    While reconciling

    Do these two entitlements held by one identity match both sides of one segregation rule, such as creating a supplier and approving its payment?

    Sees only: Two export rows for one identity and one segregation-of-duties rule

    Why: Toxic combinations are invisible row by row and only show up as a pair.

    • Yes: 0.85 or higherthenAccept
    • Unsure: 0.50 up to 0.85thenEscalate to a strong model
    • No: below 0.50thenContinue

  5. Accountable person, before anything is settled

    Person decidesYes or no, with a probability

    Before anything is reported as settled

    Does this review pack contain any flag whose action would remove access from a person or disable an account?

    Sees only: One manager's review pack

    Why: Managers and system owners approve or revoke; nothing is removed automatically.

    Accountable: Managers and system owners approve or revoke; nothing is removed automatically. The roster is personal data and needs access limits.

    • Yes: 0.30 or higherthenAsk a person
    • Unsure: 0.10 up to 0.30thenAsk a person
    • No: below 0.10thenAccept

The fleet: who does what

Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.

  1. Planner

    A strong reasoning model turns policy and duty rules into checks per role and matches identities across systems.

    Decisions here:1. Scope check

  2. Workers

    Small fast workers from an open-weight family each review one identity's entitlements against its role baseline.

    Designed for 40 to 1,000 agents, one worker task per one person or service account with its entitlements. Each worker receives only its own unit.

    Decisions here:2. Small worker or strong model

  3. Judge, from a different model family

    A decision model from a different family checks each flagged entitlement against the quoted policy rule and export row.

    Decisions here:3. Evidence check

  4. Reconciler

    A strong reasoning model builds review packs per manager and keeps identity-matching doubts visible.

    Decisions here:4. Conflict check

  5. Accountable person

    Managers and system owners approve or revoke; nothing is removed automatically. The roster is personal data and needs access limits.

    Decisions here:5. Person decides

Checked before anything is accepted

  • Every flag cites the export row and the policy rule
  • Accounts matching no roster entry are listed as orphans, not guessed
  • Duty conflicts name both entitlements and the rule they break
  • Identities matched across systems on weak evidence are marked

What comes back

  • Review packs per manager with only the flagged access
  • Orphan and leaver accounts
  • Segregation-of-duties conflicts
  • Roles whose baseline is missing or outdated

What to measure

  • Flags revoked against flags raised
  • Leaver accounts found
  • Manager review time
  • Audit findings on access after the cycle

Names of measures only. No result is claimed for this template.

Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.

Get early accessSign in to use

More in Security and IT operations

A night of alerts triaged into incidents with evidence

For: Security operations lead or on-call analyst starting the morning shift

Overnight the queue fills with alerts, most of them duplicates or noise.

Pattern: Map, verify, reduceNeeds a connector6 decisionsDesigned for 30 to 1,000 agents

Root-cause hypotheses tested against log windows

For: Site reliability engineer or incident commander writing the review after an outage

After an outage the first plausible story wins.

Pattern: Cross-examinationNeeds scale6 decisionsDesigned for 20 to 500 agents

Threat model attacked before the design is built

For: Security architect or product security engineer reviewing a new system design

Threat models are written by the people who designed the system, so they list the threats the design already handles.

Pattern: Adversarial reviewNeeds live models5 decisionsDesigned for 6 to 60 agents