Autonoma — AWS resources and IAM permissions deployed in your account

Buyer-facing disclosure for the Autonoma AWS Marketplace listings (BUILD, OPERATE, SECURE, PLATFORM), which deploy a data plane into your own AWS account via AWS Marketplace Quick Launch.

This file is generated by scripts/marketplace/generate-resource-disclosure.py from the CloudFormation templates that are actually published. Do not edit it by hand — edit the generator.

1. AWS services and resources provisioned

Every resource below is created inside your AWS account, in the single AWS Region you launch the stack in, by a CloudFormation stack you own. Autonoma has no credentials in your account and cannot access these resources — see §2 and §7.

Counts are per product listing; you deploy one product.

2. IAM roles created, and how they are used

The stack creates seven IAM roles. All seven are assumed only by AWS services (ecs-tasks.amazonaws.com, lambda.amazonaws.com) inside your account. No role trusts an Autonoma AWS account, and no role can be assumed by a principal outside your account. No IAM users and no long-lived access keys are created.

Role names are prefixed with the deployment identifier you choose at launch (CustomerId), so they never collide with your existing roles.

(this stack's RoleNamePrefix)(this stack's CustomerId)-alb-logs-fn

• Trusted principal: lambda.amazonaws.com
• AWS managed policies: AWSLambdaBasicExecutionRole

(this stack's RoleNamePrefix)(this stack's CustomerId)-dbinit-fn

Execution role for the one-shot database-initialisation Lambda, which runs the schema bootstrap as an ECS task. Scoped to running that single task definition in this stack's cluster.

• Trusted principal: lambda.amazonaws.com
• AWS managed policies: AWSLambdaBasicExecutionRole

(this stack's RoleNamePrefix)(this stack's CustomerId)-ecs-execution

ECS task execution role. Used by the Fargate agent (not by our code) to pull container images and to resolve the secrets block of each task definition at container start. Its only inline grant is secretsmanager:GetSecretValue, enumerated to the exact secret ARNs this stack creates.

• Trusted principal: ecs-tasks.amazonaws.com
• AWS managed policies: AmazonECSTaskExecutionRolePolicy

(this stack's RoleNamePrefix)(this stack's CustomerId)-quota-check-fn

• Trusted principal: lambda.amazonaws.com
• AWS managed policies: AWSLambdaBasicExecutionRole

(this stack's RoleNamePrefix)(this stack's CustomerId)-register-fn

Execution role for the registration Lambda, which calls the Autonoma control plane once at stack creation and stores the returned forwarding secret. Its only grant is read/write of that one secret.

• Trusted principal: lambda.amazonaws.com
• AWS managed policies: AWSLambdaBasicExecutionRole

(this stack's RoleNamePrefix)(this stack's CustomerId)-ecs-task

ECS task role — the identity Autonoma's own containers run as. Grants EFS access to the single file system this stack creates, read of the forwarding secret, and OpenTelemetry export to the two log groups this stack creates plus AWS X-Ray.

• Trusted principal: ecs-tasks.amazonaws.com

(this stack's RoleNamePrefix)(this stack's CustomerId)-ecs-task-test-runner

• Trusted principal: ecs-tasks.amazonaws.com

A Deny row is a restriction, not a permission. Denies on Resource: "*" are deliberately the broadest possible scope — this role runs third-party code and is blocked from reaching credentials or identity APIs anywhere in your account.

The other product listings (BUILD, OPERATE, PLATFORM) create the same seven roles. Two things differ, both because each product runs a different set of agents: the number of secrets the execution role reads, and securityhub:BatchImportFindings, which is granted only on SECURE and PLATFORM because only those two deploy the security agent that imports findings. BUILD and OPERATE do not carry that permission.

3. Every Resource: "*" grant, and why

Autonoma's deployed roles contain no service:* action wildcards. Four actions are granted at Resource: "*", in each case because AWS does not support resource-level permissions for them:

There are no other unscoped grants. Every other statement names the exact ARNs the stack itself creates.

4. Network exposure

