1Password recently announced 1Password Unified Access — an enterprise product positioning the vault as credential infrastructure for AI agents. Endpoint discovery, runtime credential brokering, audit logs, scoped access for autonomous workflows. They also shipped SDKs for Python, JavaScript, and Go so agents can integrate with the vault natively, in-process, without the CLI.
The announcements describe a problem worth solving. They also describe something you can build today, on a personal account, with tools that have existed since 2022.
This is the third post in a series. The first covered what 1Password can replace in a developer setup — SSH keys, git signing, AWS CLI credentials, .env files. The second covered what an AI agent can do when it operates the vault directly — reorganizing 690 credentials in one session. This one is about what the vault enables when agents need to operate everything else.
The problem Unified Access is solving
AWS has a mature credential model. IAM roles, temporary credentials via STS, OIDC federation, resource policies. A GitHub Actions workflow can assume an IAM role directly — no stored credentials, no rotation, nothing to leak. The problem is solved at the infrastructure layer.
The SaaS layer has no equivalent.
Stripe gives you an API key — one key, broad permissions, no expiry unless you rotate it manually. OpenAI is the same. Cloudflare, Twilio, SendGrid, Notion, GitHub — all the same. Flat credentials. No scoping to a specific workflow or agent. No native audit log showing which process called it. No revocation path that doesn’t also break everything else using that key.
As autonomous workflows multiply — deploy pipelines, content agents, data sync jobs, monitoring scripts — each one eventually needs to call something in this layer. And right now, there’s no standard way to give an autonomous process auditable, revokable, scoped access to a Stripe key. You copy the key into an environment variable and hope nothing goes wrong.
Unified Access is 1Password’s enterprise answer to this. The personal account version of the same answer already exists: service accounts.
What a service account actually does
A service account is a token — one credential — that grants access to a scoped set of vault items. You create it with one command:
op service-account create "ACL GitHub Actions" --vault "ACL:read_items" --rawThat token goes into GitHub as a single secret: OP_SERVICE_ACCOUNT_TOKEN. The GitHub Actions workflow uses it to pull every other credential it needs at runtime:
- name: Load credentials from 1Password
uses: 1password/load-secrets-action@v4
with:
export-env: true
env:
OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
AWS_ACCESS_KEY_ID: op://ACL/<item-uuid>/access_key_id
AWS_SECRET_ACCESS_KEY: op://ACL/<item-uuid>/secret_access_key
STRIPE_SECRET_KEY: op://ACL/<item-uuid>/credential
OPENAI_API_KEY: op://ACL/<item-uuid>/credential
CLOUDFLARE_API_TOKEN: op://ACL/<item-uuid>/credentialGitHub doesn’t know any of these values. It knows one token. 1Password resolves the rest at runtime, injects them into the workflow, and discards them when the job exits.
The pattern:
Autonomous workflow
└── OP_SERVICE_ACCOUNT_TOKEN (one secret, scoped, revokable)
├── AWS credentials
├── Stripe key
├── OpenAI key
├── Cloudflare token
└── anything else in the vaultWhat this changes
Attribution. Stripe has no audit log for which process used your API key. 1Password does. Every credential access by the service account is logged — which item, when, from which workflow.
Rotation without workflow changes. Rotate the OpenAI key in the vault. Every workflow that references it picks up the new value automatically. No updating GitHub secrets. No redeploying anything.
Revocation. If a workflow is compromised or a service account is over-permissioned, you revoke the token. One action cuts access to everything it could reach. You don’t have to hunt down every place a key was copied.
One secret in CI instead of ten. The attack surface of your CI environment is one token scoped to read-only vault access, not a collection of long-lived service credentials sitting in GitHub secrets.
None of this requires Unified Access. It works today on a personal 1Password account with the existing CLI.
The SDK: 1Password as a native agent dependency
The CLI pattern works. But there’s a cleaner integration for agents written in Python, JavaScript, or Go: the 1Password SDK.
pip install onepassword-sdkA Python agent resolves secrets directly in-process — no shell subprocess, no op binary call:
import asyncio
import onepassword
async def main():
client = await onepassword.Client.authenticate(
auth=SA_TOKEN, # service account token from environment
integration_name="my-agent",
integration_version="1.0.0",
)
# resolve any secret by op:// reference
aws_key = await client.secrets.resolve("op://ACL/<item-id>/access_key_id")
stripe_key = await client.secrets.resolve("op://ACL/Stripe/credential")
# list items in the vault
items = await client.items.list(vault_id)
for item in items:
print(f"[{item.category}] {item.title}")
asyncio.run(main())Tested against the ACL vault: secret resolution works, item listing works, all 37 items visible. The vault title comes back encrypted at read_items scope — that’s correct behavior, not a bug. A service account scoped to read items doesn’t need vault metadata.
The difference from the CLI: the agent doesn’t shell out. The vault client is a dependency in your code the same way a database client is. Typed responses, native async, no subprocess management. For agents that need to resolve credentials at runtime — not at deploy time — this is the right integration path.
Where AWS fits in
For AWS specifically, you don’t need this pattern — and shouldn’t use it. GitHub Actions has native OIDC federation with AWS. The workflow assumes an IAM role directly. No credentials stored anywhere, not even in 1Password. That’s the correct approach for AWS.
The value of 1Password as a hub is precisely for the services AWS can’t federate with. That’s most of the SaaS layer your workflows touch.
The cleaner architecture: OIDC for AWS, 1Password service account for everything else. One token in GitHub covers the entire non-AWS credential surface.
What 1Password is actually building
Unified Access adds what service accounts don’t have: endpoint discovery (which AI tools and scripts are running on developer machines), credential scanning (finding exposed secrets in local files), and team-scale audit logs with attribution across multiple service accounts and vaults.
For a solo builder, those gaps don’t matter. The service account pattern covers the core use case.
For a team where ten engineers are running autonomous workflows against shared infrastructure — where you need to know which agent accessed which credential, who authorized it, and what it did — the enterprise layer is real. The accountability breakdown Unified Access describes is a genuine problem at scale.
The announcement is a signal, not a product you need. It confirms that the pattern is right. The credential hub model for autonomous workflows is where the market is going. The tooling to build it yourself already exists.
So what
If you’re running autonomous workflows — any CI job, any scheduled script, any agent that calls external services — the credential model matters. Not because of security theater, but because:
- You want to know what your agents accessed
- You want to rotate credentials without touching every workflow that uses them
- You want one place to cut access when something goes wrong
1Password service accounts give you that today, across every SaaS API that doesn’t have its own identity federation model. One token in CI. Everything else in the vault.
That’s infrastructure. Not a password manager.