A Credential-Setup Skill for New Projects

Every new AWS integration needs the same first decision made correctly: what can this code actually do, and where do its credentials come from.

Getting that right by hand, every time, is exactly the kind of repeatable task worth packaging as a skill. A credential-setup skill is a wrapper around two things this site already covers in depth - IAM least-privilege policies and the credential provider chain - that scaffolds a new project's role, policy, and local config consistently.

This is a development-practice skill, not an AWS-shipped feature. AWS gives you IAM and the SDK's credential chain; the skill is your team's packaged, repeatable way of using them the same way on every new integration.

Recipe

Package a fixed procedure - name the service and actions, generate a least-privilege policy, attach it to a role, and set up a local profile that resolves through the existing chain - so a new integration never starts from a wildcard policy or a hardcoded key.

---
name: credential-setup
description: Scaffold IAM role/policy and local credential config for a new AWS integration.
triggers:
  - "set up credentials for a new integration"
  - "add IAM access for <service>"
---
 
# Credential Setup
 
1. List the exact services and operations this integration needs
   (e.g. s3:GetObject, s3:PutObject - not s3:*).
2. Generate a least-privilege policy scoped to those actions and resource ARNs.
3. Attach the policy to a role appropriate to the runtime
   (EC2 instance role, ECS task role, Lambda execution role, or a local
   profile for development).
4. For local development, write a named profile - never raw keys in code
   or in a shared file.
5. Verify: run one read-only call using the new role/profile and confirm
   it succeeds, then confirm a call outside the granted actions fails.

The skill itself is language-neutral - it is an instructions document, so it stays a plain fence. The output it produces, in step 5, is what needs the dual-language treatment.

Working Example

Following the skill for a new integration that only needs to read from one S3 prefix produces a scoped policy, plus a verification call in both SDKs.

The policy (step 2 and 3 output):

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

The verification call (step 5 output), using the role or local profile the skill just set up:

# --- Python (boto3) ---
import boto3
 
# Uses the profile/role the skill just configured - no keys in code.
session = boto3.Session(profile_name="reports-reader")
s3 = session.client("s3", region_name="us-east-1")
 
resp = s3.list_objects_v2(Bucket="reports-bucket", Prefix="exports/", MaxKeys=1)
print("Access verified:", "Contents" in resp)

// --- TypeScript (AWS SDK v3) ---
import { S3Client, ListObjectsV2Command } from "@aws-sdk/client-s3";
import { fromIni } from "@aws-sdk/credential-providers";
 
// Uses the profile/role the skill just configured - no keys in code.
const s3 = new S3Client({
  region: "us-east-1",
  credentials: fromIni({ profile: "reports-reader" }),
});
 
const resp = await s3.send(new ListObjectsV2Command({
  Bucket: "reports-bucket",
  Prefix: "exports/",
  MaxKeys: 1,
}));
console.log("Access verified:", !!resp.Contents);

What this demonstrates:

• The skill's output is a policy document plus a runnable, minimal check - not just a role name in an issue tracker.
• Both SDKs resolve credentials through the same named profile, so the skill's step 4 output is portable across languages.
• The verification step (list a known prefix) proves the scope is both sufficient and not overbroad.
• Nothing about the underlying auth mechanics is new; the skill only fixes the order of operations and the level of scoping.

Deep Dive

Why This Is a Skill and Not Just a Reminder

Least-privilege scoping is easy to state and easy to skip under deadline pressure.

A skill turns "remember to scope this tightly" into a checkable procedure with a defined output: a policy file with specific actions and ARNs, not *. That is the entire value - it does not teach IAM, it enforces that IAM gets used correctly, every time, by making the procedure explicit enough for an assistant to follow without guessing.

What the Skill Defers To

The skill's instructions intentionally do not re-derive IAM policy mechanics or credential chain resolution order - both already have dedicated pages on this site.

Writing a least-privilege policy for a new integration and the credential provider chain end to end cover that ground. The skill references them as background and focuses only on the repeatable sequence: enumerate actions, generate the policy, attach the right role type, set up local config, verify.

Runtime-Specific Role Attachment

Step 3 branches by where the code actually runs, and this is the part teams most often get inconsistent without a written procedure.

An EC2 instance role, an ECS task role, and a Lambda execution role are each attached differently, but the skill's job is to make sure whichever one applies gets attached the same way every time - not to reinvent any of those attachment mechanics.

Keeping the Skill Current

If your team's baseline policy template changes, or you adopt a new pattern like scoped session tags, this skill's step 2 needs updating.

An out-of-date credential-setup skill that still generates a template missing a now-required condition key is a quiet source of failed calls or over-broad grants. Review it whenever the underlying IAM or credential conventions change.

Gotchas

• Copy-pasting a wildcard "to unblock now." - defeats the entire point of the skill. Fix: always enumerate the exact actions and ARNs before attaching anything.
• Skipping the verification step. - a policy that looks right on paper may still be missing an action. Fix: always run the read-only smoke test and a deliberate access-denied test.
• Local profile committed to a shared file. - defeats "never keys in code." Fix: keep named profiles in the standard local config location, never in the repo.
• Forgetting Lambda cold-start scoping. - an execution role scoped for local dev use does not match a Lambda's actual resource footprint. Fix: scope per runtime, not once for all environments.
• Skill goes stale after a policy template change. - see Deep Dive. Fix: version and review the skill alongside your IAM conventions.

Alternatives

FAQs

Related

• Writing a Least-Privilege Policy for a New SDK Integration - the IAM mechanics this skill wraps.
• The Credential Provider Chain, End to End - how the resolved profile actually gets found.
• A Service-Client Scaffolding Skill - the natural next skill once credentials are set up.
• Agent Skills Best Practices - keeping this skill narrow and current.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).