Audit logs

The security audit log, the setup audit trail and login history — what each records, how to read them, and retention.

Three read-only system collections record who did what. All are queryable as JSON:API (filters, sorting, paging) and visible in the console; none can be written or deleted through the API.

Security audit log#

security-audit-logs — authentication and authorization events: eventType, eventCategory, actorUserId, actorEmail, targetType/targetId/targetName, details, ipAddress, userAgent, correlationId, timestamp.

Event types include LOGIN_SUCCESS, LOGIN_FAILED, ACCOUNT_LOCKED, ACCOUNT_UNLOCKED, PASSWORD_CHANGED, PASSWORD_RESET_ADMIN, PASSWORD_POLICY_UPDATED, MFA_ENROLLED, MFA_CHALLENGE_SUCCESS, MFA_CHALLENGE_FAILED, MFA_RESET, RECOVERY_CODE_USED, TOKEN_ISSUED, TOKEN_REVOKED, PAT_CREATED, PAT_ADMIN_CREATED, PAT_REVOKED, DELEGATED_ADMIN_ACTION, DELEGATED_SCOPE_CHANGED, PORTAL_USER_INVITED, AUTH_FAILURE.

GET /api/security-audit-logs?filter[eventType][eq]=LOGIN_FAILED&sort=-timestamp&page[size]=100

Platform-administration events#

Token and tenant-administration events (PAT_CREATED, PAT_ADMIN_CREATED, PAT_REVOKED, TENANT_ADMIN_INVITED, TENANT_BOOTSTRAP_TOKEN_ISSUED) are emitted by the worker on its structured security.audit log stream, with the MDC fields security.event, security.actor, security.target, security.tenant and security.result. Search for them in your log pipeline.

TENANT_BOOTSTRAP_TOKEN_ISSUED records each bootstrap token attempt. The actor is the platform admin’s email, the tenant is the target tenant and the target is the user the token was minted for. A successful mint is one result=success event whose detail holds the token name, its expiry and the admin’s own tenant. Refusals are result=failure with the reason (missing MANAGE_TENANTS, the platform tenant, a bad expiresIn, a user outside the tenant). Neither ever contains token material.

Console: Setup → Security → Security audit (MANAGE_USERS). CLI: kelta audit security --since 24h.

Setup audit trail#

setup-audit-entries — every metadata change: userId, action, section, entityType, entityId, entityName, oldValue, newValue, timestamp. Collection, field, layout, flow, profile and permission edits all land here with before/after values.

Console: Setup → Security → Audit trail (VIEW_SETUP). CLI: kelta audit setup.

login-history — one row per login attempt: userId, loginTime, sourceIp, loginType, status, userAgent and, when the gateway has a geolocation database, geoCountry, geoRegion, geoCity, geoLat, geoLon.

Console: Setup → Security → Login history; a user’s own logins on their detail page. CLI: kelta audit logins, kelta users logins <userId>.

Data change history#

Changes to record data are not in these logs; they are captured per field or per record by field history and record versioning.

Correlation#

Every API response carries meta.requestId; audit rows carry correlationId. Use it to join an audit event to the request log and traces in Setup → Platform → Monitoring (Audit trails and tenant monitoring).

Retention#

Audit rows are kept indefinitely; there is no user-facing purge. Monitoring data (request logs, traces) has its own retention setting — see Audit trails and tenant monitoring.