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 <organization-api-key>; 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:

exporters:
  otlphttp/superagent:
    endpoint: https://superagent.sh/api/v1/infrastructure/sources/<source-id>
    headers:
      Authorization: "Bearer <organization-api-key>"
    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:

   https://superagent.sh/api/v1/infrastructure/sources/<source-id>/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 <organization-api-key> 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 and custom endpoint setup 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 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 or the MCP server 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.