• The stack creates its own dedicated VPC. It does not peer with, modify, or attach to any existing VPC in your account.
• Compute runs in private subnets with no public IP addresses. Outbound internet access is via a NAT gateway the stack creates.
• An internet-facing Application Load Balancer is the only ingress. It is reached by your developers' IDE/CLI clients, which authenticate with short-lived RS256 tokens verified against the Autonoma control plane's public JWKS endpoint, and — if you enable the GitHub integration — by the control plane's webhook relay described in §7.
• The load balancer is HTTPS-only. Port 443 uses TLS 1.3 (ELBSecurityPolicy-TLS13-1-2-2021-06); port 80 exists solely to issue a 301 redirect to 443. There is no plaintext path. You supply the certificate (AcmCertificateArn) and the hostname it covers (PublicHostname); the certificate lives in your ACM, in your account and Region, and Autonoma never holds it.
• You choose who can reach the load balancer. AllowedIngressCidr is a required parameter with no default — set it to a single address, your office or VPN range, or 0.0.0.0/0. If you narrow it, the range must still include 107.20.163.23/32, the address Autonoma delivers GitHub webhook events from, or that delivery stops.
• ALB access logs are enabled by default (EnableAccessLogs) and written to an S3 bucket the stack creates in your account, with a 90-day lifecycle rule. The bucket is retained if you delete the stack. AWS WAF is available (EnableWaf) and is off by default, because it adds AWS WAF charges to your bill.
• The database (RDS), cache (ElastiCache) and file system (EFS) are private to the VPC and are not internet-reachable.

5. Data handling

• Your source code and scan results stay in your account. They are written to the RDS instance and EFS file system this stack creates.
• Infrastructure credentials (database password, inter-service secrets) are generated inside your account by CloudFormation (GenerateSecretString) and stored in AWS Secrets Manager. They are never transmitted to Autonoma.
• Encryption in transit to the load balancer is mandatory, not default — see §4. Between services inside the VPC, and at rest, the AWS service defaults for each resource type apply.
• What Autonoma can and cannot see is its own section — see §6.

6. What Autonoma can see

Three things travel from your deployment to Autonoma. Nothing else does.

Two of the three are on unless you turn them off. That is an opt-out arrangement, and this document calls it that. There is no single master switch: the three flows are controlled in three different places, because they are different kinds of data with different consequences, and one control would mean either over-blocking the billing signal or under-disclosing the prompt text.

Deployment health carries no source code, no prompts, no scan results and no application data. It is deployment metadata: which build is running and whether it is healthy. We ask for it because the data plane runs in your account — we cannot force an upgrade, so knowing which builds are in the field is how a fix reaches the deployments that need it.

Your traces and logs stay with you. OpenTelemetry traces go to AWS X-Ray and logs to CloudWatch Logs, both in your own account. They are not forwarded to Autonoma.

On prompts, plainly. Model calls are routed through the Autonoma proxy so usage can be metered and so model access matches the tier you bought. Routing is not the same as keeping — but we do keep them: prompts and completions are stored and used to improve the models unless you turn model training off. If your prompts routinely contain material you cannot share, turn it off before you start, not after.

Turning it off applies to what we already hold. Collection stops immediately, and your existing datapoints are excluded from every future training run — consent is re-read each time a run selects its data, rather than trusted from when the data was captured. A model already trained cannot be untrained; that is why the switch is worth setting before the first run rather than after.

What never crosses at all: your repositories, your databases, your scan results and your traces and logs. They stay in the RDS instance, EFS file system, X-Ray and CloudWatch Logs this stack creates in your own account, whatever these three settings say — see §5.

7. Connections between your deployment and Autonoma

Outbound — your data plane calls the Autonoma control plane over public TLS:

Inbound — the Autonoma control plane calls your data plane in exactly one case:

That relay is opt-in: it happens only for deployments with an enabled GitHub integration, and only to the callback URL your own stack supplied at registration. Each request carries an X-Autonoma-Signature-256 HMAC-SHA256 header computed with the per-deployment forwarding secret, so your data plane can verify the request genuinely originated from the Autonoma control plane and reject anything else. Autonoma holds no AWS credentials for your account and cannot reach any resource other than that one HTTPS endpoint.

8. Deployment-time permissions

