Conversations with the assistant

AI Assistant in the navigation, at /ai, is a place to ask a security question in plain English and get an answer back. It keeps a list of conversations down the side, so a question you asked last Tuesday is still there this Tuesday.

The two names at the end of that notice are links, and they are where the half of the product that does read your data lives. Sentinel-Q decisions — /sentinel-q/decisions — is the autonomous-decisions screen: one row per alert Sentinel-Q looked at, with the evidence it gathered and the verdict it reached. Sentinel-Q proposals — /sentinel-q/proposals — is the change composer, where you type a sentence and get back an exact change to approve or reject.

So the routing is simple. What happened in my organisation? → Reading a Sentinel-Q decision. Change something for me → Asking Sentinel-Q to change something. What is a golden ticket attack, and should I care? → this page.

This article is about the conversation itself — what is stored, what is sent to the model, who can read it, and the several limits you will meet. The autonomous half of Sentinel-Q, the one that investigates alerts without being asked, is a different subsystem and is covered in Reading a Sentinel-Q decision.

The Sentinel-Q chip in the top bar

Every screen carries a Sentinel-Q chip in the top bar. Clicking it opens a slide-out panel rather than navigating you away from what you were doing, and it holds a real conversation against the same endpoint and the same grounded assistant this page uses — the same limits apply: general security knowledge, no read of your organisation's data, the message and token limits described below. A reply shows its thinking state while a turn is in flight, renders with the same citations, and offers a retry if the turn fails.

Asking a question in the panel stays a question — it no longer redirects you elsewhere or reframes what you typed as something else. If you want to turn what you typed into a proposed change instead, there is a separate, explicit Draft a change proposal instead button that hands your text to Sentinel-Q proposals (/sentinel-q/proposals); it is something you choose to do, not something that happens on your behalf when you press send.

Who can hold a conversation

Two permissions, at a deliberately coarse grain: ai:conversations.read to see conversations and their messages, and ai:conversations.write to start one, send a message, rename it or delete it. The reasoning recorded in the code is that a role that can hold a conversation can manage its own conversations — separating rename from send would be a permission nobody would ever grant differently.

The whole surface sits behind the ai licence feature, so a plan without it returns 402 rather than an empty page. See This is not in your plan. A separate permission, ai:tools.write, governs approving or executing anything the AI proposes — a person who can ask questions is not automatically a person who can authorise an answer. You will not meet it on this screen, because this screen proposes nothing; it belongs to the surfaces that do.

A conversation is per person, not per company

This is the behaviour most worth stating plainly, because the reasonable guess is wrong in a way that matters.

Your conversations are yours. Every read, rename and delete is filtered by both your organisation and your own user identity, in the database query rather than in a check afterwards. A colleague holding ai:conversations.read cannot list your conversations, cannot open one by guessing its identifier, cannot continue one and cannot delete one. The code comment on that query says why the owner predicate is there: without it, any member of the organisation with read permission could enumerate identifiers and read a co-worker's conversation — same tenant, so the organisation filter passed; different person, so nothing else stopped it.

The consequence for a team is that there is no shared conversation and no handover. If you want a colleague to see what the assistant told you, paste it to them, or attach the reasoning to the alert or ticket you are both working on. A saved conversation is a personal notebook, not a case file.

What it remembers, and the twenty-four-message wall

The assistant reads the recent part of a conversation, not all of it. Two independent bounds apply and the tighter one wins.

Twenty-four messages

About twelve exchanges. Older messages are trimmed oldest-first, and a message is never split in half — it is either included whole or dropped whole.

Twenty-four thousand characters

Roughly six thousand tokens. One long pasted log excerpt can consume this on its own, and if a single message exceeds the whole budget it is still kept, because the newest message is the question.

The console says this out loud rather than letting you discover it: For a long conversation the assistant reads the most recent part, not all of it. Start a new conversation for a new topic. Take that literally. A forty-message conversation that changed subject twice will answer your latest question from the last twelve exchanges only, and the earlier context is invisible to it even though you can still scroll up and read it yourself.

The transcript you can read back is capped separately at two hundred messages. That number is deliberately different from the model's window: what you can review and what the model considered are two different questions, and quietly making them the same would hide the trimming from you.

