Creating new sops file fails with `creation_rules` and `key_groups`

In short: Cannot create new sops file when using configuration .sops.yml with multiple kms_groups configured, if user lacking permission to at least on of the kms_groups. On the other hand - already created sops file with the same list of KMS keys could be decrypted/encrypted without error.

Expected behaviour: Creating new sops file and editing existing sops file works in the same way - permissions to at least one of the KMS key is enough to decrypt/ecrypt.

SOPS: v3.11.0

TL;DR

I have following configuration in .sops.yml

---
creation_rules:
    - path_regex: .*/secrets/*
      key_groups:
          - kms:
                - arn: "arn:aws:kms:eu-central-1:123456789101:alias/sops-key"
                  role: "arn:aws:iam::123456789101:role/role1"
                - arn: "arn:aws:kms:eu-central-1:123456789101:alias/sops-key"
                  role: "arn:aws:iam::123456789101:role/role2"

I have permissions to assume both roles (role1, role2), but other person has permissions only to assume role2.

When I try to create a new file - it works perfectly fine:

$ sops secrets/ok.yml
test: test

secrets/ok.yml

test: ENC[AES256_GCM,data:3WDdPA==,iv:QfKCgdcCjUBzZGomqdn7s9ZhWqgxm8yqTohuIEC8WGE=,tag:jvTCI24HUH1BVpO4Dl91jQ==,type:str]
sops:
    kms:
        - arn: arn:aws:kms:eu-central-1:123456789101:alias/sops-key
          role: arn:aws:iam::123456789101:role/role1
          created_at: "2026-01-14T12:13:16Z"
          enc: AQICAHjJMh6hKQi9wz2gM8xaJRTT3gb7CPEk4M8iczAeceeN+AH1yotCoJkUQVtS8vkUwYieAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMgY/1rdpBQqzIGUVKAgEQgDv3XdNEgUvetfeJw+maSf/+ViDqlpj3p+p4Gb9PSXWbkjbuf0wOblLq7CfpWt7NWnN4pVTyOle8kBnRyw==
          aws_profile: ""
        - arn: arn:aws:kms:eu-central-1:123456789101:alias/sops-key
          role: arn:aws:iam::123456789101:role/role2
          created_at: "2026-01-14T12:13:16Z"
          enc: AQICAHjJMh6hKQi9wz2gM8xaJRTT3gb7CPEk4M8iczABceeN+AFeHM5udHhIgffj/FSfENTLAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMhVys+I2DXMAMmSyUAgEQgDsKvBeI5pj4n0UGcjdgJCatpUtAyWbtB9U8ZZ0q1IUVHPh344ZBP1qU1JJvJhnZ3GLLElRSoQ/31eJCFA==
          aws_profile: ""
    lastmodified: "2026-01-14T12:18:20Z"
    mac: ENC[AES256_GCM,data:OA+MDQPIyMvB4c1m/GZbbObd1bKbPAXNSnceJCN5sgkHWNY0R1IaAr/Pkdlx+JgwL9fXBaRMLH6RlkndT13Lkq/HyB/pblyfAPspUJWDgEDHmhX+hEIu0Ss8xWsZiRhEeB1BG73UWtnhp8GHQP/IkuMVgUz/S31zoWSdPjYhSC0=,iv:wedVY/TYaS7Efn656EHWGTsvHQTCXBdkCmfkW42hJ6g=,tag:wDkudc1O1BmGRYDoz0ytkg==,type:str]
    unencrypted_suffix: _unencrypted
    version: 3.11.0

And another person could decrypt/encrypt that file without problem.

But when that person tries to create a new file from scratch he gets an error:

$ sops secrets/error.yml
Error encrypting the data key with one or more master keys: [failed to encrypt new data key with master key "arn:aws:kms:eu-central-1:123456789101:alias/sops-key+arn:aws:iam::123456789101:role/role1": failed to assume role 'arn:aws:iam::123456789101:role/role1': operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: aac37ad1-0886-4925-a6b6-c6f347538f60, api error AccessDenied: User: arn:aws:sts::123456789101:assumed-role/login-role2/other-user@example.com is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789101:role/role1]

Start by reproducing the failure with the .sops.yml creation_rules and key_groups shown, using the sops secrets/error.yml entry point and contrasting it with editing secrets/ok.yml. Trace how new data keys are encrypted for AWS KMS roles versus how existing files are re-encrypted. Done means a user who can assume only one configured role can create and edit files without an unnecessary access failure.