The permissions an administrator needs once to create the stack are published here: https://autonoma-quicklaunch-templates-808773666646.s3.us-east-1.amazonaws.com/docs/autonoma-quicklaunch-buyer-iam-policy.json

That file is the exact policy embedded in this product's Quick Launch deployment template, so it is what your administrator will actually use — not a representative sample. AWS Marketplace also surfaces it in the Quick Launch experience at deploy time.

Those permissions are held by your administrator, are used only for stack creation, and are not granted to Autonoma. It grants no service:* wildcards; the Get*/List* prefixes it does contain are read-only verbs, collapsed to fit the AWS Marketplace 4,000-character field limit.

Your account must allow creating IAM roles

This template creates the seven roles in §2, so the administrator running it needs iam:CreateRole (it is in the policy above). If your account restricts role creation, check which restriction applies before you launch — the stack otherwise fails partway through and rolls back:

Supplying roles you already have

If your account forbids creating roles outright, each of the seven can be supplied instead of created. Leave a parameter empty — the default — and the stack creates that role exactly as §2 describes; set it to an ARN and the stack uses yours and creates nothing:

It is all-or-nothing per role, not per stack: supply the two ECS roles and let the stack create the rest if that is what your account requires.

You do not have to write those roles yourself. This template creates all seven with the right permissions and outputs their ARNs, named to match the parameters above:

https://autonoma-quicklaunch-templates-808773666646.s3.us-east-1.amazonaws.com/docs/autonoma-quicklaunch-iam-prerequisites.yaml

Deploy it once, with an identity that can create IAM roles, using the same CustomerId you will give the product template — these policies are scoped by that name, so a mismatch produces roles that cannot reach anything. RolePath, EnablePullThroughCache and PullThroughPrefix must match too, for the same reason.

It is generated from the same template that would otherwise create these roles, so it cannot drift from them. One difference is deliberate and your security review should see it: four of the roles grant on resources the product stack creates later, which do not exist yet when you deploy this one — fourteen secrets, the ECS cluster, the db-init task definition and two log groups. Those grants are scoped by name pattern (autonoma-<CustomerId>-*) instead of exact ARN. The EFS grant, which includes ClientRootAccess, is narrowed by the tag the product stack applies rather than left as a wildcard, so it cannot reach another file system in your account. The template header states all of this again, in place.

If a supplied role is missing a grant, the stack still deploys and then fails at runtime — a task that will not start, or a database that is never initialised. §2 lists what each role must be able to do if you would rather build them under your own controls.

If you change RolePath or RoleNamePrefix, the policy linked above no longer covers these roles: it is scoped to arn:aws:iam::*:role/autonoma-*, and either setting moves them — a path to arn:aws:iam::*:role/<your-path>autonoma-*, a prefix to arn:aws:iam::*:role/<your-prefix>*. Add the matching ARN alongside the existing one in your administrator's copy. Nothing else changes — the stack refers to every role by attribute, not by name.

Three tag pairs, not unlimited. Mandated tag sets are usually small, and CloudFormation cannot build a variable-length tag list without a template transform we would rather not put in front of your security review. If your policy requires more than three, use the IAM prerequisites template instead: it creates the same roles and you can tag them however you need before passing their ARNs back.

RolePermissionsBoundary is optional and empty by default, so a buyer launching with an administrator identity is unaffected. Supplying it caps what these roles can ever do regardless of the policies attached to them, which is the control AWS recommends for delegating role creation. Autonoma's own pre-publication launch gate runs under exactly this constraint: the role that gates each release may create roles only with a boundary attached, so every template shipped to you has been launched at least once with one.

9. Removal

Deleting the CloudFormation stack removes every resource listed in §1, with one deliberate exception.

The database is snapshotted, not discarded. The RDS instance carries DeletionPolicy: Snapshot, so deleting the stack takes a final snapshot and leaves it in your account rather than destroying your data. That snapshot survives the stack and continues to incur AWS storage charges until you delete it. Remove it yourself once you are satisfied you no longer need the data.

This is also why the deployment permissions in §8 include rds:CreateDBSnapshot: without it the stack cannot complete deletion.

The deployment's registration in the Autonoma control plane can be revoked from the Autonoma dashboard.