Understanding the Problem

"Who has access to what?" sounds like a simple question, but inside a growing company it becomes one of the hardest questions to answer. Modern 1Password tenants contain hundreds of vaults, thousands of secrets, multiple user groups, direct and inherited permissions, and a constantly shifting landscape of roles and responsibilities. Over time, access becomes layered, inconsistent and difficult to reason about. The points below outline why determining who can access which secrets is far more complex than it appears.

1. 1Password permission structures become complex very quicklyAs companies scale, so do their vaults, groups and user bases. Access in 1Password is granted through multiple vectors at once: direct user permissions on vaults, group-based permissions that inherit to users, and different permission types such as "manage vault," "create items," "edit," "copy," "export," or "view/reveal." On top of that, many organizations use their own identity providers and manage parts of access and group membership outside of 1Password, adding another layer of indirection. The more broadly 1Password is adopted — which is exactly what you want from a security perspective — the more these permission vectors multiply, until the overall structure is difficult to understand, visualize or reason about. This growing complexity creates a very real need for clarity.
2. Permissions are granted both directly and indirectly, often at the same timeA user may receive access through direct assignment, through one or several groups, or through a combination of both. These layers stack and overlap, and they evolve over time as teams grow, reorganize or bring in contractors. Over time, this creates a dense permissions graph where even experienced administrators struggle to determine why a user has certain access, whether those permissions still reflect operational need, or where duplicate or redundant assignments should be removed. Without a clear view of how direct and inherited permissions interact, it becomes nearly impossible to maintain a clean, consistent access model.
3. Vault-level permissions ignore how items differ in sensitivity (impact of compromise)1Password's permission model treats all items within a vault uniformly, but the secrets inside rarely share the same risk profile. One vault might contain low-impact entries — for example, credentials for a tool used to order office supplies — alongside high-impact items such as production database passwords, API tokens for core services, or cloud admin accounts. If a user has access to the vault, they have access to all of it, regardless of how damaging a compromise of each item would be. Without looking at access through the lens of impact of compromise, it becomes very hard to decide how tightly access should be controlled — and whether a given permission is reasonable or already excessive.
4. Excessive permissions are difficult to identifyIn theory, a user having broad access does not automatically make the permission inappropriate — for example, it is normal for senior engineers, SREs or CTOs to have wide-reaching permissions even if they rarely access those items. In practice, however, this ambiguity makes it unclear whether a permission reflects actual operational need or is simply the result of gradual accumulation over time. Without visibility into real access paths and usage, the distinction cannot be made reliably.
5. "Who has access to what?" must also answer what those secrets actually controlAccess in 1Password is not just access to items in a vault — it is access to the systems those items unlock. A single secret might control an admin login to a SaaS platform, a production database, a private API, a VPN entry point or an operating system account on a critical server. In practice, item names are often inconsistent, informal or outdated, which makes it hard to see what asset sits behind a given credential and how serious an impact its compromise would have. Without linking permissions to the underlying assets and their impact of compromise, it is almost impossible to prioritise which access really matters and where tighter control is required.
6. Access reviews are almost never done on secretlevelISO 27001, SOC 2 and similar standards expect organizations to regularly review who has access to what, and many companies do run formal access reviews with professional tooling to certify who belongs in which AD group, which cloud IAM role or which SaaS entitlement. But reviews at this RBAC level simply do not cover who can use which SSH keys, API credentials, database passwords or MFA backup codes — even though these are the things that actually open production systems, tunnels and admin panels. At the scale of thousands of secrets, this layer is effectively invisible in most access review processes.
7. Permission creep accumulates silently — and people are reluctant to remove accessAs responsibilities shift, teams reorganize, or projects evolve, permissions tend to accumulate rather than shrink. Once a user has broad access, administrators are often reluctant to remove it for fear of breaking workflows or blocking the business. Without clear visibility and confidence, reducing permissions feels risky, so permissions expand indefinitely. The lack of safe, data-backed cleanup leads to long-term overexposure across many vaults.

How Gorilla solves it

Gorilla's first contribution to this problem is clarity. It takes the dense web of vaults, groups, users and permission types inside your 1Password tenant and turns it into something you can actually see and talk about. Gorilla builds permission graphs for users, groups, vaults and items, so you can inspect how access is granted — directly, through groups, or through a mix of both — and understand which permissions exist where. That makes reviews practical for the first time: instead of guessing, you can sit down with a team and look at a shared, visual representation of who has access to what.

On top of that, Gorilla surfaces Findings for access patterns that look risky or unnecessary. Items can be marked as high-priority based on what they unlock, and Gorilla flags users who retain broad permissions to those items without ever using them over long periods of time. By correlating access paths with real activity — which permissions are actually exercised, not just theoretically granted — Gorilla helps distinguish between access that is operationally required and access that has simply accumulated. The goal is not to auto-correct your permissions model, but to give you enough transparency and context to review it with confidence and reduce excessive access where it clearly no longer makes sense.