Splunk delete capability lacks per-index permission boundary

Permission scope for the delete command

The delete capability in authorize.conf is a global grant with no per-index restriction. A role that holds delete can run the | delete search command against any index listed in that role's srchIndexesAllowed or srchIndexesDefault. This means widening search access to additional indexes automatically widens deletion access, and there is no separate delete_indexes setting to limit the scope.

Operational constraints

Deleted events are only marked as removed; they persist in buckets until those buckets roll to warm, cold, or frozen per indexes.conf retention policy. Splunk provides no native undelete command, and default audit logging does not always distinguish event-level deletion from index-level administrative deletion unless access or audit logging is explicitly configured.

Open questions

1. Can a role be granted delete while restricting its effective deletion scope to a strict subset of its searchable indexes without creating a separate role?
2. What combination of srchIndexesAllowed, srchIndexesDefault, and srchFilter provides the narrowest practical boundary for event deletion?
3. Which audit or access log channels reliably capture the user, app, and target index for each | delete invocation?