How to generate an IAM policy from TypeScript code
- Add your codePaste it into the TypeScript / JavaScript editor, drag in a file, or keep the sample to see how it works.
- Generate IAM policyClick the button or press Ctrl + Enter. The result streams into the right-hand editor.
- Review and use itCopy or download the result, then test it before you rely on it. AI output is a strong first draft, not a guarantee.
How AWS SDK calls become IAM actions
Most AWS SDK for JavaScript commands map directly to an IAM action: the service prefix plus the operation name. GetObjectCommand needs s3:GetObject, QueryCommand on DynamoDB needs dynamodb:Query, and SendMessageCommand needs sqs:SendMessage. The generator reads the commands and client calls in your code and groups them into policy statements by service and resource.
There are exceptions worth knowing. Listing objects with ListObjectsV2Command needs s3:ListBucket on the bucket ARN, not on the object ARN. Reading an object encrypted with a customer-managed KMS key also needs kms:Decrypt, and passing a role to another service needs iam:PassRole. The Service Authorization Reference lists the exact actions, resource types and condition keys for every service.
Values the code only knows at runtime, like the queue URL read from process.env in the sample, can't be resolved from the source, so they show up as wildcards. Treat the output as a least-privilege draft: fill in real ARNs and check it with IAM Access Analyzer policy validation. To build a policy from what a role actually did, IAM Access Analyzer policy generation works from CloudTrail activity and complements this code-based approach.
The DynamoDB Document Client (@aws-sdk/lib-dynamodb) needs the same IAM actions as the low-level client. QueryCommand still needs dynamodb:Query, and querying a secondary index needs it on the index ARN too (table/orders/index/*).
Tips for better results
- Paste the code that makes the AWS calls. Include the client setup and every function that calls the SDK, so no action is missed.
- Tighten resources after generating. Replace wildcards with the exact bucket, table or queue ARNs, and keep bucket-level and object-level S3 permissions in separate statements.
- Validate before attaching. Run the policy through IAM Access Analyzer policy validation to catch syntax errors, overly broad statements and mismatched resource types.
- Check indirect permissions. Encrypted resources need KMS actions, and handing a role to Lambda or ECS needs
iam:PassRole. Add these by hand if your setup uses them. - Use literal resource names where you can. When bucket or table names appear as constants in the code, the generator can put them straight into the ARNs instead of wildcards.
Frequently asked questions
Is the generated IAM policy least-privilege?
It's a least-privilege starting point: it lists only the actions your code calls. Because the tool can't see runtime values, resource paths use wildcards. Replace them with specific ARNs where you can, add conditions, and validate the result with IAM Access Analyzer before you attach it.
Why does the policy use wildcards in resource ARNs?
The generator reads your code, not your AWS account. Bucket names, table names and queue URLs that come from environment variables, configuration or function arguments aren't known, so they appear as wildcards such as arn:aws:s3:::*/*. Swap in the real names before deploying.
Does it catch every permission my code needs?
Not always. It infers actions from the SDK calls it can see. Permissions triggered indirectly, such as kms:Decrypt for encrypted objects, iam:PassRole when you hand a role to another service, or calls made inside other libraries, may be missing. Test with the policy attached and check CloudTrail for AccessDenied errors.
Does it work with AWS SDK v2 code too?
Yes. It reads JavaScript and TypeScript written for either SDK version, whether you call s3.getObject().promise() in v2 or s3.send(new GetObjectCommand()) in v3. The IAM actions are the same in both.