DEV Community

Odd_Background_328
Odd_Background_328

Posted on

Before Letting a Coding Agent Touch AWS Lambda, Run This Admission Gate

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
Enter fullscreen mode Exit fullscreen mode

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}"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Limitations

  • This gate protects against accidental production writes, not against a determined adversary with iam:PassRole who 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)