Management operations may include sensitive data. If management audit logging is enabled, this data will be written in the audit log. Consider adding a mechanism for this data to be filtered.

Note that the audit log is meant to be usable by auditors, and the basic function of an auditor is to be able to review everything. So it is easy for this kind of thing to go in a wrong direction. For example, treating the audit log as if it should be readable by someone in the RBAC Operator role would be a wrong direction.

Some possibilities:

1) Allow configuration, via class-name and module configuration attributes, of a Function<ModelNode, ModelNode> that can be used as a filter.

A pro of this is users can decide what they want to filter. This makes it flexible.
A con is it's not very user friendly. Users need to decide what they want filtered, implement the logic, provision a module, and add it to the config.
A con is it becomes part of the task of the auditor to understand and control what the function does.
A con is it would likely require defensive cloning of operation ModelNodes.
A con is the filter may result in logged data that does not conform to the management API. The audit log is typically in JSON format, so it's not out of the question that machines are processing the output.

2) Similarly it could be Function<ModelNode, Set<String>> where the return value is the set of operation parameters to replace with placeholder text like 'redacted'. Fields like 'operation' and 'address' would not be redactable.

This approach somewhat reduces the 'becomes part of the task of the auditor to understand and control what the function does' con by avoiding changing of operation addresses and names and ensuring that the names of all parameters that were in the original op is recorded, along with the fact that values were redacted.

3) We could define a new interface and allow configuration of an impl via OperationDefinition. If one is configured call it to find out what should be redacted. Perhaps limit what's allowed to items where a string is the expected value. (IOW the use case for redaction is not to hide things like true, false, 100, 23, etc; it's to hide things like passwords.

A new boolean config attribute to enable/disable use of that kind of filtering would be added.

That puts the onus of deciding what parameters can be redacted on the WildFly authors. That can be a good thing, or a bad one, depending on how many opinions there are around what should be redacted and how much effort it is to decide.

IMO, if a value ends up in the config file there's no good case for redacting it from the log. So, it's possible the only good use would be for the parameter discussed in https://groups.google.com/g/wildfly/c/B3QIdA0Jv18, where a management op stores a secret in a location not in the config file.