IAM Policy Generator for TypeScript & JavaScript

How to generate an IAM policy from TypeScript code

To generate an IAM policy from TypeScript or JavaScript, paste the code that calls the AWS SDK into the editor above and press Generate IAM policy. Each SDK command, such as GetObjectCommand, becomes an IAM action like s3:GetObject, grouped into statements by resource. Replace any wildcards with real ARNs, then validate the policy before you attach it.

1. Paste the code that calls AWSAdd the file with your SDK clients and every function that sends a command, using Paste, Open file (.ts, .tsx, .js, .mjs, .cjs, .jsx or .txt, up to 500 KB) or drag and drop. Sample loads an order processor that uses S3, DynamoDB and SQS.
2. Let the secret check runBefore anything is sent, the page scans for AWS access keys, secret keys, private keys and common API tokens, and shows you where they are so you can swap in placeholders.
3. Generate the policyClick Generate IAM policy or press Ctrl + Enter. The policy JSON streams into the right-hand editor; stop it at any time.
4. Compare it with your codeCheck that every send() call has a matching action. Calls whose target comes from process.env are the ones most likely to end up as a wildcard or be left out.
5. Tighten, validate and attachReplace wildcards with real ARNs, run it through IAM Access Analyzer policy validation, then Download it as policy.json and attach it to the role your code runs as.

Why generate an IAM policy from your code

Writing a policy by hand means reading every file, finding each SDK call and looking up the matching action. Most teams skip that and attach AmazonS3FullAccess or "Action": "s3:*" to get unblocked, which is how Lambda functions end up able to delete buckets they only ever read from. Starting from the calls your code actually makes gets you much closer to least privilege.

It helps most when you're creating the execution role for a new Lambda function or ECS task, reviewing a pull request that adds new SDK calls, or replacing a broad policy on an older Node.js service. Because it reads the source rather than your account, you can run it before anything is deployed.

It has limits. The generator only sees the code you paste, not your AWS account, so values that come from environment variables, the account ID and region, and calls made inside other libraries aren't visible. In one of our test runs with the sample, the SQS call whose queue URL came from process.env was left out of the draft entirely. That's why every step on this page ends with review.

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.

If your code still uses SDK v2 (s3.getObject().promise()), the actions are the same, since both versions call the same API operations. When you're ready to move off v2, the AWS SDK v2 to v3 converter rewrites the calls, and you can run this generator on the result to confirm nothing changed.

AWS SDK v3 commands and the IAM actions they need

A quick reference for the commands Node.js services use most. The resource column shows which ARN the permission applies to.

Key features

