> ## 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. # Kyberis enrichment alert action > Parameters, indexed event shape, Enterprise Security adaptive response, and failure policy for the Splunk alert action. The **Kyberis enrichment** alert action enriches indicator values from an alert's triggering results and indexes one JSON event per unique indicator as sourcetype `kyberis:threat_activity`. It is available on every core Splunk alert, and — via its Common Action Model metadata — as an adaptive response action in Enterprise Security, verified on ES 8. It reuses the same enrichment core and KV Store cache as `| kyberis`, so alert-triggered enrichments and interactive searches warm each other's cache. ## Parameters Configured per alert, with defaults from `default/alert_actions.conf`: | Parameter | Default | Meaning | | - | - | - | | Indicator fields | `src,dest,src_ip,dest_ip,domain,url,file_hash` | Comma-separated result fields to read indicator values from. Fields a result row does not have are skipped, and multivalue fields are handled. | | Credential profile | *(empty)* | Named credential profile. Empty uses `default_profile` from `kyberis.conf`. | | Destination index | *(empty — chosen automatically)* | Index the enrichment events are written to. Left empty, the action writes to `threat_activity` when that index exists (Enterprise Security installs it, and its `Threat_Activity` dataset is defined as `index=threat_activity`), and to `main` otherwise. A value set here always wins. The index must already exist — the action fails with a clear error rather than auto-creating indexes. | | Max indicators | `100` | Cap on unique indicators enriched per invocation, a cost guard for wide alerts. `0` removes the cap. When the cap trims the list, a warning is logged. | The role that owns the alert needs `list_storage_passwords` and write access to the destination index; see [Permissions](/integrations/splunk/permissions). ## Indexed event shape One event per unique indicator. A value seen in several fields or rows keeps its first occurrence. ```json theme={null} { "indicator": "malicious-domain.example", "indicator_field": "domain", "orig_sid": "scheduler__admin__search__RMD5...at_1753692000_42", "orig_rid": 0, "search_name": "Suspicious outbound traffic", "kyberis_status": "ok", "kyberis_urgency": "today", "kyberis_score": 87, "kyberis_threat": "high", "...": "remaining kyberis_* fields", "threat_match_field": "domain", "threat_match_value": "malicious-domain.example", "threat_key": "kyberis", "threat_collection": "kyberis", "threat_collection_key": "" } ``` * `orig_sid`, `orig_rid`, and `search_name` link the event back to the triggering search and result row — the linkage Enterprise Security incident review correlates on. * The full `kyberis_*` field set is the same as the [`| kyberis` output](/integrations/splunk/search-command#output-fields). * The CIM `threat_*` fields appear only when the verdict meets `cim_min_threat`, exactly as at search time. * Events have no embedded timestamp; the index time is the enrichment time (`DATETIME_CONFIG = CURRENT`). **Every** verdict is indexed, benign ones included, so analysts see the answer for each indicator. Data model membership is narrower on purpose: the app's eventtype requires `threat_match_value=*`, so only events that qualified as threat matches are tagged `threat` and enter the Enterprise Security Threat Intelligence data model. Benign verdicts stay searchable via `sourcetype=kyberis:threat_activity` but out of the data model. ## Failure policy The action is designed to degrade rather than lose work: * A **mid-run plan limit** (HTTP 402) is not a failure. Already-enriched indicators are indexed with their verdicts, the remainder are indexed with `kyberis_status=plan_limit`, a warning is logged, and the action exits 0. * A **transport failure** annotates affected indicators with `kyberis_status=transport_error` — indexed, and retried by later runs since they are never cached — and logs a warning. * Configuration, credential, or missing-index problems exit non-zero with an actionable message and index nothing. Exit codes, for reference: | Code | Meaning | | - | - | | `0` | Success, including partial plan-limit runs and "no indicators found" | | `2` | Bad invocation payload, or splunkd connection failure | | `3` | Settings problem, or missing destination index | | `4` | Credentials rejected, or privacy guard tripped | | `5` | Indexing failed mid-write | Action output lands in `splunkd.log`, component `sendmodalert`; see [Troubleshooting](/integrations/splunk/troubleshooting#read-alert-action-logs). ## Adaptive response in Enterprise Security In Enterprise Security, the action appears under adaptive response actions, in the **Information Gathering** category, through the standard alert-action and Common Action Model mechanism. See the [compatibility matrix](/integrations/splunk/overview#compatibility-matrix). Attach it to a detection's response actions, or run it at triage time from a finding. On ES 8 that is Mission Control: open the finding, then **⋯ → Run adaptive response actions**. For the enriched events to reach the `Threat_Activity` dataset they must be indexed in `threat_activity`, which is what the action does by default on an ES instance. Pointing the action at another index keeps the enrichment but takes the events out of the data model. ## Test an alert action configuration Trigger it inline with `sendalert` on any search results: ``` index=_internal | head 5 | eval domain="malicious-domain.example" | sendalert kyberis_enrichment param.index="main" ``` Dispatching a saved search over REST with `trigger_actions=1` has been observed **not** to fire alert actions on Splunk 9.4. Use `| sendalert`, or a genuinely scheduled and triggered alert, to test.