# Staff access log

> Each time INFRO staff open or change something of your organization in INFRO's operations console: what, when, the staff role, and the outcome, kept for 400 days.

Source: https://infro.io/docs/security/staff-access

> **Warning:** **On the roadmap — not available yet.** The staff access log is built and in testing, and not deployed. This page describes what it will ship with.

INFRO's staff work in a separate operations console, with their own accounts. The **staff access log** lists, on your Security screen, each time one of them opened or changed something of your organization there: your organization's details, its members, keys, connections, subscription, a request, a Studio asset or a support ticket. It is on every plan.

## What each entry says

| Field | What it is |
| --- | --- |
| `kind` | `read` (something was opened) or `action` (something was changed). |
| `description` | What it was, in words: "Viewed the organization's details", "Revoked a gateway key", "Placed an operator hold on the organization". A route without its own wording reads "Viewed in the operations console" or "Changed in the operations console". |
| `method`, `route` | The operations-console request, with every id replaced by `:id` (`DELETE /ops/organizations/:id/keys/:id`). |
| `operator_role` | The staff member's role: `ops-admin`, `ops-engineer`, `finance` or `service`. |
| `operator_ref` | A reference to the staff member, the same on every entry they made for your organization and different in every other organization. It tells two people apart; it never names them. |
| `status` | The HTTP status the operations console got. A refused attempt is listed too. |
| `count`, `first_at`, `last_at` | Reads are folded into one entry per staff member, route and UTC hour, with how many times; an action is one entry each. |

Entries never carry the staff member's name or address, or what a request sent. They are kept for 400 days.

## What is attributed to you

An entry is written when the operations-console request names your organization: a page of your organization (`/ops/organizations/{id}`, its subscription), a list narrowed to it (`?organization_id=`), or one of your records by its id (a request, a connection, a Studio asset or preservation, a support ticket). Opening a person's account is attributed to every organization they are a member of.

- Views across every customer at once (the unfiltered request log, traffic, operator alerts, the email log) are not listed per organization: they are staff's working views, and an entry per organization per page would say nothing about whose data was looked at closely.
- Staff pages keyed by something other than your records (announcements, provider applications, startup applications, sign-up grants) are not attributed.
- Entries are written after the request, in the background; an entry that fails to write is dropped rather than slowing staff down. An id that names no organization writes nothing.

## Who sees it

Everyone who opens the [Security screen](https://infro.io/docs/security) organization-wide: owners, admins, Security members, developers, analysts and finance members. Members limited to some projects and creators do not. Staff access is also a stream of the [SIEM export](https://infro.io/docs/security/siem-export).

## API

Through the console session: `GET /console/security/staff-access` with `days` (1 to 400, default 90), `kind` (`read` or `action`) and `limit` (1 to 1,000, default 200) returns `{days, data}`, newest first. Each entry has `id`, `kind`, `method`, `route`, `description`, `operator_role`, `operator_ref`, `status`, `count`, `first_at` and `last_at`. An unknown `kind` is `400` `invalid_request`; a member limited to projects is refused with `403` `project_restricted`.

With a [management token](https://infro.io/docs/manage/tokens) holding `security:read` (the management API, on the Startup plan and up), the same list is `GET /manage/v1/security/staff_access`, as `{object: "list", days, data}`, with the same parameters. A project-restricted token is refused.