Search audit logs for ACS activity

Use ACS audit events to review and investigate ACS API activity.

The Admin Config Service (ACS) API records audit events for each ACS request. These events are stored in the _audit index of the targeted Splunk Cloud Platform stack. Review ACS audit events for details about ACS request activity.

ACS audit events can include the HTTP method, request path, response code, redacted request and response bodies, error information, and downstream splunkd or Splunkbase calls made to complete the request. This information can help you identify who initiated an operation, confirm whether it succeeded, trace a request, and investigate failures.

Use the Search & Reporting app in Splunk Web to search the _audit index in the target stack.

For more information about audit activity, the _audit index, and audit log formats, see Auditing activities in a Splunk platform instance.

Requirements

To search the audit log for ACS activity:

  • You must have access to Splunk Web for the Splunk Cloud Platform stack targeted by the ACS API request.
  • You must have permission to search the _audit index.
  • You must open the Search & Reporting app in the target stack.
  • You must select a time range that includes the ACS API operation that you want to review.
Important: ACS audit events use sourcetype=audittrail, which stores events in the audit trail string format. ACS does not write these events to the JSON-based sourcetype=audittrailv2. A search limited to audittrailv2 does not return the ACS events described in these topics.

Prepare to search ACS audit events

Before you search, identify the target stack and the approximate time when the ACS API request ran. The _audit index also contains events generated by Splunk Cloud Platform and other services. To return only ACS events, filter on the generated_by value as shown in Search ACS audit events.

The generated_by value for ACS ends with :admin-config-service. The leading wildcard in the filter accounts for differences in the service identity between deployments.

Search ACS audit events

List ACS audit events in the target stack and use the request ID to group events that belong to the same ACS API request.

List ACS audit events in the target stack to review administrative activity, create reports, dashboards, or alerts, and investigate failed ACS operations. One ACS API request typically generates multiple audit events. Each event represents a stage of the request, such as receipt of the request, the resource operation, or the final HTTP response.

Several events with the same action value do not necessarily indicate that the operation ran more than once. Use request_id to correlate events from the same request, and use the request.handled event to determine the final ACS result.

  1. In Splunk Web, open the Search & Reporting app for the target stack.
  2. Select a time range that includes the ACS API operation that you want to review.
  3. Run the following search:
    JSON 
    index=_audit sourcetype=audittrail
| spath input=info path=generated_by output=generated_by
| search generated_by="*:admin-config-service"
| spath input=info path=request_id output=request_id
| spath input=info path=result output=result
| spath input=info path=parameters.message output=message
| spath input=info path=parameters.stackType output=stack_type
| spath input=info path=parameters.userRoles{} output=user_roles
| table _time action message result user user_roles stack_type request_id
| sort -_time

The search returns ACS audit events in reverse time order. Use the request_id value to group events that belong to the same ACS API request.

For details about the audit event format and the spath commands used in this search, see ACS audit event format and spath commands.

ACS audit event format and spath commands

Use spath to extract nested values from ACS audit events.

ACS audit events in the audittrail sourcetype are stored as strings, not JSON events. Use spath to extract nested values from the serialized JSON in the info field.

ACS audit event string format

The following example shows the string produced for a successful index creation request:

JSON 
Audit:[timestamp=07-21-2026 18:35:29.175, user=admin, action=indexes.create, info={"generated_by":"system:serviceaccount:admin-config-service:admin-config-service","parameters":{"code":202,"durationMS":"742.318","message":"request.handled","method":"POST","path":"/my-stack/adminconfig/v2/indexes","stackType":"classic","userRoles":["admin"]},"request_id":"0be0b936-98f3-9c19-9aad-03ee4b2471a5","result":"success","timestamp":1784658929175}]

The fields and their order can vary by event stage. Splunk Cloud Platform extracts user, action, and info from the outer Audit:[...] string. The user and action fields are directly searchable. The info portion contains serialized JSON. After Splunk Cloud Platform extracts info from the audit string, info remains a string, so its nested values are not directly searchable as fields.

Common spath commands in ACS audit searches

The spath input=info commands parse the JSON contained in the info string. Each command extracts one nested value and assigns it a shorter output field for displaying and filtering.

Table 1. Common spath commands in ACS audit searches
Command Result
spath input=info path=request_id output=request_id Extracts the request correlation identifier.
spath input=info path=parameters.message output=message Extracts the event stage from the nested parameters object.
spath input=info path=parameters.stackType output=stack_type Extracts the Splunk Cloud Platform Experience.
spath input=info path=parameters.userRoles{} output=user_roles Extracts the userRoles JSON array as a multivalue field.

Raw request and response parameters

