The label on the credential is not the scope of the credential.

The crypto is bulletproof. RFC 5054 SRP-6a, AES-256-GCM, constant-time comparisons, zero-knowledge proof. 1Password got the cryptography right. What they got wrong is the label on the tin.

This month, two engineers at Token Security spent three days reverse-engineering 1Password's proprietary SRP authentication protocol. They were not looking for a vulnerability. They were trying to replace a SCIM bridge with a Python client for non-human identity tooling. What they found was a gap between what the credential says it can do and what it actually can do [1][2].

A service-account token scoped to one vault, with read permissions, can list every user in the organization. Every group. Every group membership. Every vault-level permission across every vault. Names, emails, states, last-auth timestamps. The token's label says "one vault." The API says otherwise [1].

1Password confirmed. The behavior is by design. Granular scoping is on the roadmap with no date [2].

What the token actually reaches

Gil Portnoy and Henry, writing for Token Security, documented five API endpoints that a "one-vault" service-account token can hit with full success [1]:

/api/v2/users returns every user in the organization: UUID, name, email, state, type, last authentication timestamp. /api/v1/groups returns every group with its permissions and state. The CLI commands for group membership, vault users and permissions, and vault groups all return live data. /api/v3/account returns account metadata. /api/v2/vault/{id}/vaultaccess returns vault access information.

None of these endpoints are scoped to the single vault the token was provisioned for. The token was told "read one vault." The API gave it a map of the entire organization [1].

Here is the sharper point: the enumeration does not work through 1Password's official SDK. That path returns UNSUPPORTED or FORBIDDEN. It works through the CLI's internal API, which the researchers had to reverse-engineer. The "scope" is a client-side SDK restriction. The underlying credential is org-wide read. An attacker does not use your SDK [1].

The researchers built the client in roughly 420 lines of Python. Five API endpoints. Full org visibility. They published the write-up on July 16 [1].

The lock is not the problem. The keyring is.

The researchers are careful on this point. The cryptography is genuinely strong. The SRP implementation uses RFC-standardized zero-knowledge proof: the server never sees the password, the client never sees the salt, and every authentication failure returns the same error message so an attacker learns nothing. 1Password documented their own non-standard deviations (including a Beatles lyric from "Penny Lane" buried in a cryptographic constant as an easter egg) and the deviations are security-neutral [1].

The problem is not the lock. It is what the key opens. When a credential is labeled "scoped to one vault," administrators provision agents with it believing the blast radius is narrow. The agent gets a credential. The credential gets the org chart. Nobody intended that, but nobody can see it happening either [1].

When you give an agent a "scoped" token, the agent operates within whatever scope the API actually enforces, not the scope the label describes. If the agent is compromised, through a prompt injection, a poisoned convention file, a supply-chain attack, or any of the vectors that text-based defenses cannot fully close, the attacker does not get one vault. They get the organizational topology: who is in which group, who has access to which vaults, when each person last authenticated. That is the reconnaissance phase of a breach, delivered in a single API call [1].

The gap between documented scope and effective scope is not unique to 1Password. Every credential management API makes implicit authorization decisions that administrators never see. What Token Security proved is that the gap is real, measurable, and exploitable with a weekend of work and a Frida hook [1].

What a vault built for this does differently

The credential's job is to survive the world it sits in. If a "scoped" token can silently map your organization, the scope was never real. It was a label.

Clavitor does not label credentials and hope. The agent gets one explicitly named credential, fetched live at the instant of the call, injected into a single request, and gone. There is no standing token for an attacker to reuse. There is no org-map endpoint behind a scope label that nobody verified. The vault does not expose enumeration to the agent. The agent reaches what it was named to reach, and nothing else.

Every access is logged to the specific agent that made it, on the vault, not on the endpoint the agent runs on. If a token is compromised, the blast radius is the scope of that one call, not the organizational topology behind it.

The principles behind a vault that enforces scope, not labels it: The Ten Rules of Credential Management

Clavitor (@clavitorai) is the credential vault built for AI agents, and against them. clavitor.ai

Sources

[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — X thread on the scope escalation finding, July 16, 2026 — "1Password confirmed this is by design, to support vault-management workflows"