> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Sumo Logic

> Stream Forge security events to Sumo Logic with delivery monitoring and replay.

Forge exports newline-delimited JSON to a Sumo Logic **HTTP Logs and Metrics
Source**. It uses the same versioned `security_event.v1` records, event scope,
content controls, delivery ledger, and replay as [Security Exports](/integrations/security-exports).
Every category in the current export schema is supported, including optional identity activity.

## Connect Sumo Logic

1. In Sumo Logic, open **Data Management → Data Collection → Collection**.
   Create or select a Hosted Collector and add an **HTTP Logs & Metrics** source.
2. Name the source `Forge security events` and choose a source category such as
   `forge/security`. Forge preserves the source's name, category, host, and fields;
   it does not override them with HTTP metadata headers.
3. Under Advanced Options for Logs, disable **Multiline Processing** and
   **One Message Per Request**. Each physical line is one JSON event; embedded
   newlines in prompt or tool content are JSON-escaped.
4. Configure timestamp extraction from `occurred_at` (UTC ISO 8601). This avoids
   selecting another nested timestamp. Check the detected timestamp using the
   test event before enabling continuous delivery.
5. Save the source and copy its **Presigned URL**. Select this option rather than
   **Auth Header**. The URL includes its ingest credential.
6. In Forge, open **Integrations → SIEM and exports → Sumo Logic**. Paste the
   full presigned URL into **HTTP Source URL**, choose scope and content detail,
   and save.
7. Use **Test**, find the event in Sumo Logic Live Tail or Log Search, then
   activate the destination.

Forge encrypts the complete URL as an organization-scoped managed secret. The URL
is masked in the form and is not returned by the API or included in delivery
attempts or audit configuration. Leave the URL blank when editing to keep the
current credential; paste a newly generated URL to rotate it. After saving a
changed destination, test it again before resuming delivery.

TLS certificate validation is required. Production deployments also reject
private-network destinations. Requests do not follow redirects. Use a dedicated
source for Forge and regenerate its presigned URL if it is exposed.

