---
title: "Audit Log Streams"
description: "Learn how to stream Infisical Audit Logs to external logging providers."
---
Audit log streams is a paid feature.
If you're using Infisical Cloud, then it is available under the **Enterprise Tier**. If you're self-hosting Infisical, then you should contact team@infisical.com to purchase an enterprise license to use it.
Infisical Audit Log Streaming enables you to transmit your organization's audit logs to external logging providers for monitoring and analysis.
## Overview
1. Navigate to **Organization Settings**
2. Select the **Audit Log Streams** tab
3. Click **Add Log Stream**

If your log provider is included in this list, select it. Otherwise click on **Custom** to input your own Endpoint URL and headers.

Depending on your chosen provider, you'll be asked to input different credentials.
For **Custom**, you need to input an endpoint URL and headers.

Once you're finished, click **Create Log Stream**.
Your audit logs are now ready to be streamed.

## Example Providers
You can stream to Better Stack using a **Custom** log stream.
On Better Stack, select **Connect Source** and click **Create source** after providing a name.

Once your source is created, take note of the **endpoint** and **Source token** for the next step.

On Infisical, create a new audit log stream and select the **Custom** option.

1. Fill in the endpoint URL with your Better Stack source endpoint
2. Create a new header with key `Authorization` and set the value as `Bearer `

Once you're finished, click **Create Log Stream**.
Stream Infisical audit logs to Cribl Stream for centralized processing and routing. Infisical supports Cribl as a provider for seamless integration.
In Cribl Stream, navigate to **Worker Groups** and select your Worker Group. Take note of the **Ingress Address** for later steps.

Within your Worker Group, navigate to **Data > Sources > HTTP** and click **Add Source**.

Configure the **Input ID**, **Port**, and **Cribl HTTP event API** path (e.g., `/infisical`). Then, generate an **Auth Token**.
You can optionally configure TLS in the **TLS Settings** tab and add a pipeline in the **Pre-Processing** tab.
Ensure that you're using a port that's open on your instance.

Once you've configured the Data Source, click **Save** and deploy your changes.
On Infisical, create a new audit log stream and select the **Cribl** provider option.
Input the following credentials:
- **Cribl Stream URL**: Your HTTP source endpoint composed of `http://://_bulk`
- **Cribl Stream Token**: The authentication token from Step 1
If you configured TLS for your Data Source, use the `https://` protocol.

Once you're finished, click **Create Log Stream**.
You can stream to Datadog using the **Datadog** provider log stream.



On Infisical, create a new audit log stream and select the **Datadog** provider option.
Input your **Datadog Region** and the **Token** obtained from step 2.

Once you're finished, click **Create Log Stream**.
You can stream to Splunk using the **Splunk** provider log stream.
Navigate to **Settings** > **Data Inputs**.

Click on **HTTP Event Collector**.

Click on **New Token** in the top left.

Provide a name and click **Next**.

On the next page, click **Review** and then **Submit** at the top. On the final page you'll see your token.
Copy the **Token Value** and your Splunk hostname from the URL to be used for later.

On Infisical, create a new audit log stream and select the **Splunk** provider option.
Input your **Splunk Hostname** and the **Token** obtained from step 1.

