AWS Lambda's console now shows a one-click prompt to add a coding agent. That is convenient for a prototype and dangerous for a production account, because the agent inherits the caller's IAM context. This article turns that risk into a reproducible admission gate: a small set of checks you can run locally before the agent ever sees a real function.
What the integration changes
When you enable a coding agent from the Lambda console, the agent operates with the permissions of the authenticated user or role that launched it. If your developer console session includes lambda:UpdateFunctionCode and iam:PassRole, so does the agent. That is not a new Lambda vulnerability--it is the standard privilege model--but it removes the friction that previously made accidental deployments rare.
The admission gate
Run these four checks before granting the agent access to any non-throwaway function.
1. Inventory the caller's effective permissions
# List the effective managed policies attached to the caller role
aws iam list-attached-role-policies \
--role-name "$CALLER_ROLE_NAME" \
--output table
# List inline policies
aws iam list-role-policies \
--role-name "$CALLER_ROLE_NAME" \
--output table
Record every action that includes UpdateFunction*, Publish*, or PassRole. These are the write paths the agent can exercise without any additional approval.
2. Define a sandbox function and a production boundary
Create a throwaway function with its own execution role scoped to a single log group:
aws lambda create-function \
--function-name agent-sandbox-001 \
--runtime python3.12 \
--role arn:aws:iam::111122223333:role/AgentSandboxExecution \
--handler index.handler \
--zip-file fileb://sandbox.zip \
--environment Variables="{ENV=sandbox,ALLOWED_LOG_GROUP=/aws/lambda/agent-sandbox-001}"
Tag every production function the agent must not touch:
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-1:111122223333:function:payments-worker \
--tags AgentAccess=denied
3. Run a deny-first SCP or permission boundary
Attach a service control policy or permissions boundary that denies lambda:UpdateFunctionCode on any resource tagged AgentAccess=denied:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"lambda:UpdateFunctionCode",
"lambda:PublishLayerVersion",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/AgentAccess": "denied"
}
}
}
]
}
4. Verify the gate with a deliberate rejection
Attempt to update the production function from the agent's context:
# Expected: AccessDenied
aws lambda update-function-code \
--function-name payments-worker \
--zip-file fileb://test-payload.zip
If this succeeds, the boundary is misconfigured. Fix it before proceeding.
Telemetry you need before the first agent task
| Field | Why |
|---|---|
eventSource = lambda.amazonaws.com
|
Confirms the action targets Lambda, not a downstream service |
eventName = UpdateFunctionCode
|
The specific write the agent can perform |
userIdentity.sessionContext.sessionIssuer.arn |
The role the agent assumed |
requestParameters.functionName |
Which function was modified |
sourceIPAddress |
Agent infrastructure IP range for correlation |
Set a CloudWatch alarm on UpdateFunctionCode events where the function name does not match the agent-sandbox-* pattern. This catches drift if the agent later gains broader access.
Rollback path
Before the agent modifies any function, capture the current configuration:
aws lambda get-function-configuration \
--function-name "$FUNCTION_NAME" \
> "backup-$(date +%s).json"
Store the last known good code package. If the agent's change fails health checks, redeploy from backup:
aws lambda update-function-code \
--function-name "$FUNCTION_NAME" \
--zip-file fileb://last-known-good.zip
Limitations
- This gate protects against accidental production writes, not against a determined adversary with
iam:PassRolewho can create a new execution role. - Tag-based conditions rely on the tag remaining on the resource. Audit tag drift with Config rules.
- The sandbox function still incurs invocation charges. Delete it after the session.
What to check
Which UpdateFunction* action does your current console role include, and which of those should survive the deny boundary? If you cannot answer that in one sentence, the agent should not have access yet.
Top comments (0)