See Sumo Logic's [HTTP source setup](https://www.sumologic.com/help/docs/send-data/hosted-collectors/http-source/logs-metrics/)
and [log upload contract](https://www.sumologic.com/help/docs/send-data/hosted-collectors/http-source/logs-metrics/upload-logs/).

## Find the test event

Replace the source category if you chose a different one:

```text theme={"system"}
_sourceCategory=forge/security
| json "forge_schema", "event_id", "category", "action", "occurred_at"
| where action = "security_export.test"
| fields _messagetime, forge_schema, event_id, category, action, occurred_at
```

Check that one exported JSON object appears as one message, `forge_schema` is
`security_event.v1`, the occurrence time is correct, and the selected fields are
present. A successful HTTP response proves request acceptance; Live Tail and
Log Search establish what Sumo Logic actually received and indexed. Processing
rules can filter accepted messages, and search visibility may be delayed.

## Cloud SIEM

Log Search ingestion and Cloud SIEM normalization are separate steps. This
integration does not install a Sumo Logic parser, log mapper, or detection rules.
Do not assume that forwarding JSON alone produces normalized SIEM records.

For a Cloud SIEM-enabled organization:

1. Create a custom JSON parser for the Forge v1 envelope and the log mappings
   appropriate to the event categories you export. Use representative test
   messages in Sumo Logic's Parser Editor and verify the mapped record type.
2. Configure the HTTP source's **Forward to SIEM** option and its `_parser` field
   with the path copied from that parser. Attach this configuration to the
   dedicated source so it applies to test, live, and replay events alike.
3. Preserve `event_id`, `source_event_id`, `organization_id`, `category`,
   `action`, `outcome`, and `occurred_at` in your parser/mapping. Map actor, device,
   and target fields according to the applicable record type; optional fields
   vary by category and detail policy.
4. Confirm that test events appear as normalized Cloud SIEM records. Inspect
   parser/mapping failures before enabling rules or relying on the stream.

Follow Sumo Logic's [ingestion best practices](https://www.sumologic.com/help/docs/cse/ingestion/cse-ingestion-best-practices/)
and [schema and log mapping guides](https://www.sumologic.com/help/docs/cse/schema/).

## Delivery and replay

The [versioned envelope schema](https://github.com/a37ai/agent-sec/blob/staging/packages/contracts/event-schemas/security-event.v1.schema.json)
applies to every line. Forge batches retained source records and sends requests
no larger than 1,000,000 uncompressed bytes. An event larger than the receiver limit cannot be sent; inspect failed
attempts and dead letters and deliberately review content detail before retrying. Forge does not silently truncate it to meet the receiver limit.

HTTP 408, 429, 5xx, and network failures are retryable. Other non-success HTTP
responses require remediation. Failed delivery does not advance the category's
live cursor. Retry exhaustion or a permanent rejection produces an unhealthy
destination and a dead letter. Correct the source or credential, test, and resume
it; the shared worker recovers the failed batch and resolves its dead letter.

Delivery is **at least once**. A lost response, worker crash, or partially accepted
multi-request batch can cause accepted events to be sent again. Successful ledger
batches are suppressed during normal delivery. Replay intentionally sends the
same destination-scoped `event_id` again without rewinding the live cursor.
Deduplicate consumers and searches by `event_id`, for example:

```text theme={"system"}
_sourceCategory=forge/security
| json "event_id"
| dedup 1 by event_id
```

Retained source data and durable cursors provide buffering; outbound payloads
are not retained indefinitely. The default replay lookback is 90 days, but actual
source retention can be shorter. Replay cannot recreate expired event bodies.

The destination page shows recent attempts, delivered/skipped counts, cursors,
unresolved failures, and replay results. The shared [security-export alert rules](https://github.com/a37ai/agent-sec/blob/staging/infra/monitoring/security-export-alerts.yaml)
cover Sumo Logic too. Operators must enable the authenticated telemetry-worker
metrics listener, load the rules, and route alerts independently of the failing
SIEM destination; see [Security Exports](/integrations/security-exports).

## Verification without a Sumo Logic account

Sumo Logic publishes a [receiver mock](https://github.com/SumoLogic/sumologic-kubernetes-tools/tree/main/src/rust/sumologic-mock)
for local collection tests. The [Kubernetes collection](https://github.com/SumoLogic/sumologic-kubernetes-collection)
uses this mock, and the [Logstash plugin](https://github.com/SumoLogic/logstash-output-sumologic/blob/main/spec/test_server.rb)
has its own HTTP receiver tests; the [Fluentd plugin](https://github.com/SumoLogic/fluentd-output-sumologic)
and [OpenTelemetry exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/sumologicexporter)
provide additional wire-format references. The OpenTelemetry exporter uses
newline-separated JSON log records and the HTTP Source's legacy
`application/x-www-form-urlencoded` content type, which Forge also uses. The
body contains raw JSON lines, not URL-encoded form fields.

For a repeatable local receiver, run the pinned vendor image:

```bash theme={"system"}
docker run --rm --name forge-sumo-receiver \
  -p 127.0.0.1:19300:3000 \
  sumologic/sumologic-mock@sha256:330cee327904cc1b8dc11c973b30139b6727fddba44da65ceae63fc08584615f \
  /usr/bin/sumologic-mock --store-logs
```

Place a TLS reverse proxy in front of this loopback receiver and trust its test
CA in the local Forge worker. Configure a task-local URL with the
`/receiver/v1/http/<test-code>` path through Forge's UI, then exercise Test,
activation, and replay. Leave certificate verification enabled. Read
`http://127.0.0.1:19300/logs/count` to confirm reception; the mock does not validate
Sumo cloud credentials. Inject 429/401 responses at the proxy to verify cursor
blocking and recovery without changing the vendor mock.

The receiver mock checks the collection boundary. It is not the Sumo Logic cloud
search or SIEM engine and cannot establish cloud indexing, timestamp extraction,
parser normalization, or rule behavior. An installed Sumo collector also forwards
data to the cloud; it does not provide a local Log Search or Cloud SIEM frontend.

For a dedicated cloud source, supply `SUMO_LOGIC_HTTP_SOURCE_URL` through the
secret environment and run the gated ingest check:

```bash theme={"system"}
FORGE_LIVE_SUMO_LOGIC=1 go test ./apps/control-plane/internal/securityexport \
  -run '^TestLiveSumoLogicIngest$' -v
```

Then find the printed synthetic `event_id` in Log Search and verify its Cloud
SIEM record separately. The check sends no production records. Do not put the
presigned URL in shell history, issue comments, recordings, or screenshots.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.