When available, the rawRequest and rawResponse parameters are strings nested inside the JSON stored in info. For example, a JSON response can appear in info as "rawResponse":"{\"message\":\"index already exists\"}". ACS redacts sensitive values before logging captured payloads. Raw content can be redacted or omitted when ACS cannot safely capture it. Extract the rawResponse value before parsing or displaying its contents.

For more information about extracting fields from JSON, see spath in the Search Reference.

Search final ACS request results

Use the request.handled message to find the final result of an ACS API request.

Use the final request.handled event to determine the ACS response code and request outcome. Intermediate downstream events can fail and be retried before the ACS request completes successfully.

  1. To search ACS API requests that completed successfully, run the following search:
    JSON 
    index=_audit sourcetype=audittrail
| spath input=info path=generated_by output=generated_by
| search generated_by="*:admin-config-service"
| spath input=info path=request_id output=request_id
| spath input=info path=result output=result
| spath input=info path=parameters.message output=message
| spath input=info path=parameters.code output=code
| spath input=info path=parameters.stackType output=stack_type
| spath input=info path=parameters.userRoles{} output=user_roles
| search message="request.handled" result="success"
| table _time action user user_roles stack_type code request_id
| sort -_time

    The code field contains the final HTTP response code. For example, a successful asynchronous index creation request has a response code of 202.

  2. To search ACS API requests that completed with a failure, run the following search:
    JSON 
    index=_audit sourcetype=audittrail
| spath input=info path=generated_by output=generated_by
| search generated_by="*:admin-config-service"
| spath input=info path=request_id output=request_id
| spath input=info path=result output=result
| spath input=info path=parameters.message output=message
| spath input=info path=parameters.code output=code
| spath input=info path=parameters.error output=error
| spath input=info path=parameters.rawResponse output=raw_response
| spath input=info path=parameters.stackType output=stack_type
| spath input=info path=parameters.userRoles{} output=user_roles
| search message="request.handled" result="fail"
| table _time action user user_roles stack_type code error raw_response request_id
| sort -_time

    The final request.handled event contains the ACS response code and can contain the response body in raw_response. A related event with the same request_id can contain additional error information.

  3. To trace one ACS API request, replace {request_id} with a request ID from another ACS audit search, then run the following search:
    JSON 
    index=_audit sourcetype=audittrail
| spath input=info path=generated_by output=generated_by
| search generated_by="*:admin-config-service"
| spath input=info path=request_id output=request_id
| spath input=info path=result output=result
| spath input=info path=parameters.message output=message
| spath input=info path=parameters.code output=code
| spath input=info path=parameters.error output=error
| spath input=info path=parameters.stackType output=stack_type
| spath input=info path=parameters.userRoles{} output=user_roles
| search request_id="{request_id}"
| table _time request_id action message result user user_roles stack_type code error
| sort _time

    Sort the results in ascending time order to see the request lifecycle. Use the request.handled event to determine the final result.

  4. To view one summary row for each ACS request, run the following search:
    JSON 
    index=_audit sourcetype=audittrail
| spath input=info path=request_id output=request_id
| spath input=info path=result output=result
| spath input=info path=generated_by output=generated_by
| spath input=info path=parameters.message output=message
| spath input=info path=parameters.userRoles{} output=user_roles
| where match(generated_by, "^system:serviceaccount:[^:]+:admin-config-service$")
| eval roles=if(isnull(user_roles), "(not captured)", mvjoin(user_roles, ", "))
| eval event_rank=case(message="request.handled", 0, user!="anonymous" AND isnotnull(user_roles), 1, true(), 2)
| sort 0 request_id event_rank -_time
| dedup request_id
| table _time action user roles message result request_id generated_by
| sort 0 -_time

    The search returns one row for each ACS request ID, including the user and authenticated Splunk roles. When a request has multiple audit events, the search prefers the final request.handled event. If no request.handled event is available, the search selects an event with an authenticated user and captured roles.

Search allowlist changes in ACS audit events

Review ACS audit events for IP allow list changes.

Use an ACS audit search to review allowlist add and delete operations and identify submitted CIDRs.

To view allowlist changes and submitted CIDRs, run the following search:
JSON 
index=_audit sourcetype=audittrail action IN ("allowlist.add_subnets", "delete.subnets", "delete.subnet", "create.allowlist.v6", "delete.allowlist.v6", "delete.allowlists.v6")
| spath input=info path=request_id output=request_id
| spath input=info path=parameters.message output=message
| spath input=info path=parameters.path output=path
| spath input=info path=parameters.userRoles{} output=user_roles
| spath input=info path=parameters.rawRequest.subnets{} output=cidrs_structured
| spath input=info path=parameters.rawRequest output=raw_request
| spath input=raw_request path=subnets{} output=cidrs_string
| search message="request.received"
| rex field=path "/ipallowlists(?:-v6)?/(?<cidr_from_path>[^?]+)$"
| eval cidrs=coalesce(cidrs_structured, cidrs_string, cidr_from_path)
| eval roles=mvjoin(user_roles, ", ")
| eval cidrs=mvjoin(cidrs, ", ")
| table _time action user roles cidrs path request_id
| sort 0 -_time

