The Same Pattern, From Solo Builder to Enterprise Scale

TL;DR

• The same vault-and-IdP architecture — 1Password as source, OAuth/OIDC as authorization plane, M2M clients per agent — works unchanged from one person to 10,000.
• Adding a second person means new M2M clients, an owner JWT claim, and scoped grants; the protected APIs don’t change at all.
• At enterprise scale, SCIM handles provisioning and deprovisioning automatically — no credentials left behind when someone leaves.
• Credentials always flow one direction: vault → services, never the reverse.
• Build the pattern for yourself today; your team inherits it without a rewrite.

The previous four posts in this series established a credential pattern: 1Password as the source, an OAuth/OIDC provider as the authorization plane, M2M clients for agents, and protected APIs as the resource layer. One vault, one tenant, separate clients for interactive vs autonomous use.

The question this post answers: what changes when you add people?

The short answer: less than you think.

What the solo pattern looks like

Before scaling it, here’s the full stack at one-person scale:

1Password vault
  └── M2M secrets, API keys, TOTP secrets

OAuth/OIDC tenant (e.g. Auth0)
  ├── owner@example.com              (human identity)
  ├── agent-m2m-interactive          (interactive sessions)
  └── agent-m2m-autonomous           (scheduled / headless agents)
        └── JWT claims: owner + agent_type + scopes

Protected APIs / tools
  └── whatever your agents call (search, deploy, data, etc.)

Every caller — an IDE agent, a LangGraph workflow, GitHub Actions, a cron job — authenticates the same way: get a token from the IdP, call the API with it. No credential files on disk. No secrets in the repo. The tools follow the identity, not the device.

The human is the policy layer. The agent is the execution layer. 1Password is the trust boundary. Touch ID once per session. Everything else runs.

Adding a second person

Say someone else joins. They sign in with Google or corporate SSO — the IdP handles it. What you provision for them:

1. M2M clients — client credentials stored in their vault (1Password or equivalent). One for interactive use, one for autonomous agents.
2. JWT claims — owner: their@email.com injected via an IdP Action or rule that stamps tokens at issuance.
3. Scopes — what APIs their agents can call. Read-only vs write access. Explicit grants per M2M client, not inherited from the owner’s full access.

The protected APIs don’t change. The IdP tenant gets new clients and grants. That’s the entire delta.

The second person’s autonomous agents can only call what their M2M clients are authorized to call — not everything the human identity can do. The authorization model enforces the separation. You don’t write custom code to make this true; it’s how OAuth scopes work.

At team scale

Ten people, each with the same structure: a human identity, an interactive M2M client, an autonomous M2M client. Each with an owner claim pointing back to their identity. Each with explicitly granted scopes.

What changes at this scale:

IdP Organizations. Instead of a flat tenant, you create an Organization — a named group with its own role assignments, branding, and SSO configuration. Members belong to the Organization. Permissions attach to membership, not just to individual client grants.

1Password Teams. The vault structure scales with the team. Each person’s M2M secrets live in their own vault. Shared infrastructure secrets (tenant domain, shared API keys) live in a shared vault with scoped access. The vault is still the source — nothing changes about the credential model, only who has access to which vault.

Audit trail. The IdP logs every token issuance. 1Password Teams logs every vault access. Every API call is traceable: which M2M client called it, which identity owned that client, at what time. No additional instrumentation required.

What scales is the authorization layer and vault access policy. The protected APIs stay the same.

At enterprise scale

SSO via SAML or OIDC federation. Users authenticate through their company IdP — Okta, Azure AD, whatever they already have. Your authorization tenant federates with it. Protected APIs still validate the same JWT claims.

SCIM provisioning. When someone joins the company, their identity is provisioned automatically. When they leave, it’s deprovisioned. The M2M clients associated with their identity are revoked. No manual cleanup, no credentials left behind.

1Password Business. Enterprise vault management, centralized policy, integration with SSO so vault access is gated by the same identity provider as everything else. The credential pattern from post one is unchanged — the agent still reads secrets the same way. The difference is that IT manages who has access to which vault, not the individual.

At this scale, the gap that 1Password Unified Access (described in post three) addresses becomes real: endpoint discovery, credential scanning across developer machines, runtime brokering with team-scale audit logs. The enterprise product fills in what the personal account doesn’t cover.

But the pattern is identical. APIs validate JWTs. JWTs come from the IdP. The IdP federates with whatever identity system the company runs. The protected resources have no idea whether the caller is a solo builder or a member of a 10,000-person enterprise. They see a validated token with claims. That’s all they need.

What never changes

Across all three scales — solo, team, enterprise — these things are constant:

• Credentials originate in the vault. They flow outward to services. They never flow the other direction.
• Agents authenticate with M2M clients scoped to what they’re allowed to do.
• JWTs carry identity and scope claims. Authorization is in the token, not hardcoded in each tool.
• The human approves at the policy level. Agents execute. The vault is the boundary.
• Tool definitions are independent of who’s calling. Adding a user doesn’t change what the tools do.

The activation energy to start: one vault, one IdP tenant, scoped M2M clients. The ceiling: enterprise SSO, SCIM, audit logs, multi-org. Nothing between start and ceiling requires a rewrite of the credential model.

So what

Most infrastructure patterns work at one scale and break at another. You build for a team and then spend months re-platforming for enterprise. Or you over-engineer for scale you don’t have yet and spend months building infrastructure that’s unused.

This pattern avoids that because the scaling axis is the IdP and 1Password — services already built to handle every scale. Protected APIs are stateless consumers of tokens. The only stateful components are the identity plane and the credential store, and both have clear scaling paths.

If you work in this stack as a solo builder: the pattern that works for you today is the same pattern your team will use, and the same pattern enterprise deploys. The only thing that changes when you add users is how the IdP is configured and who has access to which vault.

The architecture doesn’t change. That’s the point.

This is the fifth post in a six-post series on 1Password as infrastructure. The sixth covers op run — making any tool vault-transparent. Start from the first post.