feat: declare a risk tier on every command in the catalog

467 of the 1592 commands carried no `risk:`. An unset risk is read as
destructive by the agent approval gate, so half the catalog's write side sat
behind the same prompt — and, in HarfangLab's case, 39 pure lookups did too.
A gate that stops everything stops being read as a signal, which is the
argument already made for the toolkit and for sentinelone (df27876).

The catalog is now 1027 read, 261 safe_write, 304 destructive, with nothing
defaulted. The line follows the one sentinelone drew: impact on the estate,
not reversibility — isolate-agent is reversible and is the canonical
destructive example.

  read        only queries; changes nothing outside Riposte
  safe_write  additive or reversible inside the tool's own case/enrichment
              plane: comments, tickets, tags, alert statuses, threat-intel
              records, sandbox submissions, collection jobs, outbound messages
  destructive changes the estate or weakens a control: containment, blocklists
              and allowlists, exclusions and detection rules, every delete,
              identity and credential operations, code on a host, generic
              API escape hatches

Three calls that were not obvious, and are now applied throughout:

- Undoing a containment is tiered like the containment it lifts. Un-isolating
  a host or un-banning an IP mid-incident is its own decision, not a return to
  a neutral state. The catalog contradicted itself here — crowdstrike's
  lift_containment was destructive while harfanglab's deisolate_from_threat
  was safe_write — so deisolate_from_threat and unquarantine_file are
  re-tiered to destructive, the only two existing tiers this pass changes.
- Retrieving a live secret is destructive: cyberark get_password, delinea
  get_secret, vault read_secret, beyondtrust get_credential. It is a GET, but
  the tier describes the stake, not the HTTP verb.
- Sending outward to humans stays safe_write — slack, teams, twilio, telegram,
  mail. Irreversible, but it is the collaboration plane, not the estate.

An object created but not yet referenced by a rule is safe_write; editing one
a rule already reads is destructive. That is why fortigate create_address and
panos create_custom_url_category are safe_write while update_address_group and
edit_custom_url_category are not.

The template and README never documented the field, which is how 467 commands
came to omit it. Both now carry the tier table and these rules, so the next
integration declares a tier instead of inheriting one.

111 packages get a MINOR bump and a changelog entry: an instance compares
versions to offer an update, so an unbumped manifest would leave the tiers
sitting in the catalog and never reaching the estates that need them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

integrations/splunk/manifest.yaml

@@ -1,8 +1,8 @@
 id: splunk
 name: Splunk
-version: 1.1.0
+version: 1.2.0
 description: "Splunk (REST API, management port 8089) — run SPL searches with notable/CIM finding ingestion and an OCSF mapper, manage search jobs, indexes and event submission (incl. HEC), full KV Store collection/entry management, and user administration. Token or basic authentication."
-changelog: "1.1.0 — Full coverage: search jobs (create/status/results), indexes listing, event submission (receivers/simple + HEC), and the complete KV Store command set (collection create/config/delete, list, data list/add/delete, entry search/delete/update). 1.0.0 — Initial release: SPL search (oneshot) ingestion with a bundled OCSF mapper for notable/CIM events, get_users, delete_user and a KV Store entry update."
+changelog: "1.2.0 — Declare the risk tier on the 10 commands that carried none: 6 safe_write, 4 destructive. An unset risk is read as destructive by the agent approval gate, so the 6 that only annotate sat behind the same prompt as the ones that change the estate. | 1.1.0 — Full coverage: search jobs (create/status/results), indexes listing, event submission (receivers/simple + HEC), and the complete KV Store command set (collection create/config/delete, list, data list/add/delete, entry search/delete/update). 1.0.0 — Initial release: SPL search (oneshot) ingestion with a bundled OCSF mapper for notable/CIM events, get_users, delete_user and a KV Store entry update."
 category: siem
 
 # Per-instance configuration. The REST API lives on the Splunk management port (default 8089),
@@ -123,6 +123,7 @@ commands:
   - id: submit_event
     name: splunk-submit-event
     description: "Submit a single event to an index via the REST receivers/simple endpoint."
+    risk: safe_write
     inputs_schema:
       properties:
         index: { type: string, description: "Target index name" }
@@ -135,6 +136,7 @@ commands:
   - id: submit_event_hec
     name: splunk-submit-event-hec
     description: "Submit an event through the HTTP Event Collector (HEC). Requires hec_url and hec_token in the instance config."
+    risk: safe_write
     inputs_schema:
       properties:
         event: { type: string, description: "Event payload (string or JSON object as a string)" }
@@ -158,6 +160,7 @@ commands:
   - id: delete_user
     name: splunk-delete-user
     description: "Delete a Splunk user by username."
+    risk: destructive
     inputs_schema:
       properties:
         username: { type: string, description: "Username to delete" }
@@ -177,6 +180,7 @@ commands:
   - id: kv_store_collection_create
     name: splunk-kv-store-collection-create
     description: "Create a new KV Store collection in an app."
+    risk: safe_write
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }
@@ -186,6 +190,7 @@ commands:
   - id: kv_store_collection_config
     name: splunk-kv-store-collection-config
     description: "Define field types on a KV Store collection (e.g. field.name=string). Pass a JSON object mapping field name to type."
+    risk: safe_write
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }
@@ -196,6 +201,7 @@ commands:
   - id: kv_store_collection_delete
     name: splunk-kv-store-collection-delete
     description: "Delete a KV Store collection and all of its data."
+    risk: destructive
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }
@@ -207,6 +213,7 @@ commands:
   - id: kv_store_collection_add_entries
     name: splunk-kv-store-collection-add-entries
     description: "Insert one or more entries into a KV Store collection (batch_save). Pass a JSON array of objects."
+    risk: safe_write
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }
@@ -228,6 +235,7 @@ commands:
   - id: kv_store_collection_data_delete
     name: splunk-kv-store-collection-data-delete
     description: "Delete ALL entries in a KV Store collection (the collection itself is kept)."
+    risk: destructive
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }
@@ -248,6 +256,7 @@ commands:
   - id: kv_store_collection_delete_entry
     name: splunk-kv-store-collection-delete-entry
     description: "Delete entries in a KV Store collection matching a Mongo-style query (JSON object)."
+    risk: destructive
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }
@@ -258,6 +267,7 @@ commands:
   - id: kv_store_update_entry
     name: splunk-kv-store-update-entry
     description: "Update a single field of an existing KV Store entry by key, preserving the other fields."
+    risk: safe_write
     inputs_schema:
       properties:
         app_name: { type: string, description: "App namespace (defaults to the instance 'app' config)" }