Other limits worth knowing: the conversation list is capped at fifty, a title is capped at 120 characters and is truncated rather than rejected, and an auto-derived title takes the first sixty characters of your opening question trimmed at a word boundary. Each reply is capped at 4,096 output tokens, dropping to 1,024 when your tenant is running close to its daily AI budget.

What appears in the transcript

A conversation is threads and messages, and that is all this screen renders. There is no plan panel, no step list, no Approve plan or Reject plan button and no blast-radius label, because nothing on this route calls a tool. If you are looking for a proposed change to approve, you are on the wrong screen — that is Sentinel-Q proposals (/sentinel-q/proposals in the console), described in Asking Sentinel-Q to change something.

One property of the surfaces that do propose actions is worth carrying with you, because it is the reason to trust an impact label anywhere in the product. The blast radius shown next to a step is re-derived by the server from the tool registry, not taken from the model's output. The comment in the code is one line and it is the whole security argument: re-derive blast radius from the registry so the model cannot lie. A model that describes an isolation as low-impact does not thereby make it low-impact.

Every turn writes one audit row regardless. It records the model, the provider, whether the call was billed to your own provider, the inference geography, input and output token counts, cost, whether the tenant was in degraded mode, the stop reason, how many context messages were used and whether the context was truncated — plus the redacted prompt, the reasoning and the response. The code is explicit that this row, in the database, is the only place a prompt or a response is recorded, and that nothing on this path may put message content into a log line.

The notices you may see, and what each means

These are the console's own strings, so you can match what you saw against what it means.

Sensitive details in your prompt were redacted before being sent to the model

Something matching a redaction pattern was removed on the way out. The redacted form is what is stored in the audit row as well.

This prompt was blocked by the safety guardrails

Nothing was sent. Rephrase, or if you believe the block is wrong, say so when you report it — the guardrail is a control, not an opinion about your intent.

You have reached the per-minute AI request limit for your organisation

A rate limit, per organisation rather than per person, so a colleague running a long session can hold you up. It is recorded as a rate_limited audit event and answered with 429.

Your AI usage has exceeded the daily cost budget for this license tier

429 with a Retry-After pointing at the start of the next UTC day. Before this point the platform degrades rather than stopping: at roughly three-quarters of the budget it moves to a cheaper model, shortens replies and limits an investigation to four tool rounds. See What an investigation costs.

This assistant is an AI system…

The EU AI Act disclosure, shown on the page rather than buried in a policy document. It states that responses and proposed actions are model-generated, that a human must approve anything flagged high-impact, and that a full audit trail is retained for every prompt and tool call.

Deleting a conversation

The console asks first, and the wording is accurate: The conversation and every message in it are deleted permanently. This cannot be undone. The delete cascades to the messages and to any action plans and steps attached to the conversation.

What happens to the audit row is the interesting part, and it is a deliberate compromise between two obligations that pull in opposite directions.

1. 1

   The deletion is recorded before it happens

   An audit event is written first. Afterwards there is no conversation to attach it to, and if the delete then failed there would be a record of an erasure that did not happen.

2. 2

   The audit row's free text is cleared, in the same transaction

   The prompt, the reasoning and the response columns are set to null and the row is marked content_redacted: thread_deleted. Your words are gone from the second copy as well as the first.

3. 3

   The audit row itself survives

   The timestamp, the event type, the model, the token counts and the safety verdict remain. This is the EU AI Act record of which model ran, for whom, at what cost and with what safety outcome — and, as the code puts it, a record a user can erase by pressing delete is not a record.

A GDPR erasure request takes a deliberately different shape, because the two requests are asking for different things. Erasure deletes the message content outright and keeps an anonymised conversation shell, because deleting the conversation would cascade away the action plans and steps — and that would silently destroy the record of every change the AI made to your security configuration on the way to answering. See GDPR data subject requests and export.

What to read next

1. Asking Sentinel-Q to change something — the screen to use when you want a change made, rather than a question answered.
2. Reading a Sentinel-Q decision — the screen to use when you want to know what happened in your own organisation.
3. What Sentinel-Q is allowed to do — the ceiling on every action, including the ones no conversation can reach.
4. The MCP server — if you would rather ask these questions from your own AI client than from this page.