> For clean Markdown of this page, append .md to its URL. For the complete documentation index, see https://www.superagent.sh/llms.txt. Connect logs for security-one assessment, correlation, and webhook escalation. # Infrastructure log sources Superagent stores sanitized accepted logs and sends every event to security-one. The model decides whether activity is routine, needs more context, or indicates a threat. Only an explicit threat assessment meeting the configured threat-confidence threshold creates an incident. Routine and inconclusive assessments remain in analysis history and participate in correlation. Incidents are visible in the Infrastructure dashboard. Escalation always uses all enabled webhooks subscribed to infrastructure incidents. An organization owner manages these subscriptions under **Webhooks**. A successful response means the sanitized replay batch and its processing job have been durably saved. It does **not** mean assessment has finished. View reception, indexing, screening, and correlation coverage separately in the dashboard. ## Connect an OTLP source 1. Open **Infrastructure → Sources** in the dashboard and choose the organization you want to receive logs for. An organization owner selects **Add source** and gives the source a name and environment. Give related application and infrastructure sources the same **Application group** and environment to enable correlation. A blank group keeps the source separate. Other members can review incidents. 2. Copy the **Collector base URL** for an OTLP/HTTP exporter that appends `/v1/logs` itself, or the **Full logs endpoint** if your sender requires the complete URL. Do not append `/v1/logs` twice. 3. Create or reuse an organization API key in **Settings → API Keys**. The key is displayed only when created. Configure your sender with the header `Authorization: Bearer `; never put the key in the URL. 4. Send a small test batch, refresh the Infrastructure page, and check **Last received**, **batches received**, and **records received**. These counts reflect reception, independently of indexing and analysis. Owners can rename, disable, enable, or archive a source. Archiving stops reception and further analysis while preserving incident history. Source correlation scope becomes immutable once logs have been accepted. A Collector `otlphttp` exporter can use the base URL: ```yaml exporters: otlphttp/superagent: endpoint: https://superagent.sh/api/v1/infrastructure/sources/ headers: Authorization: "Bearer " compression: gzip ``` Add `otlphttp/superagent` to the **logs** pipeline's exporters. This example only configures the exporter, not the complete Collector pipeline. Review initial detections before enabling infrastructure incident subscriptions on your webhooks. ## Connect a Vercel Log Drain 1. Create a source in **Infrastructure** for the desired organization and copy its **Full logs endpoint**. In Vercel, go to **Team Settings → Drains → Add Drain**, choose **Logs**, and select **Custom Endpoint**. Set the **Endpoint URL** to the full HTTPS URL, for example: ```text https://superagent.sh/api/v1/infrastructure/sources//v1/logs ``` Use your actual public HTTPS origin if it differs; do not use the Collector base URL without `/v1/logs`. 2. Set **Format** to **JSON** (an array of log objects) or **NDJSON** (one log object per line). The endpoint accepts `Content-Type: application/json` for JSON and `application/x-ndjson` or `application/ndjson` for NDJSON. Do not select a Trace drain: this endpoint receives logs, not traces. 3. In **Custom Headers**, add `Authorization: Bearer ` using a key from **Settings → API Keys** for the source's organization. Do not put the key in the URL. Vercel's **Signature Verification Secret** is separate and is not checked by this endpoint; it does not replace the Authorization header. 4. Send a test log and refresh the source's reception counters. A `200` means the sanitized batch and processing job are saved. Analysis runs asynchronously; monitor the dashboard for pending work and incidents. See Vercel's [Log Drains format reference](https://vercel.com/docs/drains/reference/logs) and [custom endpoint setup](https://vercel.com/docs/drains/using-drains#custom-endpoint) for the current Vercel configuration options. ## Protocol and limits Send HTTPS `POST` requests to the full endpoint with either an OTLP `ExportLogsServiceRequest` (`Content-Type: application/x-protobuf` or `application/json` using protobuf JSON field names) or a Vercel Log Drain (`application/json` array of log objects, `application/x-ndjson` or `application/ndjson` newline-delimited log objects). A JSON object is treated as OTLP; a JSON array is treated as a drain batch. Empty OTLP objects and empty JSON arrays are valid, but NDJSON requires at least one object. UTF-8 is required; an optional `charset=utf-8` parameter and `gzip` compression are accepted. Traces, metrics, and OTLP/gRPC are not supported. The request body must be no larger than **4 MiB on the wire** and **16 MiB decompressed**. A batch may contain at most 10,000 log records. OTLP additionally limits batches to 1,000 resource groups, 1,000 instrumentation scopes, and 128 attributes per resource, scope, or log. Split larger batches before sending. A successful batch returns `200` only **after reception counters update**: OTLP JSON and Vercel drains receive JSON `{}`, and OTLP protobuf receives empty protobuf bytes. This means durable acceptance; assessment runs asynchronously. Errors for Vercel drains are JSON; OTLP protobuf errors remain protobuf. Malformed or unsupported requests return 4xx errors; a temporary storage or database failure returns `503` with `Retry-After`, so a sender can retry. An invalid key returns `401`, and a missing, disabled, or other-organization source returns `404` when authenticated. The existing [Telemetry destination](https://www.superagent.sh/docs/telemetry) sends Superagent events **out** to your collector; this Infrastructure source receives your logs **in**. Other vendor drain formats are not connected by their dashboard cards; use an OTLP-capable collector if their formats are not supported here. ## How assessment and escalation work Each accepted event reaches security-one; there are no static maliciousness filters, severity filters, or suspicious-only samples. Secret fields and common credential patterns are redacted before storage. Other personal or sensitive data can remain in logs; configure your sender's privacy controls appropriately. Unfamiliar fields are retained. Missing timestamps, redactions, conflicting provider IDs, and incomplete context remain explicit in evidence. Screening packs actual compiled model prompts around 4,000 tokens, with an 8,000-token hard limit and a separately bounded context allowance. Sources collect logs for up to 30 seconds before creating windows; indexing delays and outages can increase latency. Large events are fragmented by tokens and bytes, with every fragment tracked. Neighboring windows carry bounded overlap. A model result for one fragment cannot clear the whole original event as routine. Security-one first answers a general three-way assessment question. Ambiguous large windows can be localized into both halves. Investigation adds behavior, impact, and the next permitted evidence operation. The worker can retrieve scoped surrounding activity, historical activity, related sources, or adjacent context, then reassess using a focused or general probe. Retrieval is bounded to two rounds; remaining context is marked pending, never silently presented as complete. A short correlation pass runs every five minutes over the previous 15 minutes. An hourly pass covers the previous 24 hours. Both include routine activity and all observed entities, resources, actions, outcomes, and distinct message values. Repeated identical messages are counted together; unique messages are retained. Pages and token windows cover the entire result rather than a top-N list. Each window includes whole-period entity totals and a preceding-period baseline, so a sequence crossing page boundaries can still be assessed. Late arrivals receive an additional retrospective pass. Correlation coverage is tracked independently from first-pass screening. Threat probability and impact have different meanings. The model's threat probability must meet the policy threshold (default 0.8), and its impact assessment must meet your notification policy. Unknown impact remains reviewable. A routine result needs high confidence (default 0.9) and complete current evidence. To send webhooks: 1. Create an HTTPS destination under **Webhooks** and explicitly subscribe it to `infrastructure.incident.escalated` and **Infrastructure** sources. 2. No additional destination selection is needed. New escalations are sent to all enabled webhooks with both subscriptions, and setup completes once your source has received logs. The completed checklist collapses and remains expandable. 3. In **Settings** beside the Infrastructure page header, set the minimum impact and add trusted application context, such as sensitive assets, approved automation, and expected maintenance. Save the policy. Disable a webhook or remove its infrastructure subscription under **Webhooks** to stop future deliveries. Already queued events retain their original targets. The incident transition and signed webhook outbox are committed together. Retries reuse the same webhook event; repeated assessments merge into an active incident, with notifications for initial escalation or meaningful changes. The payload contains the incident ID, revision, impact, probabilities, scoped sanitized evidence, timestamps, and a dashboard link. Inspect delivery attempts and provide **Useful detection**, **Looks routine**, or **Unsure** feedback from an incident's detail panel on the Incidents page. Existing incident links open that panel, keeping the list available. The panel combines assessment, evidence, deliveries, and history in one view, with review status in its header dropdown. Daily analysis is unlimited by default, and token usage is tracked. Optional daily limits are managed by Superagent administrators and are not part of user settings. Model unavailability or an exhausted administrator-configured limit leaves work pending. A full ingestion backlog returns `429` before acknowledging additional data. ## Replay identity and retention Send a stable `Idempotency-Key` for transport retries where your exporter supports it. Reusing a key with different content returns `409`. Provider `event.id` or Vercel `id` values deduplicate repeated records within a source. Logs without a stable provider ID receive distinct batch/ordinal identities; retries without an idempotency key can therefore be counted and assessed again. A conflicting provider ID gets a flagged fallback identity rather than hiding the new content. ClickHouse retains indexed history for 30 days from indexing. Completed private replay blobs expire after 30 days; pending or failed batches remain recoverable. Detailed assessment windows remain for 30 days and usage records for 90 days. Incident evidence, revisions, and feedback remain in the application database. Logs counted by the reception-only version of this feature before this release were discarded and cannot be reconstructed. ## Review incidents Open **Infrastructure → Incidents** from the sidebar. Use the Findings-style search, table, or kanban view to review incidents. Search supports `status:`, `risk:`, `resolution:`, `source:`, `environment:`, and `group:` qualifiers. Results are paginated; **Load more** fetches further matches, and CSV export includes the loaded rows. Open an incident to inspect evidence, webhook deliveries, assessment revisions, and review history. Organization owners can mark an incident **New** or **In Review**, or resolve it as **Fixed**, **Accepted Risk**, **False Positive**, or **Won’t Fix**. Members can view decisions and evidence. Human decisions are audited and remain intact when security-one reassesses activity. Resolved incidents stop further webhook escalation for that episode; reopening clears the resolution. A later, separate episode can still produce a new incident. ## Incident API and MCP Use the [Incidents API](https://www.superagent.sh/docs/api/incidents) or the [MCP server](https://www.superagent.sh/docs/mcp) to list incidents, retrieve their assessment and evidence, and update review status. Updates require the current incident version and record the API key actor in the same audit history as dashboard reviews. --- Source: https://www.superagent.sh/docs/infrastructure-log-sources Index: https://www.superagent.sh/llms.txt