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: October 13, 2026
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: prompts and completions, unless you turn model training off
- 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
- Autonoma holds no AWS credentials for your account
- Deployed through AWS Marketplace Quick Launch and removed by deleting the stack
What crosses the plane boundary
Travels to us:
- Model prompts and completions. Model calls are routed through our proxy to the model provider. Prompts can include excerpts of your code. We keep them and use them to improve the models unless you turn model training off (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, once. Deployment id, load balancer DNS name, AWS account id, region and agent version
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 soonTertiary 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.
AWS Foundational Technical Review
ApprovedAll four AWS Marketplace products, validated through an AWS Well-Architected Framework Review. Valid through August 24, 2028.
SOC 2 Type I audit
PlannedVendor selection in progress; controls documentation kicks off Q2 2026 with completion targeted Q3 2026.
SOC 2 Type II audit
PlannedSix-month observation window begins immediately after Type I is awarded.
GDPR data processing addendum
PlannedCustomer DPA template; EU-West-1 data residency option on ULTRA tier.
HIPAA readiness (BAA available)
PlannedFor 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. Nothing else does. Two of the three are on unless you turn them off, and we say so here because it is the first thing a security reviewer should ask.
| What crosses | Default | What it carries | How you control it |
|---|---|---|---|
| Model prompts and completions | On | The text of your agents' model requests and the replies. Kept, and used to improve the models. | The Model training setting in the Autonoma dashboard. Turning it off stops collection immediately and excludes what was already collected from future training runs. |
| 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. |
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 data is excluded from every future training run. Consent is re-read each time a run selects its data.
A model already trained cannot be untrained. That is why the switch is worth setting before the first run.
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 →