This search returns allowlist add and delete operations, including IPv4 and IPv6 changes. It extracts CIDRs from the captured request body. For single-CIDR deletes, the CIDR can also be present in the request path. Historical events without a captured request body cannot recover batched CIDRs.

ACS audit search filters

Use common filters to narrow ACS audit searches.

Use common filters to narrow ACS audit searches by action, user, role, stack type, or result. Add filters after extracting the corresponding fields with spath.

Common ACS audit search filters

Table 2. ACS audit search filters
To find Add this filter
One action action="apps.install"
Actions with a common prefix action="describe.*"
One user user="admin"
Events for a user role user_roles="sc_admin"
Events for Classic Experience stack_type="classic"
Events for Victoria Experience stack_type="victoria"
Any failed event, including a failed intermediate call result="fail"

Use an exact action value when possible. To search by a prefix, place the wildcard at the end of the value. A wildcard in the middle of an action can produce inconsistent results when the value contains punctuation.

ACS audit event data

ACS audit events contain top-level fields from the audit trail string and nested values from the serialized JSON in info.

ACS audit events contain top-level fields from the audit trail string and nested values from the serialized JSON in info. The available values depend on the event stage.

ACS audit event fields

The available values depend on the event stage. An ACS audit event contains the following main fields:

Table 3. Main ACS audit event fields
Field Description
_time Time when the event occurred.
user Splunk Cloud Platform user associated with the event. Early authentication events can have the value anonymous.
action ACS API operation, such as indexes.create or apps.install.
info String containing serialized JSON with the request ID, result, producer identity, and event parameters.

The JSON data serialized in info contains the following fields:

Table 4. Serialized JSON fields in info
Field Description
generated_by Identity of the service that generated the event.
parameters Optional information specific to the event stage.
request_id Correlation identifier shared by events generated for the same ACS API request.
result Event result: success, fail, or none.
timestamp Event time in Unix epoch milliseconds.

The parameters included in an event depend on the event stage. ACS omits parameters that do not apply to an event stage.

ACS audit event stages

The following table describes events that an ACS API request can generate:

Table 5. ACS audit event stages
Event stage result parameters.message Common parameters
Request received none request.received method, path, rawRequest, apiVersion, userAgent
Downstream request none splunkd.request or splunkbase.request method, url, path, rawQuery
Downstream response success or fail splunkd.response or splunkbase.response method, url, path, code, durationMS, responseBytes
Downstream error fail splunkd.error or splunkbase.error method, url, path, durationMS, error
Resource operation success or fail Resource-specific message, or no message name, other supported resource fields, error
Request handled success or fail request.handled method, path, code, durationMS, responseBytes, rawResponse

The stackType parameter is available after ACS resolves the stack, and the userRoles parameter is available after ACS authenticates the user. Events generated earlier might not contain one or both parameters.

ACS audit result and message values

Use result to determine the outcome of an individual event. Use parameters.message to determine the stage of the request represented by the event.

Table 6. ACS audit result and message values
Field Value Description
result success The event completed successfully.
result fail The event failed. Review message, code, error, and rawResponse.
result none An outcome is not available yet. This value is commonly used when a request or downstream call begins.
message request.received ACS received the API request after stack validation and authentication populated the request context.
message request.handled ACS completed the HTTP request. Use this event to determine the final result.
message splunkd.request ACS sent a request to splunkd.
message splunkd.response ACS received a response from splunkd.
message splunkd.error A splunkd request failed before ACS received a usable response.
message splunkbase.request ACS sent a request to Splunkbase.
message splunkbase.response ACS received a response from Splunkbase.
message splunkbase.error A Splunkbase request failed before ACS received a usable response.

Other message values describe resource-specific stages, such as read stack information succeeded. ACS can omit a message when the event itself represents the resource operation result.

ACS audit event parameters

The following table lists the parameters supported by ACS audit events. All parameters are optional and depend on the event stage.

