Audit Log

Audit logs are records of what happens inside your GoodData environment. These logs help you track who did what, when they did it, how they did it, and what they changed.

The audit log can support you in several critical areas:

• Security and fraud prevention – Monitor unauthorized or suspicious activity.
• Compliance and legal requirements – Meet GDPR, HIPAA, or SOC2 standards.
• Troubleshooting and support – Quickly trace issues and understand changes that impact your setup.

Audit Log Scope and AI-Initiated Actions

The audit log records events that GoodData considers relevant for security investigations, data access, and changes to the solution. It is not intended to contain every individual interaction with the platform.

For example, searching for a dashboard or visualization through the user interface, API, or AI Assistant does not create an audit log entry unless the action also triggers one of the events listed in the Audit Events section.

AI Assistant does not grant users additional permissions. If the AI Assistant performs an action on behalf of a user and the same action is covered by the audit log when performed directly through the UI or API, GoodData records the same audit event. Depending on the action, additional metadata may distinguish whether the action was initiated through the AI Assistant, for example by including an agent identifier.

Diagnostic identifiers such as traceId or X-GDC-TRACE-ID are used for internal troubleshooting. They are not intended as stable end-to-end audit correlation identifiers.

Setting up Audit Logging

Audit Log Entries

Each audit log entry is saved in JSON format and includes a set of mandatory fields, which are standardized and present in every log entry, regardless of the event type:

Audit entries may include additional JSON fields specific to that event type. These extra fields provide more context for that particular action and are not standardized across all events. These include:

Example Audit Log Entry:

{
  "eventName": "user_login",
  "categoryUid": "3",
  "classUid": "3002",
  "description": "User XY logged in",
  "ts": "2023-01-20T18:55:32.466Z",
  "orgId": "org_abc123",
  "workspaceId": "workspace_xyz456",
  "userId": "user_XY",
  "target": "organization_setting_XY",
  "source": "1.2.3.4",
  "sessionContextType": "OIDC",
  "sessionContextIdentifier": "token_1234",
  "success": true,
  "type": "audit"
}

Audit Events

Below is a complete list of all audit log events, including their meanings, categories, and classes. The categories and classes follow the Open Cybersecurity Schema Framework (OCSF) where applicable.

AI Memory Audit Events

The same MEMORY_ITEM_* event set covers both workspace-level and organization-level AI memory items. Workspace-level memory items log with workspaceId populated. Organization-level memory items log with workspaceId set to <NONE>. Use the workspaceId field to distinguish the scope.

For MEMORY_ITEM_UPDATE, the audit entry contains only the fields that were changed by the request. The strategy field is an enum value, keywords is a list of strings, isDisabled is a boolean, and instruction contains the system-prompt text.

When a memory item is created or updated by the AI Assistant on behalf of a user, agentId and conversationId are attached automatically.

Reads of memory items, such as GET, list, or search operations, are not audited.

Cache Settings Audit Events

The CACHE_SETTINGS event is recorded when the cache strategy or cache retention of a data source changes. This includes the initial settings applied when a data source is created, changes made when a data source is updated, and changes applied through the data sources layout API. No CACHE_SETTINGS event is recorded if neither setting changes.

The audit entry identifies the affected data source in the target field as datasource:<id> and contains these attributes:

• cacheStrategyPreviousValue and cacheStrategyValue: Previous and new cache strategies. Values are ALWAYS or NEVER.
• cacheRetentionPreviousValue and cacheRetentionValue: Previous and new cache retention configurations. The configuration can be INDEFINITE, VALIDITY_PERIOD (with an ISO-8601 duration), or SCHEDULE (with a cron expression and timezone).

For example, a validity period of 24 hours is represented as {"type":"VALIDITY_PERIOD","validityPeriod":"PT24H"}. A previous value of null means no value was previously set. A previous value of READ_FAILED means the earlier setting could not be retrieved, but the change was still applied and logged.

Data source updates continue to generate DATASOURCE_UPDATE events. Cache invalidations, including scheduled invalidations, are recorded separately as CACHE_INVALIDATE events.

Audit Logging for Layout APIs

When using the layout APIs, deletion of old resources is recorded through a single audit log message per action, rather than individual entries for each sub-resource. However, creation events are logged individually for each entity.

Here is how deletion events are logged:

• eventName = workspace_delete, target = <org_id> (Triggered by the organization layout API) This also deletes: workspace settings, dashboards, visualizations, and permissions.

• eventName = workspace_delete, target = <workspace_id> (Triggered by the workspace layout API) This also deletes: workspace settings, dashboards, visualizations, and permissions.

• eventName = analytics_model_delete, target = <workspace_id> (Triggered by the analytics model layout API) This also deletes related permissions.

• eventName = datasource_delete, target = <organization_id> Deletes the data source and all related permissions.

Limitations

• The audit log does not provide a complete record of every API request, UI interaction, or AI Assistant conversation.
• Authorization failures, 403 responses, failed AI actions, prompt-injection attempts, and policy-blocked actions are not generally recorded as audit events unless they correspond to one of the events listed in the Audit Events section.
• Diagnostic logs may contain additional troubleshooting information, but diagnostic log fields and formats are not part of the public audit log.