• Reads SDK v3 and v2 codeCommands sent with client.send() and v2 calls like s3.putObject().promise() both map to the same IAM actions.
• Statements grouped by resourceActions on the same bucket, table or queue land in one statement, so the policy is short enough to review.
• Uses the names in your codeLiteral bucket and table names, and key prefixes in template strings, go straight into the ARNs, such as acme-invoices/pending/*.
• Wildcards only where it can't knowRegion, account ID and values read at runtime become *, which makes the parts you need to fill in easy to spot.
• No guessed extrasJSON can't hold comments, so anything the model can't infer from the code is left out rather than invented. Compare the draft with your calls.
• Ready-to-save policy.jsonCopy the policy or download it as policy.json to paste into the IAM console, CDK or Terraform.
• Secret check before sendingAccess keys, private keys and API tokens are detected in your browser before any code leaves it.

Examples: TypeScript code and the IAM policy it needs

Three common patterns and a correct least-privilege policy for each. Choose Try this example to load the code into the generator and compare its draft with the policy shown here.

import { S3Client, ListObjectsV2Command, GetObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({});
const Bucket = "acme-uploads";

export async function readUserFiles(userId: string) {
  const list = await s3.send(new ListObjectsV2Command({ Bucket, Prefix: `users/${userId}/` }));

  const files: string[] = [];
  for (const obj of list.Contents ?? []) {
    const res = await s3.send(new GetObjectCommand({ Bucket, Key: obj.Key! }));
    files.push(await res.Body!.transformToString());
  }
  return files;
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acme-uploads"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::acme-uploads/users/*"
    }
  ]
}

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand, PutCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

export async function ordersForCustomer(customerId: string) {
  const { Items } = await ddb.send(new QueryCommand({
    TableName: "orders",
    IndexName: "byCustomer",
    KeyConditionExpression: "customerId = :c",
    ExpressionAttributeValues: { ":c": customerId },
  }));
  return Items ?? [];
}

export async function saveOrder(order: Record<string, unknown>) {
  await ddb.send(new PutCommand({ TableName: "orders", Item: order }));
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:Query",
      "Resource": "arn:aws:dynamodb:*:*:table/orders/index/byCustomer"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:PutItem",
      "Resource": "arn:aws:dynamodb:*:*:table/orders"
    }
  ]
}

import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";
import { SNSClient, PublishCommand } from "@aws-sdk/client-sns";

const secrets = new SecretsManagerClient({});
const sns = new SNSClient({});
const TOPIC_ARN = "arn:aws:sns:us-east-1:123456789012:order-events";

export async function chargeAndNotify(orderId: string) {
  const { SecretString } = await secrets.send(
    new GetSecretValueCommand({ SecretId: "payments/stripe-api-key" })
  );
  // ...charge the card with SecretString...
  await sns.send(new PublishCommand({ TopicArn: TOPIC_ARN, Message: JSON.stringify({ orderId }) }));
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:*:*:secret:payments/stripe-api-key-*"
    },
    {
      "Effect": "Allow",
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:order-events"
    }
  ]
}

Tips for better results

• Paste the code that makes the AWS calls. Include the client setup and every function that sends a command. A wrapper module you import but don't paste is invisible to the generator.
• Keep literal names in the code you paste. When a bucket or table name is a constant, the generator can put it straight into the ARN. If yours come from process.env, paste a line showing the real value to get exact ARNs.
• Keep bucket and object permissions apart. s3:ListBucket goes on arn:aws:s3:::bucket; s3:GetObject and s3:PutObject go on arn:aws:s3:::bucket/*.
• Test before you rely on it. Check specific calls with the IAM policy simulator, then run the code with the policy attached and watch for AccessDenied errors.
• Cross-check with real activity. Once the service has run in a test account, IAM Access Analyzer policy generation builds a policy from its CloudTrail events, a useful second opinion on what this page produced.

Common mistakes to avoid

• Using a queue URL as the resource. SQS permissions take the queue ARN (arn:aws:sqs:us-east-1:123456789012:orders), not the https://sqs... URL your code passes.
• Granting the table but not the index. QueryCommand with an IndexName needs dynamodb:Query on table/NAME/index/INDEX as well.
• Putting s3:ListBucket on bucket/*. It has no effect there. List permissions apply to the bucket ARN only.
• Forgetting permissions the code doesn't show. SSE-KMS reads need kms:Decrypt, writes need kms:GenerateDataKey, and handing a role to Lambda or ECS needs iam:PassRole.
• Attaching the draft without comparing it to the code. Count your send() calls and check each one has an action. Calls built from runtime values are the easiest to miss.
• Leaving * in production ARNs. Region and account wildcards are fine in a draft but should be replaced before the policy protects anything real.

Frequently asked questions

Related tools and next steps

• AWS SDK v2 to v3 converterMove old aws-sdk code to modular v3 clients before you write the final policy.
• IAM policy from Python (boto3)Generate a policy for the Python scripts and Lambda functions in the same project.
• IAM policy from GoThe same approach for services written with the AWS SDK for Go v2.
• Terraform to CDK TypeScriptDefine the role and policy in CDK alongside the rest of your TypeScript stack.
• ChatWithCloud securityHow ChatWithCloud handles credentials and data when it talks to your AWS account.
• All AWS code toolsSDK converters, infrastructure-as-code converters and IAM policy generators.