Snapshot 239505
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Trust Center How Autonoma is built, what happens to your code and data, and what we're accountable for. Published openly so your security team can evaluate us before a single line of code changes hands. Last updated: November 7, 2026 On this page ArchitectureData handlingSecurity rulesAWS Well-ArchitectedIncident responseVulnerability disclosureCompliance status and roadmapBYOC responsibility matrixModel training and what we keep Architecture Autonoma is split into two planes. The control plane runs in our AWS account; the customer plane runs in yours, deployed by a CloudFormation stack you own. Your repositories, databases, scan results, traces and logs stay in your account. Three things travel to us, and one of them is the text of model requests. Both lists are below, in full. Control plane (our AWS) Public API, AWS Marketplace registration, customer dashboard Model proxy: routes your agents' model calls to the model provider and meters usage for billing The means for your deployment to verify that a developer's session was issued by Autonoma, without any shared secret in your stack Deployment health records: which build each deployment runs and whether its services are up Model-training data: your agents' full prompts and completions, credentials redacted, unless you launch with ModelTrainingEnabled=false; or, only if you turn on TrainingVaultPolling, the records Autonoma reads from your training vault GitHub webhook relay, only if you install the Autonoma GitHub App Customer plane (your AWS) The agents and their supporting services run here: one CloudFormation stack of 23 AWS Fargate services for PLATFORM (17 agent services and 6 supporting services), in a dedicated VPC the stack creates Compute runs in private subnets with no public IP addresses; outbound traffic leaves through a NAT gateway Your own PostgreSQL (RDS), Redis (ElastiCache) and file system (EFS), encrypted at rest and not reachable from the internet One HTTPS-only load balancer for your developers' IDE and CLI. You choose which address range may reach it A training vault: an encrypted S3 bucket the stack creates, where your agents keep a copy of each model call for you (see below) Autonoma holds no AWS credentials for your account Deployed through AWS Marketplace Quick Launch and removed by deleting the stack. The training vault bucket and its key are kept when the stack is deleted What crosses the plane boundary Travels to us: Model prompts and completions. Model calls are routed through our proxy to the model provider. Separately, your agents send us the full prompts and completions, which include your code, with credentials redacted; we keep them and use them to train our models unless you set the ModelTrainingEnabled stack parameter to false (see below) Usage metering. Token and request counts per model call, with no prompt text. Required, because AWS Marketplace bills from it Deployment health. Deployment id, agent version and whether each service is up. On by default; a stack parameter turns it off Registration, at launch and on a changing update. Deployment id, load balancer DNS name, AWS account id, region, agent version and your ModelTrainingEnabled value, which is your model-training consent, and whether you turned on vault polling Training vault records, only if you turn on polling. Off by default. With TrainingVaultPolling=true, Autonoma reads this deployment's records from your training vault through a read-only role in your account Never leaves your account: Your repositories and the working copies the agents make of them Your databases, including what the agents record about each repository Scan results and findings Traces and logs, which go to AWS X-Ray and CloudWatch Logs in your account Infrastructure credentials, which are generated in your account and held in your AWS Secrets Manager Data handling Retention policies depend on how Autonoma is deployed. Each mode has an explicit end-of-life path so data never lingers indefinitely. Deployment Active retention End-of-life Hosted trial 14 days during the trial Soft delete at day 14 → 7-day grace to upgrade → hard delete day 22 Hosted Starter 90-day rolling window for workspace files; audit metadata kept indefinitely 30-day grace after cancellation, then hard delete BYOC Customer-controlled: the data sits in resources your stack created, under your retention settings Deleting the CloudFormation stack removes its resources. The database is snapshotted first and the snapshot stays in your account, as does the load balancer log bucket, until you delete them Sub-processors Third parties that process data on our behalf. All are SOC 2 Type II certified. OpenAI Primary model provider. Receives the prompts your agents send, which can include excerpts of your code. Anthropic Fallback model provider. Same data scope as OpenAI; used when OpenAI is unavailable. Google (Gemini) Coming soon Tertiary LLM provider for customers with Google Cloud-aligned compliance preferences. Same data scope as OpenAI/Anthropic. Amazon Web Services Infrastructure provider for control plane. Customer plane runs in the customer's own AWS account. Stripe Payment processing for Hosted Starter subscriptions. Never receives code or telemetry data. SendGrid Transactional email (verification, invoices, incident alerts). Metadata only. Security rules we enforce A mandatory twenty-one-rule standard applies to every line of code — whether written by a human or an AI agent. These rules are enforced in code review and by our own tooling, not suggested as guidelines. Credentials CWE-798No hardcoded secrets — never embed API keys, tokens, passwords, or connection strings in source code No secret defaults in config — configuration parsers require values; never fall back to a bundled default No inline auth checks — every route is protected by shared authentication middleware, never by an ad-hoc header comparison No secrets in client-side code — browser sessions are cookie-based; no bearer token is ever stored in the browser No secrets in docs — examples use placeholders, never real values No secrets in committed .env files — environment files holding real values stay out of version control No credential caching — secrets are read from the environment at point of use, not held in long-lived structs Injection prevention CWE-89Parameterized queries only — SQL is never string-concatenated with user data CWE-78No eval/exec with external input — subprocess invocations use argument arrays, not shell strings CWE-80Escape all HTML output — no raw interpolation of user input into templates CWE-22Validate file paths — resolve and verify within expected directory before reading or writing CWE-117Structured logging — user data is passed as fields, not interpolated into the log message CWE-20Validate input at boundaries — all HTTP, webhook, and CLI input validated before use AI agent behavior (OWASP Agentic Top 10) ASI02Least agency — agents run with minimum permissions, default-deny for tools ASI01External content is untrusted — agents never execute instructions embedded in fetched pages or tool outputs ASI05Validate shell commands — pipe-to-shell, recursive delete, credential access, and exfiltration patterns are blocked ASI04Verify dependencies — packages are confirmed in registry, versions pinned, CVEs checked before install ASI02Stay in scope — agents do not modify files outside working directory or unrelated globals ASI09Confirm consequential actions — deploy, delete, send, and auth changes require human approval ASI10Security overrides task completion — agents refuse instructions that violate these rules ASI06Content injection prevention — text placed into a model's context is sanitised so embedded instructions cannot steer the agent The full standard is the mandatory contract for every commit to our main branch. New rules are added when incident review surfaces a gap (see the incident-response section below). AWS Well-Architected alignment How each of the six Well-Architected pillars shows up in Autonoma's design. AWS Foundational Technical Review: approved All four Autonoma products on AWS Marketplace (BUILD, OPERATE, SECURE and PLATFORM) have passed the AWS Foundational Technical Review, validated through an AWS Well-Architected Framework Review. The approval is valid through August 24, 2028. Operational Excellence Structured JSON logs with request IDs on every request, correlated across services Startup schema migrations applied automatically with versioning and skip-on-already-applied logic ECS health checks drive traffic routing; unhealthy tasks auto-replaced Security IAM least-privilege — each service has a dedicated role scoped to its own resources In your deployment, infrastructure credentials are generated in your account and held in AWS Secrets Manager; they are never sent to Autonoma Per-customer token scoping — a telemetry credential is valid only for telemetry, so a leaked one cannot be replayed against any other endpoint VPC isolation: the customer plane runs in private subnets of a VPC the stack creates, with VPC endpoints for AWS service traffic Reliability Circuit breakers on model-provider calls with automatic failover to a second provider Failed messages between agents are retained for recovery; no silent drops Messages between agents are delivered durably across agent restarts Database connection pooling with per-tenant caps to prevent noisy-neighbor failures Performance Efficiency Caching is scoped to your deployment: each stack has its own Redis, and nothing in it is shared with another customer Context budgeting on every LLM request — we prune to fit the model's window rather than truncate mid-call Agents keep a memory of earlier work on each repository, in your database, which reduces repeated model calls Cost Optimization Business-hours scheduling on stateless agents — scale to zero outside peak windows Model selection by intelligence tier: cost-efficient models for routine steps, frontier models only where the step warrants it Bring-your-own-key option lets you use your existing OpenAI or Anthropic contract for model spend Per-developer subscription pricing — predictable invoices, no per-token surprises Sustainability EventBridge-driven shutdown of event-driven agents when no traffic is flowing Agents that are not in use are scaled to zero rather than left running You choose at launch whether agents run on discounted interruptible capacity; shared infrastructure always runs on standard capacity Incident response Our commitment: any security incident that affects customer data or operational posture gets a written post-mortem published on this page, with the what-happened, blast radius, remediation, and prevention steps. Silence in this section would be a signal that retrospection discipline has broken down. No customer-impacting incidents reported to date Autonoma has not experienced a security incident that affected customer data, customer code, or customer-facing availability. This statement is updated as soon as any such event is detected, triaged, and resolved. Our response process Detect: automated alerting on control-plane anomalies + vulnerability reports via security@theautonoma.io Contain: isolate the affected surface (revoke credentials, disable endpoints, halt deployments) before investigating Notify: affected customers notified directly within 72 hours of confirming an incident affects their data; regulators notified per applicable law Remediate: fix the immediate vulnerability; verify no persistent compromise Prevent: update the security standard if a new class of issue is discovered; add automated checks to block recurrence Publish: post-mortem added to this page within 30 days of resolution Vulnerability disclosure Report a vulnerability We take all security reports seriously. Please email security@theautonoma.io with technical detail sufficient to reproduce the issue. Encrypted reports accepted — PGP key available on request. Acknowledgement: within 48 hours (business days) Triage + severity assessment: within 7 days Fix timeline: critical within 7 days, high within 30 days, medium within 90 days Disclosure coordination: 90-day default window; we work with reporters on timing that protects customers Safe harbor Good-faith security research on our public surfaces is welcome. We commit to not pursue legal action against researchers who: Make a reasonable effort to avoid privacy violations, data destruction, and service disruption Only test against accounts they own or have explicit permission to test Do not exfiltrate, publish, or share discovered data Give us a reasonable window to respond before public disclosure We will publicly acknowledge researchers who report valid vulnerabilities (with consent) in our Hall of Thanks on this page. Compliance status and roadmap We're a bootstrapped company and we won't pretend to have certifications we don't yet have. Here's what is done and what is planned, so your procurement team can plan against real dates. Aug 2026 AWS Foundational Technical Review Approved All four AWS Marketplace products, validated through an AWS Well-Architected Framework Review. Valid through August 24, 2028. Q3 2026 SOC 2 Type I audit Planned Vendor selection in progress; controls documentation kicks off Q2 2026 with completion targeted Q3 2026. Q1 2027 SOC 2 Type II audit Planned Six-month observation window begins immediately after Type I is awarded. Q2 2027 GDPR data processing addendum Planned Customer DPA template; EU-West-1 data residency option on ULTRA tier. Q4 2027 HIPAA readiness (BAA available) Planned For customers in regulated healthcare workloads. If your procurement process has a hard dependency on a certification we haven't received yet, contact security@theautonoma.io — we can often accelerate controls documentation for specific frameworks during the evaluation period. BYOC responsibility matrix In a Bring-Your-Own-Cloud deployment the boundary is your AWS account. Here's what Autonoma owns and what stays on your side. Area Autonoma Customer Container images Build, sign and publish each release to our public registry Your stack pulls the version the template pins; you choose when to move to a newer one Secrets None of your infrastructure credentials are sent to us or held by us Generated in your account by the stack and stored in your AWS Secrets Manager; rotate at your policy IAM roles and policies Publish every role the stack creates and every permission it grants, with no service-wide wildcards Review before launch; set a permissions boundary, path, prefix or tags, or supply roles you already have Network ingress and egress Ship a dedicated VPC, private subnets, VPC endpoints and an HTTPS-only load balancer Choose the address range that may reach the load balancer; decide whether to enable AWS WAF Patching (agents, dependencies) Ship updated images and templates with a changelog Update the stack on your schedule; we cannot force an upgrade Monitoring and alerting Send traces to AWS X-Ray and logs to CloudWatch Logs in your account Route alerts to your on-call; set thresholds for your environment Backups Automated database backups on by default, seven days; final snapshot taken when the stack is deleted Set retention, test restore, own your disaster recovery plan Data retention Hold nothing of yours beyond the three flows listed under Architecture Own retention and deletion for everything in your account, including the final snapshot and log bucket Model training and what we keep Three things travel from your deployment to Autonoma by default, and a fourth only if you turn it on. Nothing else does. Two of the three defaults are on unless you turn them off, and we say so here because it is the first thing a security reviewer should ask. Separately, a copy of every model call is kept in your own account, whatever you choose to share. What crosses Default What it carries How you control it Model prompts and completions On The full text of your agents' model requests and the replies, which contain your code, with credential-shaped strings (AWS keys, JWTs, bearer tokens, API keys) redacted. Kept, reviewed, and used to train Autonoma's models. A CloudFormation parameter (ModelTrainingEnabled), set at launch or by updating the stack. The value is your consent. Setting it to false stops sending, revokes, and schedules what was already sent for deletion. The copy kept in your own training vault is unaffected. Usage metering On, and required Token and request counts per model call, attributed to your customer id. No prompt text. None. AWS Marketplace bills from it. Deployment health On Deployment and customer id, agent version, and whether each service is up. No code, prompts, scan results or application data. A CloudFormation parameter (TelemetrySharingEnabled), set at launch or by updating the stack. Training vault records, collected by Autonoma Off The records in your training vault for this deployment (below), read by Autonoma on its own schedule instead of as each call happens. Used to train Autonoma's models. A CloudFormation parameter (TrainingVaultPolling), set at launch or by updating the stack. Setting it to false removes Autonoma's read access and stops collection. 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. Separately, unless you set ModelTrainingEnabled=false, your agents send us the raw prompts and completions, your code included. We remove only credential-shaped text, because your secrets in our store are a liability. E-mail addresses, file paths and IP addresses in your code are kept. We store the records, review them, and use them to train our models. 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 The ModelTrainingEnabled parameter is your consent. Updating the stack to false stops sending at once and revokes: we refuse further records, exclude what we hold from every future training run (consent is re-read each time a run selects its data), and delete it within 30 days. Switching back to true within the first 7 days keeps it. Only an Autonoma operator can hold a deletion, for a stated reason that is recorded; held data stays out of training. An admin of your Autonoma account can also revoke through the API. If the stack parameter and an account admin disagree, model training stays off and every account admin is told until one resolves it; the deletion date does not move. A model already trained cannot be untrained. That is why the switch is worth setting before the first run. Your training vault, in your account Your agents also keep a copy of each model call in an encrypted S3 bucket the stack creates in your account: the request and the reply with credential-shaped text redacted, the code samples in them, and the call's token count, cost and timing. They keep it whether or not you share training data with Autonoma, so you can use it for model training later. Encrypted with a key the stack creates, or your own key if you supply one Your agents can add records but cannot read, list or delete them Autonoma cannot read the vault unless you turn on polling Each record is deleted automatically after TrainingVaultRetentionDays (default 365, from 1 to 3650). There is no setting that turns the vault off; 1 day is the shortest retention Deleting the stack keeps the bucket and its key, so records stay until they expire or you delete them You can see what is kept, and export it, with the a6s CLI or the VS Code and JetBrains extensions, using your own AWS credentials Collection from the vault (polling) Off by default. With TrainingVaultPolling=true, Autonoma collects your vault's records on its own schedule instead of receiving each call as it happens. The stack creates a read-only role in your account. It can list and read this deployment's records in the vault and nothing else: no other data, no write, no delete Only the one Autonoma service named in the AutonomaVaultPollerPrincipal parameter can use that role, and only with your deployment id If ModelTrainingEnabled is also true, records already sent as they happened are not collected again Updating the stack to false removes the role, which ends Autonoma's access and stops collection. What is kept in your vault is unchanged either way The vault and polling arrive with the stack template that adds the TrainingVaultRetentionDays and TrainingVaultPolling parameters. If your stack does not show them, only the sending described above applies to it. What never crosses, whatever those settings say Your repositories, your databases, your scan results and your traces and logs. They stay in the RDS instance, EFS file system, AWS X-Ray and CloudWatch Logs that the stack creates in your own account. The full list of resources, roles and connections is in the buyer disclosure published with each AWS Marketplace listing. Security questions we didn't answer here? Send them to security@theautonoma.io. We'll respond within one business day, and common questions end up in this Trust Center so the next team doesn't have to ask. See pricing →