Security operations: MFA, SIEM export, audit log, deletion, retention¶
These are the operator-facing controls a regulated customer expects from a vendor: who can sign in and how, where security events go, what is logged about administrators, and how data is deleted at exit. Everything on this page is configuration, reported back in the Deployment Manifest under security, siem and retention.
Account security¶
Multi-factor authentication¶
Dashboard users enrol an authenticator app (TOTP, RFC 6238, any app: Microsoft Authenticator, Google Authenticator, 1Password) at Account > Security (/account/security). Enrolment shows a QR code and issues ten single-use backup codes. After enrolment, sign-in asks for the six-digit code (or a backup code) as a second step.
| Setting | Default | Meaning |
|---|---|---|
XYBERN_MFA_REQUIRED |
0 on Cloud, 1 on Dedicated and Sovereign |
When on, users in the required roles are sent to enrolment on their first sign-in and cannot use the product until an authenticator is confirmed |
XYBERN_MFA_ROLES |
owner,admin |
Roles that must enrol. Platform administrators always count |
Any user can enrol voluntarily even when enforcement is off. The mobile app sends the code as code in the login body and receives mfa_required or invalid_mfa_code when it is missing or wrong.
Passwords, lockout, sessions¶
| Setting | Default | Meaning |
|---|---|---|
XYBERN_PASSWORD_MIN_LENGTH |
12 |
Minimum length. Passwords must also use three of four character classes, must not be a common password, and must not contain the account's email name |
XYBERN_LOGIN_MAX_FAILURES |
5 |
Failed sign-ins (web or mobile) before the account is locked |
XYBERN_LOGIN_LOCKOUT_MINUTES |
15 |
Lockout duration. A lockout emits auth.lockout to the SIEM |
XYBERN_SESSION_HOURS |
336 on Cloud, 12 otherwise |
Absolute session lifetime; afterwards the user signs in again |
XYBERN_SESSION_IDLE_MINUTES |
0 on Cloud, 60 otherwise |
Idle timeout (0 disables) |
SIEM export¶
Every security-relevant event can be streamed to the customer's SIEM. Nothing is sent unless a sink is configured; sending is asynchronous and never delays an authorisation decision.
# syslog (Splunk, QRadar, Elastic, Microsoft Sentinel via a syslog collector)
XYBERN_SIEM_SYSLOG_HOST=siem.internal
XYBERN_SIEM_SYSLOG_PORT=514 # default 514
XYBERN_SIEM_SYSLOG_PROTOCOL=tls # udp | tcp | tls
XYBERN_SIEM_FORMAT=cef # cef | json
# or an HTTP collector receiving one JSON object per POST
XYBERN_SIEM_HTTP_URL=https://collector.internal/xybern
XYBERN_SIEM_HTTP_TOKEN=... # sent as a bearer token
XYBERN_SIEM_MIN_SEVERITY=0 # drop events below this severity (0 to 10)
Event catalogue¶
| Event id | Meaning | Severity |
|---|---|---|
authorization.allow |
An agent action was authorised | 2 |
authorization.escalate |
An agent action was held for human review | 5 |
authorization.block |
An agent action was refused | 7 |
authorization.terminate |
An agent session was terminated (kill switch or budget) | 8 |
escalation.approved, escalation.rejected, escalation.expired |
A held action was resolved | 5, 5, 4 |
admin.<action> |
A platform or workspace administration action (workspace created, member invited, key rotated, workspace deleted, and so on) | 4 |
admin.account.mfa_enrolled, admin.account.mfa_disabled, admin.account.mfa_backup_codes_regenerated |
MFA lifecycle (recorded through the audit trail) | 4 |
auth.lockout |
An account was locked after repeated failed sign-ins | 6 |
incident.opened |
An incident record was created | 7 |
breakglass.triggered, breakglass.closed, breakglass.reviewed |
Break-glass override lifecycle | 8, 5, 4 |
licence.warning |
Licence grace or expiry state (Sovereign) | 6 |
CEF format¶
CEF:0|Xybern|AuthorisationLayer|2026.09|authorization.block|Agent action refused|7|rt=1757184000000 cat=authorization outcome=block suser=agent:finance-bot act=payment.transfer cs1Label=workspace_id cs1=f5300764… cs2Label=agent_id cs2=finance-bot cs3Label=decision_id cs3=8c1f… cs4Label=policy cs4=Saudi Financial: high value payments msg=amount above threshold xyDeployment=dedicated:SA
Header fields are the standard seven; extensions use the standard CEF keys where they exist (rt, suser, act, outcome, cat, msg, cs1 to cs4 with labels) and xy* keys for Xybern-specific fields. Values are escaped per the CEF specification. Syslog framing is RFC 5424 with facility authpriv; CEF severity maps onto syslog severity (9 to 10 critical, 7 to 8 error, 5 to 6 warning, 3 to 4 notice, else informational).
JSON format¶
{"schema": "xybern-event/1", "event_id": "authorization.block", "name": "Agent action refused",
"severity": 7, "ts": "2026-09-06T18:40:00+00:00", "ts_ms": 1757184000000,
"workspace_id": "f5300764…", "actor": "agent:finance-bot", "agent_id": "finance-bot",
"decision_id": "8c1f…", "action": "payment.transfer", "outcome": "block",
"policy": "Saudi Financial: high value payments", "message": "amount above threshold",
"deployment": "dedicated:SA", "extra": {}}
The same object is posted to the HTTP sink. The manifest reports siem.enabled, the configured sinks and the format so the customer can confirm the integration from outside.
Administrator audit log¶
Everything administrators do (workspace and member changes, key minting and rotation, mandate signing, escalation decisions, deletions) is recorded with actor, target, source IP and request id, hash-chained into the Provenance Vault. Workspace owners and admins read it in the dashboard under Proof > Audit log, or export it:
GET /api/sentinel/audit-log?workspace_id=<id>&limit=500
GET /api/sentinel/audit-log?workspace_id=<id>&format=csv
The same events reach the SIEM as admin.<action> in real time.
Workspace deletion and the Deletion Certificate¶
Deleting a workspace removes every row that belongs to it, across every table (decisions, escalations, receipts, keys, agents, mandates, members, sessions, incidents, uploaded content), then the workspace itself. Nothing is soft-deleted. The operation is available only to platform administrators and requires typing the workspace name:
DELETE /api/admin/workspaces/<id>
{"confirm": "<workspace name>", "reason": "Contract ended 2026-12-31"}
The response is a Deletion Certificate: per-table row counts before, rows removed, rows remaining after (expected empty), who ordered it, when, and why, signed with the Provenance Vault's ECDSA key so the customer can verify it offline with the published public key (/api/sentinel/vault/v2/keys). It is also kept at GET /api/admin/workspaces/<id>/deletion-certificate and written to instance/deletions/<id>.json on the server.
{"schema": "xybern-deletion-certificate/1", "workspace_id": "…", "workspace_name": "SAB pilot",
"deleted_at": "2027-01-05T09:12:44Z", "ordered_by": "ops@xybern.com", "reason": "Contract ended",
"rows_before": {"enforcement_decisions": 18422, "enforcement_escalations": 311, "…": 0},
"rows_removed": {"…": 0}, "remaining_after": {},
"backups_note": "Database backups expire per the retention schedule of this deployment (default 14 days); no restore of this workspace will be performed after deletion.",
"certificate_sha256": "…", "signature": {"algorithm": "ecdsa-p256-sha256", "key_id": "…", "public_key_pem": "…", "value": "…"}}
On Dedicated and Sovereign the whole environment (database, volumes, backups) is destroyed at exit as well; the certificate covers the application data, the environment teardown is recorded in the offboarding checklist.
Retention¶
Retention is off by default (everything is kept for as long as the workspace exists). Regulated customers usually set it:
| Setting | Effect |
|---|---|
XYBERN_RETENTION_CONTENT_DAYS |
Action content (the payload an agent tried to send) older than this is nulled; the decision record, its hashes and its receipt are kept |
XYBERN_RETENTION_DECISIONS_DAYS |
Decision records older than this are deleted together with their escalations |
XYBERN_RETENTION_ESCALATIONS_DAYS |
Resolved escalations older than this are deleted |
The purge runs daily inside the application. Provenance Vault entries are never altered: they hold hashes, not content, and the chain must stay intact so older receipts keep verifying.
Content Security Policy¶
Product pages send a Content Security Policy. On Cloud it is report-only by default (the marketing site loads third-party scripts); on Dedicated and Sovereign it is enforced with self-hosted sources only. XYBERN_CSP_MODE=report|enforce|off overrides the default.