Effective security monitoring depends on comprehensive, timely audit logs. This guide explains how to ingest and analyze Foundry audit logs to maintain oversight of user activity, detect security incidents, and ensure compliance with organizational policies.
Audit logs capture critical information about every action taken in Foundry, enabling you to understand:
These logs may contain contextual information including Personally Identifiable Information (PII) such as names and email addresses. Access should be restricted to personnel with appropriate security qualifications.
Foundry provides flexible delivery mechanisms to support diverse security infrastructure and Security Information and Event Management (SIEM) requirements.
For external SIEM integration (audit.3 only, preferred):
External SIEMs can continuously poll audit.3 logs directly using Palantir's audit API endpoints. The list-log-files endpoint lists available log files filtered by date range, and the get-log-file-content endpoint retrieves the content of specific log files. This approach is preferred for organizations with dedicated security operation centers and established SIEM platforms, offering low latency for timely detection and response.
For Foundry-based analysis:
For organizations without dedicated SIEM tooling or organizations with lighter analytical needs, both audit.2 and audit.3 logs can be exported to per-organization Foundry datasets. Organization admins configure the target file system location during setup. Once exported, logs can be analyzed directly in Foundry or forwarded to an external SIEM through Foundry's Data Connection application.
Refer to our audit delivery documentation for detailed API endpoint information and export setup instructions.
The infrastructure through which audit logs flow from generation to storage is engineered to be append-only, ensuring audit trail integrity. Access to log archival storage is aggressively restricted. If information captured in audit logs must be removed for legal purposes, you can work with Palantir Support directly to identify a remediation plan to eradicate the suspected disallowed data in place within audit log storage.
Upon ingesting audit logs, security and compliance teams typically focus on themes described in the following sections.
Detect and respond to potential security incidents, including the following:
Example investigation workflow:
A security analyst receives an alert about unusual data access by a user account. Using audit.3 logs with category filtering:
time filter where categories contains dataLoad for the user in question.resultFields to identify exactly which datasets were accessed.categories contains dataExport to verify whether any data was actually exported.users and entities fields to understand the complete activity timeline.The structured audit log categories eliminate the need to know which specific Foundry services or event names to search for; the analyst can focus on understanding behavior rather than navigating system architecture.
For organizations handling sensitive or regulated data:
Example compliance workflow:
A compliance team needs to verify that patient data exports only occurred for users with appropriate training certifications:
time filter where categories contains dataExport and resources match patient datasets.uid field against internal certification records.Audit logs are organized into audit categories that group related events by intent and action type. Categories provide a product-agnostic way to identify relevant events; for example, the dataExport category captures all data export events regardless of which Foundry application performed the export.
This abstraction enables security analysts to reason about user behavior without deep knowledge of Foundry's internal architecture. When investigating potential data exfiltration for example, simply filter for dataExport rather than enumerating dozens of product-specific event names. Categories frequently used in security monitoring and compliance workflows might include the following:
| Category | Description | Example use case |
|---|---|---|
authenticationCheck | Checks authentication status via a programmatic or manual authentication event, such as token validation. | Detect token validation patterns that suggest credential stuffing. |
dataCreate | Indicates the addition of some new entry of data into the platform where it did not exist prior. This event may be reflected as a dataPromote in a separate service if it is logged in the landing service. | Track data creation patterns and enforce governance policies. |
dataDelete | Related to the deletion of data, independent of the granularity of that deletion. | Alert on deletion of critical or protected resources. |
dataExport | Export of data from the platform. Use for things like downloading data from the platform, such as a system external to Palantir, CSV file and more. If data was exported to another Palantir system, use the dataPromote category. | Alert on large exports, exports of sensitive data, or exports outside business hours. |
dataImport | Imports to the platform. Unlike dataPromote, dataImport refers only to data being ingested from outside the platform. This means that a dataImport in one service could show up as a dataPromote in a separate service. | Monitor for malicious file uploads or policy violations. |
dataLoad | Refers to the loading of data to be returned to a user. For purely backend loads, use internal. | Establish baseline normal access patterns and detect anomalous bulk data access. |
tokenGeneration | Action that leads to generation of a new token. | Detect unusual token creation that could indicate preparation for bulk data access. |
userLogin | Login events of users. | Monitor for failed login attempts, unusual login times, or geographic anomalies. |
userLogout | Logout events of users. | Track session durations and identify abnormally long sessions. |
For the complete list of available categories with detailed field specifications, refer to our full audit log categories documentation.
Performance note: Audit log datasets can contain very high volumes of data. Always filter using the time column before performing aggregations or visualizations to ensure performant queries.
Audit log categories enable powerful, maintainable queries that work across all Foundry products. In pseudo-code this would look like the following:
Monitoring all export activity:
categories contains "dataExport"
Investigating potential credential compromise:
categories contains "authenticationCheck" AND result = "FAILURE"
GROUP BY uid
HAVING COUNT(*) > 5
Tracking permission changes on sensitive resources:
categories contains "managementPermissions" AND resource_id IN (sensitive_resource_list)
The category-based approach ensures queries remain valid even as new features are added. New export capabilities we develop will use the dataExport category without requiring query updates in your analyses.
Before implementing automated alerting, establish baselines for normal activity:
Anomalies are only meaningful in context. Understanding normal behavior patterns and platform usage enables high-fidelity alerting with minimal false positives.
Layer multiple detection mechanisms:
When working with large audit datasets:
time range first to reduce data volume.categories filters early in query pipeline before examining detailed fields.As part of Foundry's shared security model, Palantir's Computer Incident Response Team (CIRT) monitors hosted customer platforms for security threats. CIRT maintains alerting and detection strategies ↗ targeted towards activity on our hosted customer platforms. If CIRT identifies suspicious activity on your platform, you will be contacted to reconcile the activity.
We encourage customers to implement their own audit log monitoring in accordance with their understanding of normal user behavior and organizational security requirements; you have the domain knowledge to identify anomalies that platform-level monitoring cannot detect. Only you can ensure that usage of your platform is appropriate and meets your own policies and obligations.
For new implementations, follow the steps below that are discussed in detail throughout this documentation:
For additional assistance with audit log monitoring or questions about specific use cases, contact Palantir Support.