Table 7. ACS audit event parameters
Parameter Type Description
message String Event stage or resource-specific description.
error String Error information for a failed event.
method String ACS or downstream HTTP method.
path String ACS or downstream request path.
rawRequest String Captured request body. The value can be omitted or redacted.
rawResponse String Captured response body. The value can be omitted or redacted.
rawQuery String URL query string.
referer String HTTP Referer header, when supplied.
userAgent String HTTP User-Agent header.
status String or number Resource-specific status, when supplied.
code Number ACS or downstream HTTP response code.
apiVersion String ACS API version, such as v2.
durationMS String or number Operation duration in milliseconds. Use tonumber() for numeric comparisons.
responseBytes Number Response size in bytes.
url String Full downstream URL, most commonly a splunkd endpoint.
name String Resource name, such as an index, policy, or stack.
tokenID String Token identifier, when applicable.
tokenName String Token name, when applicable.
tokenStatus String Token status, when applicable.
maintenanceName String Maintenance window name, when applicable.
stackType String Splunk Cloud Platform Experience: classic or victoria.
userRoles Array of strings Roles assigned to the authenticated user. Extract this value with parameters.userRoles{}.

ACS captures request and response bodies up to 64 KiB. ACS omits larger bodies and requests with an unknown size. ACS sanitizes captured JSON, form, and multipart bodies. ACS replaces token and password fields and uploaded file contents with [REDACTED]. ACS can redact unsupported or malformed bodies in full.

ACS audit action values

Review action values for ACS API operations.

Review ACS audit action values to identify ACS API operations in audit events. The action value remains the same for all events generated by one API request. ACS records the Splunk Cloud Platform Experience separately in parameters.stackType, except when Classic Experience and Victoria Experience use different operations, such as patch.app.classic and patch.app.victoria.

The following sections list ACS audit action values.

Indexes

CODE 
indexes.create                  indexes.update
delete.index                    get.index.info
list.indexes

Apps and app permissions

CODE 
apps.install                    app.export.download
list.apps                       list.apps.victoria
describe.app                    describe.app.victoria
describe.splunkbase.app         patch.app.classic
patch.app.victoria              uninstall.app
uninstall.app.victoria          describe.app.feature.enablement
set.app.feature.enablement      describe.permissions.apps
list.permissions.apps           patch.permissions.apps
describe.permissions.federated.provider
update.permissions.federated.provider

Users, roles, tokens, and capabilities

CODE 
create.user                     describe.user
list.users                      patch.user
users.delete                    create.role
describe.role                   list.roles
patch.role                      roles.delete
create.token                    get.token.info
list.tokens                     delete.token
list.capabilities

IP allow lists, outbound ports, and private connectivity

CODE 
allowlist.add_subnets           describe.allowlist
create.allowlist.v6             describe.allowlist.v6
delete.allowlist.v6             delete.allowlists.v6
delete.subnet                   delete.subnets
add.outbound.ports              get.outboundports
describe.outboundports          delete.outboundport
create.outbound.ports.v6        list.outbound.ports.v6
describe.outboundports.v6       delete.outbound.ports.v6
enable.private.connectivity     describe.private.connectivity
update.private.connectivity     validate.private.connectivity
enable.egress.private.connectivity
describe.egress.private.connectivity
update.egress.private.connectivity
validate.egress.private.connectivity
delete.egress.private.connectivity
get.egress.private.connectivity.account.id

HTTP Event Collector (HEC) tokens

CODE 
create.hec                      describe.hec
list.hecs                       patch.hec
update.hec                      delete.hec

Maintenance windows

CODE 
audit.maintenance.windows.schedule
describe.maintenance.windows.preferences
describe.maintenance.windows.schedule
list.available.windows.for.preference
list.maintenance.windows.schedules
update.maintenance.windows.preferences

Limits configuration

CODE 
add.limit.config                get.limit.config
get.all.limits.config           get.all.limits.config.defaults
reset.limit.config

Dynamic Data Self-Storage (DDSS)

CODE 
create.self.storage.location
describe.self.storage.location
list.self.storage.locations
get.self.storage.location.policy
get.self.storage.location.prefix
get.self.storage.location.service.accounts
get.self.storage.location.azure.consent.url
get.self.storage.location.azure.service.principal

Stack, deployment, and platform configuration

CODE 
describe.stack                  describe.stack.old
restart.stack                   restart.status
change.python.version           get.python.version
describe.deployment             list.deployment
retry.deployment                describe.managed.glue.resources
update.managed.glue.resources

Splunk Observability Cloud and Enterprise Managed Encryption Keys (EMEK)

CODE 
enable.rbac.on.o11y
get.observability.pairing.status
post.observability.capabilities.on.splunk
post.observability.pairing
describe.emek.waiver
get.emek.policy
put.emek.key

List action values on your stack

To list the action values present on your stack, run the following search:

CODE 
index=_audit sourcetype=audittrail
| spath input=info path=generated_by output=generated_by
| search generated_by="*:admin-config-service"
| stats count by action
| sort action