Tool 05 · Analysis · Free
Access Control Matrix
The roles × functions table we build by hand in every engagement, generated from your source. It answers the question most teams cannot answer about their own protocol: exactly what can each key do?
At a glance
Access Control Matrix
Run it
Only state-changing external and public functions are listed. View and pure functions are excluded — they are not an authority question.
How it works
What this tool does, and what it can't.
Access control failures are the simplest bug class to describe and among the most expensive in practice, because a modifier is a short token at the end of a signature. When a hundred and ninety functions are guarded correctly, the ten that are not do not look wrong — they look like the others.
The fix is to stop reading and start tabulating. The tool extracts every state-changing external or public function, classifies the guard on it (recognising eighteen common modifier patterns plus in-body require and hasRole checks), and builds the full matrix. Functions with no recognised guard whose names suggest they move value or change configuration are flagged Critical.
It also produces the section most protocols are missing from their documentation: what a compromised privileged key could actually do. Not what the admin is trusted to do — what the key can do if someone else holds it.
A table of roles against functions showing which role can call what. It is the artefact that turns “the owner can update parameters” into a precise, checkable claim — and the disagreements it surfaces between the code and what the team believed are usually the findings.
Deposits, swaps and claims are permissionless by design, and the tool rates those Medium rather than Critical. It escalates only when a function has no guard and a name suggesting it changes configuration or moves value. Each one should still be a deliberate decision you can articulate.
It recognises eighteen common patterns (onlyOwner, onlyRole, onlyKeeper, Solmate and DSAuth styles, initializers and more) plus in-body checks. Anything else is listed separately as unrecognised, because a custom modifier is exactly where a subtle authorisation bug hides — the tool will not guess at what yours does.
Bound every parameter in code — a fee setter with no maximum is a drain function with extra steps. Timelock the dangerous paths. Split operational keys from upgrade keys. Emit an event on every privileged change so monitoring is possible. And publish the capability list, because users cannot assess a risk they have not been told about.
Not automatically — but that comparison is the point. Generate the matrix, then read it next to what your docs claim the admin can do. In our engagements, that gap is where the finding is.
Beyond automation
No tool reads your specification. We do.
The findings that drain protocols come from state assumptions, economic design and cross-contract interaction — none of which a scanner sees. Free scoping in under two working days.