QUESTION

I noticed that the AWS user account Panther uses to assume roles for enrichments (Lookup Tables) looks different from the one used for log sources. Is this expected, and does it affect how I need to configure IAM permissions for my S3-backed enrichment?

ANSWER

Yes, this is expected and by design. Panther follows the principle of least privilege, meaning each service uses its own dedicated, scoped IAM role. Specifically:

• Log sources use the PantherLogProcessingRole-* role to assume access in your AWS account.

• Enrichments (Lookup Tables) use the PantherLUTsRole-* role when refreshing data from an S3 source.

So if you've configured an S3-backed enrichment with an IAM Role ARN, the role in your AWS account must explicitly trust the Panther enrichment identity — not the log processing one. These are two separate principals, and a trust policy that allows one will not automatically allow the other.

If you're seeing an AccessDenied error when Panther tries to assume the enrichment role, the most common cause is a missing or incorrect trust policy on the target role. For guidance on setting up the IAM role correctly, including the required permissions policy and trust configuration, see Panther's Custom Enrichments documentation — specifically the "Sync custom enrichment data from an S3 bucket" and "Creating an IAM role" sections.