Lambda SourceFunctionArn: tie a permission to one function

The lambda:SourceFunctionArn condition key lets an IAM policy allow an action only when the call came from code running in one named Lambda function. It helps when functions share a role, and it helps trace where leaked credentials were used. It works in identity policies and service control policies, not in resource policies.

The problem it solves

A Lambda function calls other AWS services with temporary credentials from its execution role. Those credentials are exposed to the function as environment variables. If two functions share a role, nothing in a plain policy distinguishes their calls. And if the credentials leak, a policy cannot tell whether a call came from the function or from an attacker's machine.

Lambda injects the source function ARN into the credentials context when the AWS API request comes from within the execution environment. The condition key lets you test for it.

How to use it

Add it as a condition with an ARN condition operator, and make the value a valid ARN. AWS gives an example: allow s3:PutObject on a specific bucket only when the source is a named function. The policy does not allow that action to any other calling identity, even a different function using the same execution role.

You can also use it in a service control policy. AWS shows one that denies S3 actions on a bucket unless the call comes from a given function or from a specified VPC, using the IfExists variants of the operators so each condition applies only when its key is present.

What it can tell you after a leak

If credentials are copied out of a function and used elsewhere, a call made from somewhere else would not be coming from inside the execution environment, so it should lack the source function ARN. A policy that requires it should make those calls fail, which you should test. That turns a leaked credential from usable anywhere into usable only inside that function, for the actions you guarded.

Limits to remember

1. Unqualified ARN only. The key does not support function versions or aliases. If you put a version or alias ARN in the condition, the function will not have permission. Use the plain function ARN.
2. Not for resource policies. AWS says you cannot use it in resource based policies.
3. Not injected everywhere. Lambda adds it for calls made from inside the environment and for some calls on your behalf: CloudWatch Logs, X-Ray and EFS mounts. It is not present on other calls Lambda makes outside the environment, such as KMS calls that decrypt environment variables, EC2 calls that create network interfaces, or reading from an event source like a queue.
4. Different from similar keys. lambda:FunctionArn applies to event source mappings, and aws:SourceArn applies where your function is the target resource. Mixing them up gives policies that look right and do nothing.

Because of point 3, do not add a blanket deny that requires the key on every action of the role. You may break log delivery or queue reads. Scope the condition to the specific actions you want to guard.

A rollout plan

1. Pick the highest value data store the function touches.
2. Add an allow statement with the condition on the actions that matter.
3. Remove broader statements for the same resource.
4. Test with the function and with a call made from outside, and confirm the second is denied.
5. Check the logs for unexpected denials before widening the pattern.

Quick check

Sources

• Using source function ARN to control function access behavior, AWS documentation

Last reviewed: 19 October 2026.