Logging, Evidence, and SIEM Delivery

​

Overview

Zylon records structured audit, security, application, and AI chat lifecycle events when logging storage or delivery is enabled. Operators can use these logs to investigate what happened, who initiated it, what was requested, what was answered, and which observable tools or data paths were used. Zylon can:

• Store structured logs internally when logging storage is enabled.
• Send logs to SIEM applications and log collectors using supported syslog formats, including RFC 5424 JSON and CEF.
• Send structured JSON logs to HTTP destinations, including cloud-based ingestion endpoints and customer-managed collectors.
• Let authorized Backoffice users retrieve stored logs manually.

Default log-storage behavior keeps stored logs inside the customer’s Zylon deployment unless external log delivery is configured. Operators should confirm deployment-specific observability, telemetry, and crash-reporting settings separately. External delivery configuration is documented in Configuration: Log Delivery and Storage.

​

Before you configure delivery

• Confirm which logs must be stored in Zylon and which logs must be delivered to customer-controlled systems.
• Confirm the syslog collector host and port, or the HTTP collector URL, from the Zylon deployment network.
• Select syslog rfc5424_json, syslog cef, or HTTP canonical_json according to the collector input.
• Decide whether TLS certificate verification is required and prepare a trusted CA path when needed.
• Decide retention in both Zylon internal storage and downstream systems.
• Review action and organization filters so required audit events are not excluded.
• Confirm all Zylon nodes use a trusted time source such as NTP. Log timestamps are most useful for forensic correlation when host clocks are synchronized and reviewed in UTC.

​

What Zylon logs

Zylon stores a shared log envelope and event-specific structured data. Exact fields depend on the event family and enabled logging settings.

Masked request keys

Zylon masks these exact request-key names before storage: password, new_password, current_password, secret, api_key, apikey, private_key, privatekey, token, id_token, access_token, refresh_token, session_token, bearer_token, client_secret, secret_key, credentials, connection_string, cookie, set_cookie, and authorization.Zylon also masks keys ending in _token, _password, _secret, _credential, _credentials, _connection_string, or _cookie.

​

Trust and integrity

Stored logs should be treated as operational audit records with a read-only Backoffice retrieval surface:

• Documented Backoffice log access is for retrieval only.
• Log retrieval through Backoffice is itself logged, so operators can review who accessed platform or gateway log records.
• No documented Backoffice UI or API flow permits an operator to modify or delete one stored log record.
• The documented deletion path for stored log records is the configured retention cleanup task.
• Cleanup is disabled by default. When cleanup is enabled, the default stored log retention threshold is 180 days.

Zylon does not document a cryptographic hash chain, signature chain, or tamper-evident log store for internal records. For stronger tamper-evidence, deliver logs to a customer-controlled SIEM or append-only archive, restrict database administrator access, retain backups, and monitor Kubernetes/database audit trails. Direct database access by infrastructure administrators is outside the Backoffice permission model and should be governed by the customer’s platform controls.

​

Logging-system administration

Logging storage, retention, syslog delivery, and HTTP delivery are deployment configuration settings. Changes such as disabling storage, reducing retention, or changing delivery destinations should be captured in the customer’s change-management system, GitOps history, Kubernetes audit trail, or infrastructure audit logs.

​

AI auditability

Zylon provides auditability of the observable chat lifecycle and agent-visible actions. Logs can support reconstruction of:

• who initiated a chat;
• which organization, gateway, or project was involved;
• what request metadata was stored;
• what response was stored when audit logging captured it;
• which tools were visible in the response payload;
• which actions, integrations, files, chats, and projects were used.

​

EU AI Act-supporting logging and traceability

Zylon logging can support EU AI Act traceability and record-keeping workflows, depending on configuration and deployment. It should be treated as one technical evidence source inside a broader governance, monitoring, and retention program. Relevant official EU AI Act Service Desk pages:

• Article 12: Record-keeping
• Article 19: Automatically generated logs
• Article 26: Obligations of deployers of high-risk AI systems

​

Control evidence mapping

This table is a procurement and control-evidence aid, not a certification statement or compliance claim. Final applicability depends on the customer’s deployment, policies, procedures, monitoring, retention, and use case.

​

Log storage and retention

When logging storage is enabled, Zylon persists structured logs in internal storage. When logging storage is disabled, new logs are not persisted internally. Zylon can clean up stored logs after a configured retention window. Stored log cleanup is disabled by default. The default retention value is 180 days once logging cleanup is enabled. The cleanup task deletes stored log records older than the configured threshold. External collectors keep their own retention policies outside Zylon.

​

Right to erasure and retention

Audit and security logs may contain user identifiers, account identifiers, organization identifiers, IP addresses, prompts, responses, or other context that can be personal data depending on the deployment. A user deletion or erasure workflow does not automatically imply immediate deletion of every historical audit record; many regulated environments retain security logs for a defined period to preserve fraud, abuse, and incident evidence. Set stored-log retention, external delivery filters, and downstream collector retention according to your legal basis and data-minimization policy. If your policy requires pseudonymization or earlier deletion of user-linked log fields, implement that requirement in the customer-controlled collector/SIEM or validate product behavior for the deployed version before enabling long retention.

​

Time and schema markers

Backoffice log records expose ISO timestamps such as start_timestamp and end_timestamp. Use UTC for cross-system investigation and keep all Zylon nodes synchronized with NTP or an equivalent trusted time source. Delivered payloads include schema markers such as zylon.rfc5424_json.v1 and zylon.canonical_json.v1. These markers let SIEM parsers route and identify payload shapes. They do not, by themselves, enforce a deprecation or migration policy; validate parser compatibility when upgrading.

​

Ways to consume logs

​

Operational recommendations

• Keep internal log storage enabled unless security, legal, and operations teams approve disabling it.
• Deliver logs to a customer-controlled SIEM or collector where long-term monitoring or independent retention is required.
• Prefer TLS for syslog where supported by the collector.
• Enable certificate verification in production when the collector has a trusted certificate path.
• Use filters carefully so required investigation events are not excluded.
• Confirm retention in downstream systems separately from Zylon internal storage.
• Test retrieval and delivery after changing logging configuration.