Least Privilege for Service Accounts, Not Just Humans

A service account created to deploy one Lambda function often ends up with broad, unreviewed permissions because it's easier to attach an existing managed policy than to scope a new one, and because service accounts don't show up in the access reviews that focus on offboarding humans. This matters more than an over-privileged human account in one specific way: a compromised service account credential (leaked in a log, committed to a repo, exfiltrated from a compromised dependency) can be used programmatically, at scale, without needing to bypass MFA or session policies the way a human account often would. Start by inventorying what each service account actually calls in practice — cloud providers' access-analyzer tools can generate a policy from observed audit-log activity over a real usage window — rather than trying to hand-derive minimal permissions from documentation. Rotate credentials on a schedule independent of whether you suspect compromise, and prefer short-lived credentials (workload identity federation, assumed roles) over long-lived static keys wherever the platform supports it, since a leaked short-lived credential has a bounded window of usefulness even if the leak isn't detected immediately.