# Audit log and Buff Code

> What around Buff Code goes into the audit log: device sign-in and revocation, viewing others’ sessions, exports, questions, knowledge — with severity.

The organisation’s [audit log](/en/docs/audit-log) records **people’s actions** around Buff Code.
The contents of the sessions themselves — the model’s requests and answers — do not go into it: that is what
[session records](/en/docs/buff-code/sessions) are for, and the log answers the question “who did what”.

## What is recorded

| Event code | What is recorded | Severity | When |
| --- | --- | --- | --- |
| `session.device_approve` | Buff Code device sign-in allowed | notice | a person clicked “Allow sign-in” on the sign-in page; the event has the device name and the organisation |
| `session.device_deny` | Device sign-in denied | notice | a person clicked “It wasn’t me”; the event has the device name |
| `session.device_revoke` | Device revoked | notice | the “Revoke” button on the sign-in page; the event has the device |
| `session.device_refresh_denied` | Device token refresh refused | warning | only on refusal: the device is already revoked, the signature did not match or the person has no access left |
| `session.device_reuse_revoked` | Device revoked: refresh token reused | warning | an already spent token was presented again — this happens when a token is stolen; the device is revoked immediately |
| `ide.session_view` | **Someone else’s** development session viewed | notice | the owner opened another developer’s session |
| `ide.session_export` | Development session exported | notice | any Markdown or JSON export, of your own session or someone else’s |
| `ask.create` | “Ask” conversation about development sessions created | info | a question about sessions; the details hold the identifiers of the sessions in the set |
| `knowledge.create` | Knowledge “…” created from Buff Code | info | the developer confirmed an entry [proposed by the model](/en/docs/buff-code/knowledge) |

The full catalogue with operation and severity — [Event catalogue](/en/docs/audit-log/events).

## Viewing and exporting: how they are counted

- **One entry per read, not per page.** A long session arrives in the workspace in pages;
  “Show more” and the tail appended by “Follow” do not create new entries.
  One entry — one opening of the session.
- **Viewing your own session is not an event.** The session list and viewing your own session are reading
  what is yours; they are not recorded. Only the owner can open someone else’s session, so
  `ide.session_view` is always an owner’s action.
- **An export is always recorded** — of your own session too: the file leaves the workspace.
- **A refusal is recorded too.** A member who tried to open someone else’s session leaves an entry in
  the log with the result “refused” and the description “Viewing a development session refused”.
- **The “notice” severity** — the **access** operation. This is above “info”, which marks routine
  actions, and below “warning”: other people’s sessions are viewed for a reason, but the security officer
  should see who does it and how often.

The entry has **who** (the owner’s login), the **object** — the session identifier, and in the **details** —
the login of the developer whose session it is, and the project; as with all events — the address and browser.

## How to find it in the log

In the [audit log](/en/docs/audit-log) viewing and export events are in the
**“Development sessions”** category — a separate button in the category filter. Device sign-in and revocation are
in the “Sessions and sign-in” category, questions about sessions — in “Ask”, knowledge from Buff Code — in
“Knowledge base”. Searching by a developer’s login finds the entries about their sessions: the login is in
the description and in the details.

_Illustration: The “Development sessions” category in the log: viewing someone else’s session, exports and questions about sessions — with who and when._

This is how a view entry looks in the [JSON Lines export](/en/docs/audit-log/export) (the values
are illustrative; the `summary` text is stored in Russian):

```json
{"id":418,"at":"2026-09-24T11:03:17.204915+00:00","org":"buff-demo","project":null,
 "actor_kind":"user","actor":"demo-lead","session":"c2a5…","gid":"9821…","ip":"147.45.197.19",
 "user_agent":"Mozilla/5.0 …","action":"ide.session_view","operation":"access","severity":"notice",
 "target_kind":"dev_session","target":"ses_7f3a…","summary":"Просмотрена сессия разработки alice",
 "detail":{"op":"dev_session_feed","login":"alice","project":"shop-web"},"ok":true,"error":null,
 "prev_hash":"e5ac…","hash":"81df…"}
```

An export has `"action":"ide.session_export"` and the description “Development session exported (alice)”.

## What is deliberately not recorded

- **Requesting a sign-in code and waiting for confirmation** — the console asks and waits; what counts
  as an event is the person’s decision.
- **Model calls** — that is usage, and it is recorded where it is charged: in the developer’s session and
  in billing.
- **Reading the knowledge base and the project’s repositories** from Buff Code — reading, just as in the workspace.
- **The list of your own sessions and viewing your own session** — reading what is yours.
- **Connection tool calls** — the [connector’s call log](/en/docs/buff-code/tools#where-every-call-is-visible)
  keeps them, with the developer’s name.
- **Request and answer bodies, knowledge, credentials, sign-in codes, tokens and the device key** — never.

## Who needs it

The permission to read the audit log is granted separately — for example, to an information security officer.
They see who allowed sign-ins on devices, who looked at other people’s sessions and what they exported — with
export to CSV or JSON Lines and a hash chain, as described in [Exporting the log](/en/docs/audit-log/export).