access-review-campaign-prep

Installation
SKILL.md

Use this to prepare a review campaign before reviewers see anything. You get, in a new folder ./access-review-campaign-prep/: a short plan saying which systems are reviewed, by whom and by when, with a sign-off line per reviewer (campaign-plan.md); one spreadsheet per system, openable in Excel, listing every account with the risky ones flagged at the top, ready for the reviewer (populations/<system>.csv); and a follow-up spreadsheet that tracks whether each removal really happened (follow-up-tracker.csv). This skill drafts for a human to review and sign; this skill never marks a control effective. Reviewers decide on access; the agent only prepares and flags.

Inputs to gather

Read the system inventory, the access control policy (it states the cycle the company promised), the role or permission matrix if one exists, the results of the last review, and account exports the reader provides from the identity provider and from each system. Ask for an HR export of employees and contractors with start and end dates. Ask the reader, in one message: the review deadline, who owns each system, and which systems keep local accounts outside single sign-on.

Step 1: choose the systems

Include, at minimum: the identity provider itself, production infrastructure and cloud consoles, databases with customer data, source code and CI, finance and payroll, and any system that holds regulated data. Then add the systems outside single sign-on; leavers survive longest in local accounts nobody remembers. Split each system into privileged and standard access. Privileged access usually gets a shorter cycle than standard access; take the cycle from the company's own policy, and run a framework lookup where a framework sets one.

Step 2: build and reconcile populations

For each system, export every account with: account name, display name, role or permission level, created date, last login, and whether it is a person, a service or a shared account. Include non-human access in the same population: API keys, personal access tokens, OAuth grants to third-party apps, service principals and SSH keys, each with an owner and a last-used date. An unowned token is the leaver of a SaaS estate. Record the export time and the exact query or screen used, because the auditor will ask how you know the list was complete. Then match accounts to the HR list and pre-flag:

Installs
3
GitHub Stars
51
First Seen
6 days ago
Security Audits