1Password
Read and manage 1Password vault items through a self-hosted Connect server, and read the account's audit trail through the Events API.
About
1Password ships in the w6w first-party pack. It declares 14 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.onepassword- Version
- 0.1.1
- Author
- w6w
- Licence
- MIT
- Categories
- Security & Identity · Developer Tools
Overview
1Password puts a self-hosted Connect server’s vault items — and, separately, an account’s audit trail — into a workflow. Vault items can be listed and read, one field’s value fetched by name, items created and updated with a targeted patch rather than a full replace, and attachments listed and downloaded; the account’s audit events, item-usage log and sign-in attempts are read through the separate Events API.
This app reads secrets, so it is built around not surfacing them by accident. Reading an item’s structure returns its fields and labels with values redacted; getting an actual secret value is a deliberate, separate step — either revealing everything on the item or, better, fetching exactly one named field so the rest of the item’s secrets never enter the run’s data at all. No action logs a field value, item title or filename.
The audit trail turns credential management into something a workflow can act on, not just store: item-usage records show who opened which secret, in which vault, from where and when — the first place to look after a credential leaks, or when confirming what a departing employee actually read. Sign-in attempts are categorised by failure type, so a run of failed second factors — a working password paired with a wrong code — can be told apart from an ordinary mistyped password and alerted on differently. Deleting an item archives it rather than destroying it, so the credential it held keeps working wherever it was already used until it is separately revoked.
Build with 1Password
Three routes to the same 14 actions. The Workflow tab is generated from 1Password's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
List audit events
audit-event-list What changed in the account — members, vaults, permissions, integrations. Events name uuids rather than people, which is what makes the stream safe to forward.
Create an item
item-create Store a new secret — a rotated key, a generated password. Field TYPE is what makes a value secret: `CONCEALED` is hidden and audited, `STRING` is neither.
Delete an item
item-delete Move an item to the Archive, where an administrator can restore it. It does NOT revoke the credential — that happens wherever the secret was issued.
Get one field's value
item-field-get Fetch a single field — the narrow way to read a secret. The rest of the item never enters the run's data, which `item-get` with reveal cannot avoid.
Get a file's contents
item-file-get An attachment's bytes, base64-encoded. There is nothing to redact — on a credentials item the whole file is the secret, usually a private key or a certificate.
List an item's files
item-file-list Attachments on an item — where certificates and private keys live, since they do not fit in a field. Listing is safe; the bytes are a separate request.
Get an item
item-get One item's fields. Secret values are REDACTED by default — the structure comes back so a workflow can see what exists without the run carrying the secret.
List items
item-list Items in a vault, as summaries — this endpoint NEVER returns field values, whatever they are. Reading a secret always takes a second request for one item.
Update an item
item-update Change part of an item with JSON Patch. This deliberately does not expose the REPLACE endpoint, which silently deletes every field the request omits.
List item usages
item-usage-list Who opened which secret, when, and from where — including reads made through Connect, so this is how an automated consumer of secrets is audited.
List sign-in attempts
signin-attempt-list Every sign-in attempt, successful or not. `mfa_failed` is the one that matters — it means somebody had a working password — and it is counted separately here.
Inspect the Events token
token-introspect What this token may read. Grants are per event kind, so a 403 on one endpoint while the others work is scope rather than a fault.
Get a vault
vault-get One vault's metadata. `contentVersion` changes whenever its contents do, which makes it a cheap way to poll for changes without listing items.
List vaults
vault-list The vaults this token can reach — which IS the token's scope. A vault missing here was never granted, and no permission change will add it; only a new token will.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying 1Password's real ids.
{
"manifestVersion": "2",
"name": "onepassword-example",
"steps": [
{
"id": "item-create",
"uses": {
"app": "io.w6w.onepassword",
"action": "item-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"vaultId": "<vaultId>",
"title": "<title>",
"category": "<category>"
}
}
]
}Here are some of the things you can do
-
Create an item
performitem-create -
List audit events
readaudit-event-list -
Get one field's value
readitem-field-get -
Get a file's contents
readitem-file-get -
List an item's files
readitem-file-list
+9 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for 1Password, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to 1Password. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "item-create",
payload: {
vaultId: "<value>",
title: "<value>",
category: "<value>",
fields: "<value>",
// tags: "<value>",
// urls: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action item-create --payload '{"vaultId":"<value>","title":"<value>","category":"<value>","fields":"<value>"}'Give an AI agent 1Password — without giving it 1Password's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.onepassword#item-create",
"input": {
"vaultId": "<vaultId>",
"title": "<title>",
"category": "<category>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's 1Password connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
What the agent gets
Credentials it can't read
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
A tool surface scoped to the caller
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
A durable workflow in one call
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Health-aware discovery
1Password's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. 1Password itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
1Password declares its own checks, so its health is a property of the app rather than something the host guesses at.
1Password service status
1Password's own status, by region. A Connect server keeps serving its vaults through an outage — it stops receiving updates rather than stopping — so this matters far more to an Events connection than a Connect one.
Credential scope
Whether this connection's service answers and its credential still reaches what it did. A scope that shrank keeps authenticating and starts returning 404s that look like bugs.