1Password just bought into the credential broker category for AI agents
7 min read Fullmakt Team
- agents
- credentials
- security
- 1password
- industry
On June 15, 2026, 1Password — the company that taught a generation of people to stop reusing passwords — acquired Apono, a just-in-time access vendor, and shipped a new product it calls the 1Password Credential Broker. The deal was reported to be worth somewhere in the range of $250–300 million. The product name is worth reading twice, because it is the same phrase we use to describe what Fullmakt is.
When an incumbent that size spends that kind of money and ships a product named “credential broker” for humans, machines, and AI agents, a debate quietly ends. The question is no longer whether agents should be handed standing API keys. That argument is settled. The interesting questions are the ones that come next.
Why agents broke credential management in the first place
We have spent years getting reasonably good at giving people the right amount of access. Agents are different in three ways that make the old habits dangerous, and we wrote about this in detail when we argued for scoped credentials:
- They act fast and unattended. A misused human credential might do damage for a few minutes before someone notices. An agent loop can make thousands of calls before anyone looks up.
- Their instructions are attacker-reachable. Prompt injection means the thing deciding how to use a credential can be steered by untrusted input — a web page, a document, a tool result.
- They fan out. One agent calls another, which calls a tool, which calls an API. Scope has to travel with the request; it cannot live in one shared secret pasted into an environment variable.
Through 2026 all three pressures have only grown. There are now more non-human identities in many organizations than human ones, each capable of acting on its own, and the blast radius of a single leaked long-lived key keeps expanding. The fix was never “be more careful with keys.” It was to stop issuing standing keys to agents at all. That is exactly the conclusion 1Password just put real money behind.
What 1Password actually shipped
Two things arrived together, and they are worth describing accurately.
Apono brings just-in-time access governance. Instead of granting an identity standing permissions, an agent (or human, or workload) requests access — Apono’s model has agents supply a natural-language description of why they need it — and the platform analyzes the request, provisions time-boxed access, and revokes it automatically when the work is done. The pitch is governing what every identity can reach: when, why, and for how long.
The 1Password Credential Broker, launching in private beta, keeps secrets in 1Password’s zero-knowledge vault and releases an approved credential to a verified requester only at the moment it is needed. It begins with GitHub Actions workload identity and is intended to extend across humans, machine workloads, and AI agents over time. The framing 1Password uses for the combined direction is becoming the control plane for businesses running agentic AI.
This is a good product direction and a genuine validation of the category. Credit where it is due: vaulting secrets, evaluating the request for access, and handing out short-lived credentials just-in-time is a large improvement over the copy-paste-a-key status quo.
“Credential broker” now means two different things
As the term goes mainstream, it is quietly splitting into two postures that solve related but distinct problems. The distinction is the same control plane vs. data plane split we drew when comparing Fullmakt to Auth0.
- Broker at issuance. Vault the secret, evaluate the request for access, then release a real (often short-lived) credential to a verified requester just in time, and revoke it later. The control point is issuance. This is the 1Password/Apono posture, and it is strong at deciding who gets what, when, and for how long.
- Broker every call. The model never receives the real secret at all. The broker injects it at the edge on each outbound call, checks that specific call against policy — endpoint, method, rate, data class — and writes a tamper-evident record. The control point is every request. This is the Fullmakt posture.
Neither is “the right answer.” They answer two different questions, and the strongest setups use both.
| Dimension | Broker at issuance (1Password / Apono posture) | Broker every call (Fullmakt posture) |
|---|---|---|
| Control point | The request for access | Every outbound agent call |
| Where the secret lives | Released to a verified requester JIT; the agent holds it for the window | Injected at the edge per call; the model never holds it |
| Policy granularity | Per grant (who, why, how long) | Per call (endpoint, method, rate, data class) |
| Revocation | Expire or revoke the grant | Disable the principal or rotate the secret — the next call stops, no agent redeploy |
| Audit | Access-grant logs | Cryptographically chained, tamper-evident record of every call |
| Native surface | Vault + workload identity (GitHub Actions at launch) | MCP- and OAuth-native; bring your own IdP and vault |
| Plane | Control plane | Data plane |
The challenges still coming
Settling “no standing keys” does not settle everything. A few problems live specifically at the per-call layer, and they get harder as agents get more capable:
- A short-lived secret is still a secret the agent holds. While it is live, it is reachable by whatever is steering the agent — including a prompt injection. Time-boxing shrinks the window; it does not remove the secret from the model’s reach. Keeping the credential out of the agent entirely closes a door that JIT issuance leaves ajar.
- Per-grant policy is coarse for agents that chain tools. An agent given “read access to the billing API for 30 minutes” can still make every call that scope allows. As agents compose tools over MCP, you increasingly want to evaluate the individual call, not just the grant that preceded a burst of them.
- Audit has to survive fan-out. When one agent delegates to another, “which agent did what, on whose behalf, and was it allowed?” needs a provable answer that spans the whole chain — not a log per service that someone later stitches together by hand.
- Revocation should not require a redeploy. If stopping an agent means rotating a key and pushing new config to every agent that held it, you will be slow exactly when you need to be fast.
- Attribution depends on never sharing keys. The moment two agents share a credential, you lose the ability to say which one acted. Per-agent identity is what makes the audit trail mean anything.
Where Fullmakt fits
Fullmakt is enforcement-first and lives in the data plane. The model never sees the real secret; the broker injects it at the edge on each call, checks that call against policy, and writes it to a cryptographically chained, tamper-evident log. It is MCP- and OAuth-native and designed to sit on top of whatever identity provider and vault you already run.
That last part matters here. A vault-and-JIT-issuance layer and a broker-every-call layer are not competitors so much as two floors of the same building. You can let a control-plane product decide who may obtain access to what, and for how long, and let a data-plane broker enforce and record what actually happens on every call once an agent is acting. Identity and issuance on one floor; per-call enforcement and proof on the other.
So if you read the 1Password headline and wondered whether the thing you were already evaluating is now redundant — it probably is not. The acquisition is the clearest signal yet that brokered, just-in-time, revocable access is how agents should work. The open question for your own stack is no longer should agents hold standing keys. It is at which layer do you broker — at issuance, on every call, or both?