Skip to content
Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// integration

SIEM

Applies to

Product: Cloud · Server · Audience: IT security · Platform Operator · Administrator

Getting audit events from basebox into a SIEM or central log analysis: which events exist, in what format, and which paths are available today – honestly separated into what the interface offers, what operations can add on a server and what is still planned.

Which events basebox records

The application's audit log records security-relevant actions per organisation. Every entry contains timestamp (to the millisecond), user identifier, action, resource type, resource ID, result (SUCCESS/FAILURE), details and the client address.

Action group Examples
Sign-in user.login
Users and groups graphql:editUser, graphql:createGroup, graphql:deleteGroup, graphql:addUserToGroup, graphql:removeUserFromGroup
Messages of the day graphql:createMessageOfDay, updateMessageOfDay, dismissMessageOfDay
Export rest:exportAuditLogs
Connectors and web search Every tool call with organisation, user, tool, provider, result, timestamp – without the text of the search query
Conversation content Only if the detail level is configured accordingly (questions only or answers as well); users then see a notice in the chat

Failing token requests are logged with the address concerned. Retention period and detail level are set by the administrator – see Policies.

Path 1: CSV export from the interface

Available in Cloud and Server. Administration → Audit log → set filters (period, action, resource type, result) → CSV export. The file is saved locally and can be imported into any SIEM that understands CSV. The export itself appears as rest:exportAuditLogs in the log. Suitable for periodic evidence; not for real-time monitoring. Details: Exports.

Path 2: log collection on basebox Server

On a server you control the platform and can collect application and system logs with your usual log stack:

  • Container logs of all services (aisrv, storesrv, ragsrv, idp, inference, MCP connectors) via the Kubernetes log path – e.g. with Fluent Bit, Vector or Promtail into Loki, Elastic or a SIEM.
  • Log level controllable per service (AISRV_LOG_LEVEL, STORESRV_LOG_LEVEL, LOG_LEVEL for ragsrv): info in production; prompt content appears exclusively at trace, credentials only at debug in targeted diagnostic runs.
  • Host logs via the server's syslog / systemd-journal.
  • Metrics for Prometheus: AISRV_METRICS_PORT, Keycloak KC_METRICS_ENABLED, CloudNativePG enablePodMonitor, GPU via NVIDIA DCGM.
  • Keycloak events (login successes/failures, admin actions) can be enabled in Keycloak and collected as well.

Example for the live view:

kubectl logs -n basebox -l app.kubernetes.io/name=aisrv --tail=100 -f

This covers authentication, errors, request traces and infrastructure health – complementing the application's functional audit log.

What is planned

A REST interface for continuous audit export is planned but not yet available to customers. Until then, CSV export and – on servers – log collection are the paths.

In basebox Cloud

You have access to your organisation's audit log and the CSV export. Infrastructure and application logs remain with basebox as operator. Who at basebox can access what is described under Administrative access.

Recommendations

  • Export regularly, at least within the configured retention period – after that nothing can be exported.
  • Filter on FAILURE for a quick look at failed sign-ins and actions.
  • Choose the detail level deliberately: conversation content in the audit log is personal data and produces the notice in the chat. Agree this with data protection.
  • Separate functional audit from technical logging. The audit log answers "Who did what?", the service logs "Why did something fail?".
  • Protect export files: store encrypted, limit recipients, delete once the purpose is fulfilled.

Next: Audit & logging · Logging (operations) · Monitoring