Investigate 1Password vault changes and sign-ins in one place

Build me an internal security activity console for 1Password that I open through the week to answer who changed what. The 1Password admin console gives almost no visibility into vault permission changes and sends no alert when someone is added to a vault, so this app is where I go to browse and investigate that history. It is an investigation and browsing surface, not an alerting workflow. Give it three tabs across the top: Permission Changes, Sign-ins, and People.

All data comes from the 1Password Events API, so the connected 1Password credential must use an Events API base URL (events.1password.com, or the events.ent.1password.com, events.1password.ca, and events.1password.eu variants) together with an Events Reporting bearer token. A Connect server token will not authenticate against these operations. All three read operations are POST requests that read data and change no state.

The Permission Changes tab is powered by the 1Password List Audit Events operation. Show every vault grant, vault removal, group membership change, and administrator action as a row carrying the actor, the target person or vault, the action type, and the timestamp. Make it sortable by time and filterable by action type and by actor. This tab is the core value of the app, so give its table the most careful design: someone scanning it should be able to answer "who got access to what, and who gave it to them" in seconds.

The Sign-ins tab is powered by the 1Password List Sign-in Attempts operation. Show each attempt with the person, outcome, country, client or device, and timestamp, with filters for outcome, country, client, and person. Add a cluster view toggle that groups repeated failures by account, so one person fat-fingering a password five times in a row reads as a single cluster rather than five separate alarming rows. Each cluster should show the account, how many attempts it covers, the time span, the countries and clients involved, and whether it ended in a successful sign-in.

The People tab is a per-person drill-down. I pick an individual and get one merged chronological timeline stitched from all three sources: their sign-ins from List Sign-in Attempts, their administrative and vault actions from List Audit Events, and their credential accesses from the 1Password List Item Usages operation. Type each entry visually by source so I can read the story of one person in a single scroll, and let me narrow the timeline to the same date range as the other tabs.

Every row in every tab gets two buttons. Share to Slack posts the record plus surrounding context, meaning the handful of events immediately before and after it, to our security channel using the Slack Bot Send a Message operation. Format it for a human reader rather than dumping raw fields. Investigate opens a Jira ticket through the Jira Create Issue operation, prefilled with the event detail, the person involved, and the timestamp, so the ticket arrives with enough context to act on without anyone going back to look it up.

Bake in the cursor behaviour properly. The Events API is cursor-based and the cursor is a durable checkpoint that stays valid across sessions, so persist it per tab on the server and page forward from it instead of refetching the whole history every time the app opens. On the first load for a tab, send a reset cursor request carrying the selected date range, then replay the stored cursor while the response reports there is more to read. Use a page size of 100 (the valid range is 1 to 1000) and stay well under the ceiling of 600 requests per minute, backing off when a rate limit response comes back.

Default every tab to the last seven days, with a date range picker I can widen when I am investigating something older. Changing the range should start a fresh cursor for that tab rather than reusing the stored checkpoint.

Visually flag any action taken with the owner role. Owners have unrestricted vault access and can silently add themselves to any vault at any time, which is the single thing I most want to catch, so make the flag obvious in the table and filterable on its own.

The Events token is scoped per feature, so an account may be granted audit events but not item usage. Detect that and degrade gracefully: a tab whose data type has not been granted should explain which report to enable in 1Password rather than showing an error or an empty table, and the remaining tabs should keep working normally. Keep the layout comfortable on a 13 inch laptop screen, since the 1Password admin console itself gets cramped on smaller displays and this console should not repeat that.