Quick answer
The Amazon Cognito aws-auth skill is a core skill in the Agent Toolkit for AWS. It helps a compatible coding agent reason through and operate Cognito workflows: user pools and app clients, managed login, OAuth 2.0, tokens, passkeys, threat protection, Lambda triggers, identity pools, and API authorizers.
Treat it as a reviewed operator, not as an authorization shortcut. Start by naming the application, users, client type, redirect URLs, protected resources, AWS Region, and required sign-in methods. Ask the agent to inventory current state and produce a change plan. Execute only after reviewing IAM scope, destructive replacement behavior, token boundaries, tests, and rollback.
What changed in August 2026
AWS announced aws-auth as an Agent Toolkit core skill in August 2026. The official skill can be paired with the AWS MCP Server, where calls use IAM-based guardrails and AWS documents CloudTrail audit logging, or used with the AWS CLI.
The skill is guidance plus operational context. It does not grant AWS permissions, create an approval process, or prove that a generated configuration meets your threat model.
Install the Agent Toolkit path
AWS documents several host-specific installation paths. The current quick start includes an aws-core plugin for supported agents, direct MCP configuration for other MCP-capable clients, and an interactive aws configure agent-toolkit path for supported AWS CLI versions.
After installation:
- Start a fresh agent session so newly installed skills and tools are discoverable.
- Verify the AWS documentation connection before allowing write operations.
- Confirm the active AWS account, Region, role, and credential source.
- Ask the agent to explain which parts of the request belong to
aws-authand which belong to IAM, serverless infrastructure, or application code.
Do not copy a version-sensitive install command from a stale article into an automated bootstrap. Use the live Agent Toolkit quick start for current commands and prerequisites.
Use a plan-review-execute-verify workflow
1. Define the authentication contract
Write down the user population, client type, sign-up policy, identity providers, callback and sign-out URLs, session expectations, MFA or passkey requirements, protected APIs, and whether the client needs direct access to AWS services.
This immediately resolves the most common architecture fork: most apps need a user pool; an identity pool is additional infrastructure for clients that need temporary AWS credentials.
2. Inventory before changing
Ask for a read-only inventory of the relevant user pool, app clients, domains, resource servers and scopes, Lambda triggers, threat-protection settings, identity pool, and authorizers. Preserve the returned identifiers and current settings in the change review.
This matters because some AWS CLI update operations are full replacements. An apparently narrow app-client or identity-role update can reset omitted values. Require read-modify-write behavior and a field-level diff.
3. Review the proposed boundary
Check these separately:
- Authentication: how a user or workload proves identity.
- Tokens: which ID, access, and refresh tokens are issued and where they are stored.
- Application authorization: which API scopes, claims, groups, and backend rules allow an action.
- AWS authorization: which temporary or operator credentials can call AWS services.
- Agent authority: which reads and writes the coding agent may perform during this task.
Passing sign-in does not prove API authorization. A valid Cognito token does not grant arbitrary AWS access. Agent access to a signed-in terminal does not authorize an unrestricted production change.
4. Execute with a narrow role
Apply one reviewed boundary at a time: user pool and app client, managed login and redirects, token configuration, an identity pool if required, then authorizers and application enforcement. Keep human confirmation for account-wide, production, role-mapping, domain, trigger, or session-invalidating changes.
5. Verify both allowed and denied paths
Test a new user, an existing user, sign-out, expiry, refresh, revocation, wrong audience, wrong issuer, missing scope, denied role mapping, and a second tenant or user. Inspect CloudTrail and service logs for the expected control-plane events, but do not treat log presence as proof that application authorization is correct.
Scope boundaries the prompt should state
| Work item | aws-auth scope | Separate owner or review |
|---|---|---|
| User pool, app client, managed login, OAuth | In scope | Application redirect and session implementation |
| Passkey and threat-protection configuration | In scope | Product recovery design and feature-plan verification |
| Identity pool connection | In scope | Least-privilege IAM roles and trust policies |
| API authorizer configuration | Authorizer boundary | API routes, integrations, backend business rules |
| Cognito Lambda trigger wiring | Trigger purpose and connection | Lambda implementation, data handling, deployment |
Amplify Gen 2 defineAuth backend | Not covered | Amplify backend workflow |
A safer starter prompt
Inventory the current Cognito configuration for this application without changing it. Separate user-pool, identity-pool, API-authorizer, IAM, and application-code responsibilities. Propose the smallest change set, show full-replacement operations and preserved fields, list exact account/Region/resource scope, and include allowed, denied, rollback, token, redirect, and audit checks. Wait for approval before writes.
Use the Cognito auth workflow planner to adapt that contract to your client and resource path. For the two architecture decisions that cause the most rework, continue with OAuth, PKCE, and passkeys and user pools versus identity pools.
Frequently asked questions
What is the AWS aws-auth skill?
aws-auth is an Amazon Cognito core skill in the Agent Toolkit for AWS. It gives compatible AI coding agents workflows for user pools, app clients, managed login and OAuth, tokens, passkeys, threat protection, Lambda triggers, identity pools, and API authorizers.
Does the aws-auth skill require the AWS MCP Server?
No. AWS says the skill can work with the AWS MCP Server or with the AWS CLI. The MCP path adds IAM-based guardrails and CloudTrail-audited API activity, but neither path replaces a least-privilege permission review.
Can the skill finish an application’s entire authorization design?
No. It covers Cognito and the authorizer boundary. IAM role design, Amplify Gen 2 backend definitions, API Gateway routes and integrations, and application-specific authorization logic remain separate work.
Should an agent apply Cognito changes immediately?
Use a plan-first workflow for consequential changes. Inventory current state, review the exact change set and rollback, then execute with scoped credentials and verify allowed and denied cases.
Official sources
- AWS launch: Amazon Cognito as an Agent Toolkit skill
- Agent Toolkit for AWS quick start
- AWS-owned
aws-authskill source - Amazon Cognito developer guide
Source check: August 9, 2026. Verify current installation commands, supported clients, Regions, feature plans, APIs, limits, prices, and IAM actions before production use.