AWSDevTools is being built around AWS-native security patterns: short-lived access, secrets in AWS, environment-specific runtime roles, and customer-visible IAM boundaries.
No Long-Lived AWS Keys
AWSDevTools is designed around role assumption and short-lived credentials rather than permanent customer access keys.
Runs In Customer AWS Accounts
Tool execution is intended to happen against customer-owned AWS environments, not by copying infrastructure state into our platform.
Least-Privilege Role Model
Baseline and per-tool role patterns are meant to keep access narrow and tied to the exact action being performed.
Secrets Managed In AWS
Application secrets are loaded from AWS Secrets Manager and the backend runs with environment-specific runtime roles.
Runtime secrets are stored in AWS Secrets Manager in `us-east-2`.
Backend runtime permissions are isolated by environment.
Customer account access uses AWS STS role assumption.
Transactional email is intended to use AWS SES rather than third-party mail credentials embedded in the app.
Operational environments are separated across staging and production secrets and runtime roles.
You keep control of your AWS accounts and IAM trust decisions.
You can review exactly which role ARN and external ID are used.
You can revoke access by removing or editing the trust relationship in your AWS account.
You can limit permissions per tool instead of granting blanket admin access.
We want customers to feel comfortable because the security model is understandable and inspectable.
Today, that means AWS-native secrets handling, runtime roles, STS-based access patterns, and clear separation between staging and production. This page should evolve as the platform matures, but it should already make a serious buyer more comfortable with how AWSDevTools is being operated.