Redact sensitive values in built in validation error

[capoccias]

Describe the bug At the moment, using Ash.Resource.Validation.Builtins.confirm includes the comparison value in value when returning an error It does this even if the attribute is set as sensitive: true

To Reproduce A minimal set of resource definitions and calls that can reproduce the bug.

defmodule MyApp.MyResource do
  use Ash.Resource,
    otp_app: :my_app,
    data_layer: AshPostgres.DataLayer

actions do
update :confirm_phone_number do
      require_atomic? true

      argument :input_phone_number_confirmation_code, :string, allow_nil?: false, sensitive?: true

      validate confirm(:input_phone_number_confirmation_code, :phone_number_confirmation_code)
end
end

  attributes do
    attribute :phone_number_confirmation_code, :string do
      allow_nil? true
      sensitive? true
    end
end

Will get a changeset like:

    arguments: %{phone_number_confirmation_code: "incorrect"},
    errors: [
      %Ash.Error.Changes.InvalidAttribute{
        field: :phone_number_confirmation_code,
        message: "confirmation did not match value",
        private_vars: nil,
        value: "correct",
        splode: nil,
        bread_crumbs: [],
        vars: [],
        path: [],
        stacktrace: #Splode.Stacktrace<>,
        class: :invalid
      }
    ],

Expected behavior Something like:

    arguments: %{phone_number_confirmation_code: "incorrect"},
    errors: [
      %Ash.Error.Changes.InvalidAttribute{
        field: :phone_number_confirmation_code,
        message: "confirmation did not match value",
        private_vars: nil,
        value: "REDACTED",
        splode: nil,
        bread_crumbs: [],
        vars: [],
        path: [],
        stacktrace: #Splode.Stacktrace<>,
        class: :invalid
      }
    ],

Runtime

• Elixir version: 18.2
• Erlang version: 27.3
• OS: Ubuntu
• Ash version: 3.4.68
• any related extension versions

Additional context Add any other context about the problem here.

[zachdaniel]

This one is a bit complex, as right now validations are in control of setting their own values, and ultimately the only solution is to just add branching logic inside all of the validations to have them not put in a value (or use **redacted**) if the field they are validating is sensitive. We should definitely do it, but its not something we can just apply a cross cutting fix to.