Once you're finished, click **Create Log Stream**.
### Example Log Entry
```created-secret.json
{
"id": "7dc1713b-d787-4147-9e21-770be01cc992",
"actor": "user",
"actorMetadata": {
"email": "example@infisical.com",
"userId": "7383b701-d83f-45c0-acb4-04e138b987ab",
"username": "example@infisical.com"
},
"ipAddress": "127.0.0.1",
"eventType": "create-secret",
"eventMetadata": {
"secretId": "3e5c796e-6599-4181-8dca-51133bb3acd0",
"secretKey": "TEST-SECRET",
"secretPath": "/",
"environment": "dev",
"secretVersion": 1
},
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
"userAgentType": "web",
"expiresAt": "2025-01-18T01:11:25.552Z",
"createdAt": "2025-01-15T01:11:25.552Z",
"updatedAt": "2025-01-15T01:11:25.552Z",
"orgId": "785649f1-ff4b-4ef9-a40a-9b9878e46e57",
"projectId": "09bfcc01-0917-4bea-9c7a-2d320584d5b1",
"projectName": "example-project"
}
```
### Audit Logs Structure
Streamed audit log structure **varies based on provider**, but they all share the audit log fields shown below.
The unique identifier for the log entry.
The entity responsible for performing or causing the event; this can be a user or service.
The metadata associated with the actor. This varies based on the actor type.
This metadata is present when the `actor` field is set to `user`.
The unique identifier for the actor.
The email address of the actor.
The username of the actor.
This metadata is present when the `actor` field is set to `identity`.
The unique identifier for the identity.
The name of the identity.
This metadata is present when the `actor` field is set to `service`.
The unique identifier for the service.
The name of the service.
If the `actor` field is set to `platform`, `scimClient`, or `unknownUser`, the `actorMetadata` field will be an empty object.
The IP address of the actor.
The type of event that occurred. Below you can see a list of possible event types. More event types will be added in the future as we expand our audit logs further.
`get-secrets`, `delete-secrets`, `get-secret`, `create-secret`, `update-secret`, `delete-secret`, `get-workspace-key`, `authorize-integration`, `update-integration-auth`, `unauthorize-integration`, `create-integration`, `delete-integration`, `add-trusted-ip`, `update-trusted-ip`, `delete-trusted-ip`, `create-service-token`, `delete-service-token`, `create-identity`, `update-identity`, `delete-identity`, `login-identity-universal-auth`, `add-identity-universal-auth`, `update-identity-universal-auth`, `get-identity-universal-auth`, `create-identity-universal-auth-client-secret`, `revoke-identity-universal-auth-client-secret`, `get-identity-universal-auth-client-secret`, `create-environment`, `update-environment`, `delete-environment`, `add-workspace-member`, `remove-workspace-member`, `create-folder`, `update-folder`, `delete-folder`, `create-webhook`, `update-webhook-status`, `delete-webhook`, `webhook-triggered`, `get-secret-imports`, `create-secret-import`, `update-secret-import`, `delete-secret-import`, `update-user-workspace-role`, `update-user-workspace-denied-permissions`, `create-certificate-authority`, `get-certificate-authority`, `update-certificate-authority`, `delete-certificate-authority`, `get-certificate-authority-csr`, `get-certificate-authority-cert`, `sign-intermediate`, `import-certificate-authority-cert`, `get-certificate-authority-crl`, `issue-cert`, `get-cert`, `delete-cert`, `revoke-cert`, `get-cert-body`, `create-pki-alert`, `get-pki-alert`, `update-pki-alert`, `delete-pki-alert`, `create-pki-collection`, `get-pki-collection`, `update-pki-collection`, `delete-pki-collection`, `get-pki-collection-items`, `add-pki-collection-item`, `delete-pki-collection-item`, `org-admin-accessed-project`, `create-certificate-template`, `update-certificate-template`, `delete-certificate-template`, `get-certificate-template`, `create-certificate-template-est-config`, `update-certificate-template-est-config`, `get-certificate-template-est-config`, `update-project-slack-config`, `get-project-slack-config`, `integration-synced`, `create-shared-secret`, `delete-shared-secret`, `read-shared-secret`.
The metadata associated with the event. This varies based on the event type.
The user agent of the actor, if applicable.
The type of user agent.
The expiration date of the log entry. When this date is reached, the log entry will be deleted from Infisical.
The creation date of the log entry.
The last update date of the log entry. This is unlikely to be out of sync with the `createdAt` field, as we do not update log entries after they've been created.
The unique identifier for the organization where the event occurred.
The unique identifier for the project where the event occurred.
The `projectId` field will only be present if the event occurred at the project level, not the organization level.
The name of the project where the event occurred.
The `projectName` field will only be present if the event occurred at the project level, not the organization level.