Audit

The Audit page is the super-admin’s window into what’s been happening on your customer. Pick a user, pick one of their sessions, and you see exactly what was asked, what was answered, and every backend step the platform took to produce that answer — with sensitive data masked by default.

It only appears in the sidebar for the Customer Super Admin. Everyone else, regardless of role flags, has no access to it. The backend enforces the same restriction independently of the UI.

What you see

The page is laid out as four panels, drilling left-to-right:

┌────────┬──────────┬─────────────────┬──────────────────┐
│        │          │                 │                  │
│  USERS │ SESSIONS │  CONVERSATION   │  AUDIT TRACE     │
│        │          │                 │                  │
└────────┴──────────┴─────────────────┴──────────────────┘

Panel	What it shows
Users	The first 20 users in your customer (super admins + product app users). Includes a search box.
Sessions	The picked user’s recent chat sessions. Top 20, last 30 days by default, with a date range filter and a search box.
Conversation	The chat transcript for the picked session — every user prompt and assistant reply, in order.
Audit trace	The reasoning or feedback trail behind each agent run, including status, timing, selected tools, and governance checks.

Each subsequent panel shows a small loading overlay while its data is being fetched, so you always know which slice is in flight.

Refresh

The Refresh button (top-right) resets the page to step zero — clears your selections and re-fetches the user list. Useful when new sessions have been created since you opened the page, or when you want to step out of a deep dive and start over.

Locking personal information

Next to Refresh is the Lock Personal Information toggle. It controls whether the server masks PII before the data reaches your browser.

• Default: ON. Emails, phone numbers, credit cards, IBANs, IP addresses, US SSNs, UK NHS / NINO / postcodes, AU TFN / ABN / ACN / Medicare numbers, SA 13-digit IDs, EU VAT numbers, customer-id-shaped tokens, currency amounts (USD / GBP / EUR / AUD / ZAR + adjacent), percentages, dates, and titled-prefix names (Mr / Mrs / Dr X Y) are all replaced with bracketed placeholders like {{EMAIL}}, {{PHONE}}, {{CREDIT_CARD}} before the response is sent.
• Toggle: clicking the lock disables masking and immediately re-fetches the open conversation + audit trace so the change is visible.
• Persistence: your choice is remembered for the browser session — if you disable masking and refresh the page, it stays disabled. Closing the tab resets to ON next time you open it.

Tip

Server-side masking means raw PII never reaches your browser when the lock is on. It can’t be inspected via devtools or the network tab. The unmasked path is gated by the same super-admin check as the rest of the page.

The masking is applied to both the conversation panel and the audit trace, so even when you’re inspecting how an answer was produced you’ll see masked values until you opt in to the unmasked view.

Agent sessions may also use Mask to AI. In those sessions the model saw placeholders such as [PERSON_1] rather than the original personal identifiers. If masking is unlocked in the UI, RebelCore reconstructs known placeholders on the server before returning the response to your browser. The raw placeholder map is not sent to the browser while masking is locked.

Coverage notes

The masker uses Microsoft Presidio with a stronger English language model, layered with country and domain-specific recognisers for structured identifiers. Together they catch:

• Names — [PERSON] — full names (“Brian Naidoo”), title-prefixed (“Mr John Smith”), and single first names mid-sentence (“Brian applied for a loan.”) via Presidio’s spaCy NER.
• Locations and organisations — [LOCATION], [ORGANIZATION] — also via the NER pass.
• Structural identifiers — [EMAIL_ADDRESS], [PHONE_NUMBER], [URL], [CREDIT_CARD], [IBAN_CODE], [IP_ADDRESS], [US_SSN], plus the country and domain-specific ones ([SA_ID_NUMBER], [US_EIN], [UK_NHS], [UK_NINO], [UK_POSTCODE], [AU_TFN], [AU_ABN], [AU_ACN], [AU_MEDICARE], [EU_VAT], [CUSTOMER_ID], [MONEY_AMOUNT], [PERCENTAGE], [DATE]).

The trade-off:

• The language model has better name recall than the earlier lightweight masker, but no automatic masking system is perfect — uncommon-script names and very ambiguous tokens can still slip through.
• The first masked request after a service restart can take slightly longer while the masking model warms up. Subsequent calls are fast.
• Repeated identical text is cached (LRU, 512 entries) so the audit page’s re-renders against the same chat history don’t re-pay the analyser cost.

If you need stronger multilingual coverage, speak to RebelCore™ support about the available masking options.

Customer-id-shaped tokens (e.g. ABC500, cust-123, LN_4567) are matched case-insensitively with a 3-digit minimum. The minimum is what suppresses false positives on natural-language word+number combos like win10 or covid19 — short suffixes pass through, but anything that looks like a real customer / account / loan code gets masked regardless of letter casing.

Reasoning and User Feedback

The right-hand audit pane separates the two kinds of agent trace:

Tab	What it shows
Reasoning	The detailed workflow trace for Thinking sessions.
User Feedback	The shorter Fast-session activity trail that was shown while the answer streamed.

Fast-session feedback is deliberately written for people, not engineers: it shows the major steps the agent took without exposing private reasoning. Thinking sessions keep the deeper workflow trace for investigations that need more detail.

What’s in the trace

Each accordion row in the rightmost panel is one inference workflow run. The header shows:

• Start time of the run
• Duration end-to-end
• Status — completed, failed, timed_out, canceled
• Activity count — how many backend steps were involved

Expanding a row reveals the per-activity tree. For each activity:

• Name — the step or tool used by the agent.
• Duration
• Status badge — green for OK, rose for failed, amber for timed-out, slate for canceled
• Input — what the step received, masked when the lock is on
• Output — what the step returned, masked when the lock is on
• Timestamps — scheduled / started / ended
• Error message — when an activity failed, with the failure reason inline

This view answers questions like “why did the agent give that answer?” — you can trace the selected operation, whether data was searched, how the answer was prepared, and where time was spent.

Tree vs Graph view

The trace panel has a Tree | Graph toggle in its header.

• Tree — the per-run accordion view described above. Best for reading individual step inputs and outputs.
• Graph — a visual reasoning graph. Each step is a node, connected top-to-bottom in the order it ran, colour-coded by status, with a side-drawer that opens to show the step detail when clicked.

Switching views doesn’t re-fetch the data — both are different visualisations of the same audit document.

LLM exposure visibility

The audit captures the active LLM exposure level for every inference workflow:

• Every run records the active exposure level (full / limited / advisory) in its run metadata.
• If the agent’s leak scanner ever catches an answer trying to quote a value the project’s exposure level forbids, the run is marked and an event lands on the Activity page.

Together these let you answer questions like “was this advisory project ever asked for raw rows, and did the agent comply?” without leaving the audit page.

Filtering sessions

The Sessions panel has two controls above the list:

• Search — substring match on session title (case-insensitive)
• Date range — defaults to the last 30 days. Change either bound to widen or narrow.

The “to” date is inclusive to end of day, so picking today as the upper bound includes sessions that ran later in the day.

Where the data comes from

• Users and Sessions come from your customer workspace.
• Conversation messages are stored in order so the transcript can be reviewed later.
• Reasoning and User Feedback traces are written to the audit store for the session.
• PII masking is applied by the server before masked audit data reaches your browser.

Where to go next

• Managing users — adding users and resetting their passwords.
• Roles & permissions — the boolean permission model that gates everything else in the platform.