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

# Splunk network requirements

> Egress endpoints, the HTTPS-only transport policy, timeouts and retries, and what data leaves Splunk.

## Egress

The app makes outbound HTTPS requests from **search heads only**. Indexers and
forwarders make no connections.

| Destination | Port | Purpose |
| - | - | - |
| `api.kyberis.ai`, or your configured `base_url` | 443 | Batched enrichment calls to `POST /v2/assessments/batch` |

Allow this destination in any egress firewall or proxy policy that applies to
your search heads. Requests are batched — up to 50 indicators per call, never
one call per event.

The app has no proxy configuration; requests go directly from the search head to
the API endpoint.

## Transport policy

* `base_url` **must be `https://`**. Requests carry the API key and indicator
  values, so plaintext `http://` is rejected with an error. The only exceptions
  are local development targets that never leave the machine: `localhost`,
  `*.localhost`, literal loopback IPs (`127.0.0.0/8`, `::1`), and
  `host.docker.internal`.
* TLS certificates are always verified using Python's default certificate
  handling. There is deliberately no option to disable verification. If your
  network intercepts TLS, the intercepting CA must be trusted by the certificate
  store Splunk's Python runtime uses.

## Timeouts and retries

Configured in `kyberis.conf`; see `README/kyberis.conf.spec` in the app.

* `timeout_seconds`, default 20 — per-request timeout.
* `max_retries`, default 2 — retries for transient failures: connection errors
  and HTTP 429 or 5xx responses, with a short backoff.

When the API stays unreachable, affected events are annotated with
`kyberis_status=transport_error` and the search shows a warning. After two
consecutive failed batches, the command stops calling the API for the rest of
the search rather than adding retry latency to every remaining batch. See
[Troubleshooting](/integrations/splunk/troubleshooting).

## What data leaves Splunk

This is the transport-level summary. For the full statement — including what
Kyberis retains server-side and the controls you have — see
[Data handling and privacy](/integrations/splunk/privacy).

Each enrichment request contains:

* the **indicator values** being enriched — the contents of the fields you point
  `| kyberis field=` or the alert action at, and nothing else from the events;
* a static **agent context**: an objective string (a fixed default, or the
  `objective=` override typed by the user), a fixed requested-outcome and
  workflow-stage string, the Splunk search ID as `run_id`, and a batch counter as
  `step_id`;
* the `Authorization` header with the profile's API key.

### The raw SPL of your searches is never sent

This is runtime-enforced, not just policy: every outgoing payload is checked
against the running search's SPL text, and a request that would contain it is
blocked before sending. The search fails with an explicit privacy error asking
you to report the bug.

## What the app keeps locally

Successful verdicts are cached in your own KV Store (`kyberis_ioc_cache`:
indicator, verdict fields, and fetch timestamp, expiring after
`cache_ttl_seconds`), and the alert action indexes verdict events into an index
you choose. Neither leaves your Splunk environment.