1Password stores the credentials your agents need to authenticate with external services: API keys, OAuth tokens, database passwords, and service account secrets. When an OpenClaw agent retrieves a secret from 1Password via official API, the risk is not the vault itself but the execution layer around it: a misconfigured skill or malicious plugin can exfiltrate, over-scope, or replay those credentials without constraint. The fix is policy-as-code enforcement through Work Policy Contracts (WPC), scoped tokens (CST), and gateway receipts, not prompt-level instructions that the model can ignore.
1Password can be connected via official API with enterprise buildout controls. It is not available as a native connector today. Write and admin actions require WPC approval gates, scoped tokens, and explicit least-privilege auth scopes.
Step-by-step runbook
- Create a 1Password Service Account. In your 1Password admin console, provision a service account with read-only access to a single vault designated for agent secrets. Do not grant write or admin permissions at this stage.
- Author a WPC for vault access. Define a Work Policy Contract that pins the allowed 1Password vault ID, the permitted operations (read-only item retrieval), and the maximum secret categories the agent may request (e.g.,
API_CREDENTIAL,DATABASE). Register it in the WPC registry served by clawcontrols. - Issue a job-scoped CST. Use clawscope to mint a scoped token bound to the WPC policy hash. The CST restricts the agent session to the specific job and vault scope. Pin the policy hash so the token cannot be reused against a different or relaxed policy.
- Wire the 1Password SDK call through clawproxy. Route the agent's HTTP calls to the 1Password Connect Server or SDK endpoint through clawproxy. This produces gateway receipts for every secret-fetch operation, recording the timestamp, target endpoint, and CST used.
- Enable sandbox isolation. Run the agent session with OpenClaw sandboxing set to
"all"mode. Do not bind-mount the 1Password service account token file into the container; inject it as an environment variable scoped to the sandbox session. - Collect the proof bundle. After the job completes, the harness assembles a proof bundle containing all gateway receipts, the WPC hash, and the CST scope hash. Store the resulting Trust Pulse artifact for audit and replay checks.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Malicious plugin exfiltrates secrets to external endpoint | Plugin reads a vault item, then POSTs the plaintext to an attacker-controlled URL | Egress allowlists (planned, can be implemented outside clawproxy) restrict outbound destinations. Sandbox network isolation limits reachable hosts. |
| Over-scoped service account | Agent retrieves secrets from vaults it should never access (HR, finance, infrastructure) | WPC pins the allowed vault ID and item categories. CST policy hash pinning ensures the token only works against that exact policy. |
| Credential replay across jobs | A CST or fetched secret is reused in a later, unauthorized job | Marketplace anti-replay binding ties the CST to a single job. Gateway receipts record each fetch, making replay detectable in the proof bundle. |
| Prompt injection triggers write operation | Injected prompt convinces agent to update or delete a vault item | WPC explicitly restricts operations to read-only. The 1Password service account itself should have no write grants. Policy-as-code blocks the call before it reaches the vault. |
| Secret logged in model context | Retrieved password appears in model call, persisted in logs | OpenClaw's logging.redactSensitive setting should be active. Gateway receipts record the model call metadata but not the secret payload. |
Prompt-only guardrails ("do not leak secrets") fail because the model has no enforcement mechanism. A WPC is a signed, hash-addressed artifact that the proxy and token issuer verify before the call executes. The model never gets to decide whether the policy applies.
Policy-as-code example
{
"wpc_version": "1.0",
"name": "1password-readonly-agent",
"tool_scope": {
"integration": "onepassword",
"auth_mode": "service_account",
"allowed_vaults": ["vault_agent_secrets_prod"],
"allowed_operations": ["read_item"],
"allowed_categories": ["API_CREDENTIAL", "DATABASE"],
"deny_operations": ["create_item", "update_item", "delete_item"]
},
"cst_constraints": {
"max_ttl_seconds": 900,
"policy_hash_pin": true,
"job_scoped": true
},
"sandbox": {
"mode": "all",
"network_egress": ["connect.1password.com", "api.1password.com"],
"workspace_access": "none"
}
}The deny_operations array is enforced at the WPC level, not as a prompt suggestion. The network_egress field documents the intended allowlist; note that egress allowlists enforced outside clawproxy are planned and can be implemented as part of enterprise buildout.
What proof do you get?
Model-assisted runs that touch 1Password produce gateway receipts and proof bundles for audit and replay checks. Each gateway receipt records the proxied call metadata: target endpoint, HTTP method, timestamp, and the CST that authorized it. Receipts are signed by clawproxy.
The proof bundle aggregates all receipts from the job session, the WPC policy hash, and the CST scope hash into a single verifiable artifact. This bundle can be submitted to clawverify for trust-tier and proof-tier assessment. The resulting Trust Pulse artifact is stored in the marketplace viewer for compliance teams and auditors to inspect.
What you can confirm from the bundle: which vault items were accessed, when, under which policy, and by which scoped token. What you cannot confirm (yet): whether the 1Password Connect Server itself was unmodified. Transparency log inclusion proofs for vault-side operations are planned.
Rollback posture
| Action | Safe rollback | Evidence |
|---|---|---|
| Agent read a secret it should not have | Rotate the exposed credential in 1Password. Revoke the CST via clawscope. Update the WPC to narrow allowed_categories. |
Gateway receipts show exactly which items were fetched and when. |
| Service account was over-scoped | Restrict the 1Password service account to the correct vault. Re-register a tighter WPC. | Proof bundle shows the vault IDs accessed under the old policy. |
| Suspected secret exfiltration | Rotate all secrets in the affected vault. Revoke all active CSTs for the job. Review sandbox network logs. | Gateway receipts plus sandbox logs (if captured) identify the window of exposure. |
| WPC was too permissive | Publish a new WPC version with narrower scope. Old hash becomes invalid for new CST issuance. | WPC registry retains both versions for diff and audit. |
FAQ
Is 1Password integration available as a native connector today?
No. 1Password can be connected via official API with enterprise buildout controls. The integration is planned and uses OAuth, API key, or service account authentication modes. Do not assume out-of-the-box support before release gates pass.
Why can't I just tell the agent "don't leak secrets" in the system prompt?
Prompt instructions are suggestions to the model, not enforcement boundaries. A sufficiently creative prompt injection or a malicious plugin can override them. A WPC is a signed policy artifact verified by clawproxy and clawscope before any call executes. The model never evaluates the policy; the infrastructure does.
Can the agent write to 1Password vaults?
Only if the WPC explicitly allows write operations and the 1Password service account has write grants. The recommended default is read-only. Write and admin actions require WPC approval gates, scoped tokens, and explicit least-privilege auth scopes.
How do I limit which secrets the agent can see?
Use two layers: the 1Password service account should be scoped to a single vault with only the items the agent needs. The WPC should further restrict allowed_categories so the agent cannot request item types outside its task scope.
What happens if the CST expires mid-job?
The clawproxy rejects the next API call with an authorization error. The agent cannot fall back to a cached token because CSTs are job-scoped and verified on each request. The operator must issue a new CST or extend the max_ttl_seconds in the WPC for longer-running jobs.