Least privilege, visualised

Every credential in a company is a promise about what it can reach. Most companies have never drawn that promise out. This is the access matrix of a 40-person company. Click a role to see what an attacker gets if that one credential leaks, tighten a cell, and watch the number fall. Then add an AI agent as a row and see why it quietly becomes the most dangerous identity in the building.

Runs offlineNothing leaves this pageExample company, no real dataVendor neutral

nonereadwriteadminreached after a leak

Add an AI assistant agent

Click a row name to select an identity. Click any square to cycle it through none, read, write, admin. Two presets show the same company before and after a least-privilege review. A dashed red outline marks a separation-of-duties violation.

Separation of duties in one picture

Least privilege asks how much one identity can do. Separation of duties asks what two powers must never sit in the same hands, because together they let one person both commit a fraud and hide it. Two rules cover most of the damage in a small company. Both are checked live against the matrix above.

What a company must do and prove

An auditor working to SOC 2 or ISO 27001 does not ask whether you believe in least privilege. They ask for the matrix, the reviews, and the evidence that leavers actually lost access. The same questions now apply to service accounts and AI agents, and that is where most companies have nothing to show.

Have

An access matrix that exists and is owned

One table, one owner. Every system, every role, every level, in one place. A named person owns it and signs off changes.
Non-human rows included. Service accounts, CI runners, integrations and AI agents are identities. If they are not in the matrix, they are not controlled.
Written SoD rules. The pairs that must never coexist are listed, not just understood.

AI agentsEach agent workflow gets its own identity and its own row. "Uses the engineer's token" is not a row, it is a finding.

Review access on a schedule and at every change

Quarterly access reviews. Each system owner confirms every identity still needs its level. Removals are actioned, not noted.
Joiner, mover, leaver. A ticket for every grant, a re-review on every role change, and a same-day revoke on exit. Movers are where over-privilege accumulates.
SoD enforced in tooling. The rules live in the identity provider or the access tool, so a grant that would violate them is blocked, not discovered later.

Evidence producedReview sign-offs with dates, the JML ticket trail, and the export of the enforced rule set.

Prove

What an auditor samples

Pick ten identities. Compare the matrix to what the systems actually report. Every difference is a finding.
Pick five leavers. Show the exit date and the revoke timestamp on every system, including the ones with local accounts.
Pick two SoD rules. Show the tool that enforces them and the log of any exception, with who approved it and when it expires.
Pick one agent. Show its own credential, its scope, its expiry and the last review that covered it.

Where this mapsSOC 2 logical access and segregation of duties criteria; ISO 27001 controls for access rights, privileged access and access review.

The matrix is not paperwork. It is the only place where the question "what happens if this one credential leaks" has an answer before it happens.

How we workWe draw the matrix first, with the engineers and the finance lead in the same room, then wire the rules into the identity provider so the picture stays true without anyone remembering to update it.

More explained