1Password integrations and automation

Automating 1Password is mostly about visibility and hygiene rather than moving secrets around. Security teams want to know who signed in from where, which shared items were used, and what changed in account settings, and they want that in the tools they already watch. The 1Password Events API is built for exactly this: it returns sign-in attempts, item usage in shared vaults, and audit events from a 1Password Business account, and is meant to feed a SIEM or similar.

Access to the Events API is through a bearer token created in an Events Reporting integration, scoped to the event types you choose. 1Password documents the endpoints as POST requests that take a start time or a cursor and return events plus a new cursor, so a scheduled workflow should save the cursor after each run and resume from it. Without that, it will either miss events or report the same ones twice. Item usage events identify the item and vault and the action taken, such as reveal or copy; they do not include the secret itself.

This is Business-account functionality: 1Password describes the Events API in terms of a 1Password Business account, so confirm Events Reporting appears in your account’s integrations before planning around it. Each token can be checked with the introspect endpoint, which lists the event types it is allowed to read, a quick way to find out why a request returns nothing.

Keep secrets out of workflow output. A digest that lists “item X in vault Finance was revealed by user Y” is useful; anything that would place a password or token into a chat message, document or log defeats the point, and run logs are kept for days or weeks depending on plan. Rules such as “more than five failed sign-ins for one user in an hour” are deterministic counts and suit a scheduled check.