Perplexity Enterprise Audit Logs: Rich Query Evidence Still Needs Policy Context

Perplexity Enterprise sends audit events to a customer-controlled HTTPS webhook as they occur. Its documented stream covers login and query events, generated answers and file activity, plus organization settings and Comet agent actions. Each event carries a UUID, timestamp, user email, and IP address. It also carries a user agent and optional session ID, with event-specific metadata. That is a stronger audit surface than an aggregate usage dashboard. I want to inspect what Perplexity's Audit Logs can prove, how the webhook can fail, and which enterprise policy fields still need a separate record.

TL;DR

• Perplexity Enterprise Audit Logs stream events by HTTPS POST in real time for organizations with 50 seats or at least one Enterprise Max user.
• The standard schema records an event UUID, RFC3339 timestamp, event type, and user email. It also records an IP address and user agent, with an optional session ID and metadata.
• Query and answer events provide detailed activity evidence alongside file, login, settings, and Comet agent events. Insights supplies aggregate adoption metrics.
• The documented event schema lacks a data classification and enterprise policy version. It also lacks an authorization outcome and verified delegated-agent principal.

The event stream is richer than an admin-change log

Perplexity describes its logs as capturing end-to-end queries across user input and agent steps through to answers, alongside administrative settings changes. The event catalogue includes login, query, answer_generated, and file_upload. It also includes file_download, organization_settings_update, admin_activity, membership batches, and comet_agent_action.

The query example stores query_str in metadata. An answer event can carry the generated answer and model. File attachments on a query include file UUID and file name. That means the stream can reconstruct far more than who changed a role. It can follow the input and generated output through a research session, with the files involved tied together through session_id when that field is present.

A UUID v4 gives each event a unique key, while the timestamp uses ISO 8601 in RFC3339 format. User email and client IP make incident triage practical when paired with the user agent. An investigator can put one query on the left side of a screen and its answer on the right, with the session identifier between them.

This deserves credit. Calling the stream "just application logs" would undersell what Perplexity exposes.

Webhook delivery is part of the audit system

Admins enable the feature in Organization Settings and provide an HTTPS webhook URL. They can also add an Authorization header. A token without spaces is sent under the Bearer scheme. A complete value containing a space supports a custom scheme, including the documented Splunk HEC pattern. Generic endpoints receive the standard JSON payload. Slack endpoints get Block Kit formatting, with metadata values truncated for Slack limits.

The receiver should answer with an HTTP 2xx status. Perplexity says 4xx and 5xx responses are logged as errors in its system. That leaves several implementation questions for the customer: how many delivery attempts occur, what backoff applies, where failed events can be replayed, and how an admin detects a receiver that quietly stopped accepting traffic. The published page defines response handling but gives no delivery guarantee or replay procedure.

A security review should test this path. Return a controlled 500 response. Rotate the authorization token, then disconnect the receiver for several minutes. Count what arrives after recovery and preserve the provider's error evidence. A real-time stream is an audit system only when the receiving side can prove completeness.

Webhook secrets should be stored in a managed secret store and scoped to ingestion. TLS validates the destination channel. The receiver still needs schema validation, duplicate handling keyed on uuid, restricted storage, and alerting on gaps.

Query content makes the log itself sensitive

Perplexity's event richness creates a second data channel. A query can contain customer information, contract text, source code, or a medical detail. The answer can repeat that material. File metadata reveals names that may carry project or client identifiers. Once streamed, those values leave Perplexity and enter the customer's SIEM, webhook processor, Slack workspace, or long-term archive.

The log pipeline therefore needs its own data classification. Slack is a particularly sharp example because the platform-specific format truncates individual metadata values to 500 characters and the metadata section to 2,500 characters. A security team gets a readable alert, but the message may be incomplete and may expose prompt content to a channel membership broader than the investigation group.

I would send operational notifications to Slack and keep the canonical raw event in a restricted store. A chat message is useful for waking someone up. It is a poor system of record.

Perplexity's enterprise data-retention and privacy guidance says uploaded files are deleted after seven days while threads and organization-level data are retained until specifically deleted. The customer-controlled audit archive needs an explicit retention period and deletion process of its own.

Insights and audit logs answer different questions

Perplexity's Enterprise Usage Analytics gives admins an aggregate view of adoption. The dashboard reports the registered population, monthly activity, query volume, and weekly trends. It also reports feature usage, internal-file versus web-only query types, and individual counts over seven and 30 days. It supports filtering and export.

Insights is the adoption view. It can show that query volume jumped during a product launch or that one team became a heavy user. The audit stream is the event view. It can show which email submitted a particular query and the answer returned, along with the files attached.

Keeping those purposes separate prevents a common investigation failure. An aggregate chart can identify the Tuesday when traffic rose. It cannot reconstruct a single prompt because aggregation discarded that granularity. The webhook stream can reconstruct the event, assuming delivery and storage were complete.

The threshold is the same in the current documentation: both features are exclusive to Enterprise organizations with 50 seats or more, or an organization with at least one Enterprise Max member. Procurement should confirm entitlement before an audit plan depends on either feature.

Identity evidence is strong for people and thinner for agents

For an interactive query, user email, IP address, user agent, and login events create a useful attribution chain. SSO can strengthen the email's connection to the corporate identity system. Session IDs correlate activity inside Perplexity.

Agent events raise another question. The documented comet_agent_action type says an automated action occurred, while the standard schema still carries user_email as the actor field. A delegated workflow needs both the human who authorized the chain and the non-human identity that executed each step. One email cannot express both roles without additional metadata.

The same issue appears when a customer application calls an AI API through a shared service credential. The post-authentication gap is the space between knowing who logged in and deciding what a specific agent may do under that person's authority. Perplexity's stream can provide excellent action lineage if agent metadata preserves both identities. A review should inspect actual events rather than infer the fields from the event name.

Policy outcome is the missing security primitive

The published standard schema has no dedicated field for enterprise data classification or allowed model route. It also lacks a business purpose, policy version, or allow/redact/block outcome. Metadata varies by event type, so a future or customer-specific payload could add context, but the documented contract makes none of those fields required.

That gap does not reduce the forensic value of the stream. It defines the limit of what the record proves. A query event shows that Perplexity received a query from an email and IP at a time. It does not prove that the enterprise evaluated the content against a versioned policy before the model saw it.

An independent decision record should link to the Perplexity event using session ID, request ID, or another stable key. It should carry the authenticated principal, relay identity, prompt classification, and destination route. It should also record the policy version, decision, timestamp, and integrity evidence. AI audit log schema design describes those fields, while signed audit logs for AI requests covers integrity at the decision boundary.

DeepInspect

This is the gap DeepInspect closes for HTTP AI requests routed through its stateless proxy. Before a customer application sends a query to an LLM endpoint, DeepInspect evaluates the supplied principal, role, prompt classification, model route, and versioned policy, then records the allow/redact/block outcome.

Perplexity Enterprise Audit Logs are the activity record for events inside Perplexity, including queries and answers, files and settings, plus Comet actions. DeepInspect produces the independent policy record for model traffic crossing its own boundary. Correlating both streams gives an investigator the provider event and the enterprise authorization decision without claiming coverage over direct Perplexity browser traffic that bypasses the proxy. Book a technical deep dive at deepinspect.ai.