What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Permetra is an announced open-source project intended to help answer a difficult Supabase security question: Who can access what in your Supabase application, and why? Its author, Oussama Larhnimi, describes an interactive graph for exploring access relationships. The first version was still being built in his September 20, 2026 announcement, so the described features are goals—not verified, released capabilities.
What Permetra aims to do
Larhnimi frames the problem as a fragmented view of authorization: relevant facts can span users, roles, tenants, database grants, tables, functions, and Row Level Security (RLS) policies. Permetra is intended to bring those relationships into an interactive, BloodHound-inspired graph, so developers and security teams can explore how access connects a person or role to a resource.
As an Amazon Associate I earn from qualifying purchases.
The announced goals include visualizing users, roles, tenants, tables, policies, and permissions; showing why a user can reach a resource; surfacing unexpected access paths; and helping teams review tenant isolation and authorization. These are proposed uses. The announcement does not report detection results or demonstrate that the graph has been tested against real Supabase projects. Larhnimi’s announcement asks which detections readers would want first, indicating that detection priorities were still being solicited.
Why Supabase access is more than a list of roles
An access graph would need to distinguish several layers that answer different questions. A role name alone cannot explain the complete route from an application request to permitted data.
#1 Best Overall
| Layer | What it governs | Why it matters to an access explanation |
|---|---|---|
| Postgres roles and grants | Database-level permissions on objects such as tables, views, functions, and triggers. Roles can inherit permissions from parent roles. | A user’s effective database access may derive from grants and inherited roles, not only from a directly assigned permission. Supabase documents Postgres roles and grants. |
| Row Level Security (RLS) | Policies governing which rows an application-facing database role can access. Supabase recommends RLS for application access; role-based access control can be implemented on top of it. | A table-level grant does not, by itself, explain which rows a request may read or change. The applicable policy context matters. Supabase’s role guidance describes this relationship. |
| API keys and signed-in identity | API keys identify the application component accessing a project; Supabase Auth identifies the signed-in human user. | Knowing which key made a request is different from knowing which user is represented by its authentication context. Supabase’s API key guidance distinguishes the two. |
| Organization and project membership | Who can manage or view Supabase organizations and projects in the platform. | Dashboard or project access is distinct from authorization to rows in an application database. Supabase’s platform access-control guide covers these membership roles. |
Database roles and RLS policies
Supabase documents built-in Postgres roles including anon for unauthenticated API access, authenticated for signed-in access, and service_role for elevated API access that bypasses RLS. The authenticator role validates a JWT and changes into a role selected through JWT verification. Those roles operate within the database access model; they are not the same as a person’s organization or project role in the Supabase Dashboard.
RLS adds row-level rules to application access. A useful explanation of a path therefore needs to account for both permission to reach a database object and the policies that constrain rows. It also needs to recognize privileged routes: Supabase says service_role bypasses RLS, so a graph focused only on user-facing policies could miss a consequential access path.
API keys identify a component, not a person
Supabase’s API key guidance makes a practical distinction: the key identifies what is accessing the project, while Supabase Auth identifies who is accessing it when signed in. Publishable keys are low-privilege and intended for public components. Secret keys are elevated, intended for backend components that perform their own authorization checks, and bypass RLS. Supabase also lists the legacy anon and service_role keys.
Recommended Free Tools
That distinction matters when interpreting a graph. A key’s presence does not by itself establish which human user made a request or whether application-level checks ran. A secret key or service_role path deserves particular care because it can bypass RLS.
Platform membership is a separate authorization question
Supabase lists Owner, Administrator, Developer, and Read-Only as organization or project membership roles. Organization-scoped roles apply across current and future projects; project-scoped members are limited to assigned projects and cannot see other projects in the Dashboard. Read-Only and project-scoped roles are available on Team and Enterprise plans, according to the Supabase access-control documentation.
These controls determine access to Supabase’s platform and projects, not which rows an application user can access. They should be analyzed as a distinct layer rather than folded into Postgres roles or RLS.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What is known—and not yet established—about Permetra
The project is an early-stage proposal, not a documented released product. In the September 20, 2026 post, Larhnimi wrote: “I’m still building the first version and would love feedback from Supabase developers, security engineers, and open-source contributors.” The announcement presents the project as open-source and invites feedback and contributors, but does not establish a public release, repository, license, implementation walkthrough, or test results.
It also does not specify how Permetra would connect to a Supabase project, which credentials it would require, what data it would read or retain, or how it would handle elevated secrets. Those details matter before evaluating an integration: a tool that reads configuration needs appropriately scoped access, and its treatment of sensitive credentials should be clear.
Supabase’s scoped personal access tokens can grant read or read-write access to specified resource classes. Management API requests fail if a token lacks the required permission; the permissions needed for supabase link, for example, differ from those needed for database commands. This is relevant context for assessing a future integration, not evidence that Permetra uses personal access tokens. See the Supabase personal access token guide.
What to look for as the project develops
For a graph to be useful in a real security review, the key question is not simply whether it draws connections, but whether it can support a trustworthy explanation of access. As Permetra develops, readers evaluating its claims can look for clear answers to these questions:
- Which permission sources does it ingest—Postgres grants and role inheritance, RLS policies, identity claims, API-key paths, and platform membership?
- Can each displayed access path be traced to the underlying grant, policy, role, or configuration that explains it?
- Does it distinguish a static configuration finding from behavior verified through runtime requests?
- What credential scope does the integration need, and how are elevated secrets handled?
- Is it run locally or hosted, and what project data leaves the user’s environment?
- Is there a public repository, license, release history, and documented maintenance status?
These are evaluation criteria, not capabilities confirmed by the announcement. Larhnimi’s request for feedback makes Supabase developers, security engineers, and open-source contributors the natural audience for helping shape priorities while the first version is under development.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
