Aha! Builder is the AI app builder for product teams. This article describes how applications built with Aha! Builder are hosted, secured, reviewed, and governed — and where to configure each control.
This article is written for IT, security, and compliance teams evaluating Aha! Builder. It is self-contained; you do not need an Aha! account or a product demonstration to work through it. If you are an Aha! Builder user preparing for an internal review, the last section describes what to bring to that conversation.
Click any of the following links to skip ahead:
Why governance matters for AI-built applications
More people can build software than ever before. The person closest to a problem can now build the solution to it in days rather than quarters.
Software that runs the business still has to meet your organization's standards: a named owner, controlled access, a known set of connections, and a way to turn it off. Aha! Builder builds those in.
Every application is created inside an account your administrators control, runs on infrastructure Aha! manages, and appears on a central Governance page from the moment it exists. Administrators set the rules that govern what any application may do before anyone builds one. Teams move quickly inside boundaries you have already drawn.
How Aha! Builder works
Aha! Builder generates complete, working applications from a description written in natural language.
Who builds: People on your team who hold an Aha! Builder seat, working with Elle (the AI assistant in Aha! software)
What is generated: A standalone application written in TypeScript, using React for the interface and a PostgreSQL database. Each application gets its own database. The generated code is separate from any existing codebase your organization maintains.
Where it runs: On infrastructure managed by Aha!, described in Hosting and infrastructure below
Preview and Production: Every application has two environments. Preview is where building and iteration happen. Production is the deployed application your end users reach. The two are fully separated — each has its own database, authentication configuration, user list, integrations, secrets, and logs. Data does not move between them.
What deploying means: Publishing an application to Production so end users can reach it at a URL. Deployment is a controlled step, and administrators can restrict who is permitted to take it.
Controls at a glance
Control |
What it does |
Where it is configured |
Plan |
|---|---|---|---|
Constrain what every application in the account is permitted to do |
Governance -> Rules templates |
||
Apply a different rule set to a group of applications |
Governance -> Rules templates |
||
Require a governance administrator to deploy any application |
Governance rules |
||
Prevent applications from making outbound network requests |
Governance rules |
||
Prevent applications from including Aha! AI (Elle) functionality |
Governance rules |
||
Limit which identity providers applications may use |
Governance rules |
||
Restrict application access by IP address |
Governance rules or Configuration -> Security |
||
Prevent applications from being embedded in a frame on another website |
Governance rules or Configuration -> Security |
||
Four automated code security assessments with downloadable reports |
Documents -> Security |
All plans |
|
Four automated privacy assessments with downloadable reports |
Documents -> Privacy |
All plans |
|
Record of region, certifications, and encryption |
Documents -> Hosting |
All plans |
|
Record of backup and recovery posture |
Documents -> Business continuity |
All plans |
|
Control who can create and access applications in the account |
Settings -> Account -> Users |
All plans |
|
Define end-user roles and manage who can sign in to a deployed application |
Configuration -> Authentication -> Roles |
All plans |
|
Connect applications to your identity provider |
Configuration -> Authentication |
||
Download the complete application codebase |
Implement -> Code |
All plans |
Hosting and infrastructure
Applications built with Aha! Builder run on the same infrastructure as the rest of the Aha! product suite. Every application carries its own hosting record, viewable at Documents -> Hosting, which states the following.
Provider: The application is hosted by Aha! Underlying data center services are provided by Amazon Web Services.
Certifications: Aha! maintains ISO 27001 certification. The underlying AWS infrastructure holds SOC 1, 2, and 3 certifications.
Data center location: The hosting document names the AWS region for that specific application.
Encryption in transit: TLS 1.2 and 1.3 with strong ciphers. Production certificates are generated by Let's Encrypt and renewed automatically.
Encryption at rest: Code, database, and file storage are automatically encrypted using AES-256 encryption.
Firewall: A network firewall limits access to only the running application.
Each application receives its own PostgreSQL database, isolated from every other application in the account.
Data handling and AI
Aha! Builder uses AI to generate and modify application code. This section covers which providers process your data, whether it trains models, where processing happens, and how to turn it off.
Model providers: Aha! uses state-of-the-art models from Anthropic, OpenAI, and Google, chosen for the best outcomes on each use case. These models run on secure infrastructure built for enterprise use. Aha! maintains a current list of subprocessors at https://www.aha.io/legal/subprocessors and publishes its AI security policies at https://www.aha.io/legal/security/ai-features.
Model training: Your account data is never used to train AI models. Aha! does not use your content for model development and does not share it with other customers.
Processing location: AI processing is performed in your account's region or in the United States, using the same secure infrastructure that runs the rest of Aha! software.
Data protection: AI functionality follows the same privacy and security standards as the rest of Aha!, including encryption in transit and at rest, and role-based access.
Governance administrators can remove AI from Aha! Builder applications with the Enable AI usage rule.
Identity and access
End users of an application built with Aha! Builder do not need an Aha! account. Applications use their own authentication, separate from the Aha! account credentials of the people who build them.
Aha! Builder supports seven authentication methods, each of which an administrator can permit or block across the account:
Password: Users sign in with their email address and password.
Aha!: Users sign in with their Aha! account.
Google: Users sign in with their Google account.
GitHub: Users sign in with their GitHub account.
Microsoft: Users sign in with their Microsoft account.
SAML: Users sign in through a custom single sign-on provider. Available on the Aha! Builder Scale plan.
JWT: Users sign in through a custom single sign-on provider using a JSON Web Token. Available on the Aha! Builder Scale plan.
Three further accountwide controls apply to every application:
Require authentication: Requires users to sign in before they can reach any application
Allow signup: When disabled, only existing users can sign in and new users cannot create accounts.
Clickjacking protection: Prevents applications from being embedded in a frame on another website. It is disabled by default.
Within an application, builders configure access at Operate -> Configuration -> Authentication. Applications can be configured so that authenticated users share data, so that each user sees only their own data, or so that access is open. Built-in Admin and User roles provide a starting point for role-based access control. Application-level security settings, including clickjacking protection and IP address-based access control, are configured separately at Operate -> Configuration -> Security.
Built-in security and privacy reviews
This is the part of Aha! Builder most directly relevant to a security review.
Every application carries a set of documents at Operate -> Documents, covering Security, Privacy, Hosting, and Business continuity. The security and privacy tabs run automated reviews against the application's own code and record the results.
Security reviews
Four assessments are available. Each records a review date and status and produces a report you can open and download. Any review can be rerun with Repeat review after changes are made.
Review for secure by design principles: Checks that security is built into the application architecture and features from the start — so risks are minimized by default rather than addressed later
OWASP Top 10 review for design or coding issues: Assesses the application design and code against the 10 most critical web application security risks identified by the Open Worldwide Application Security Project
Static code analysis for vulnerabilities: An automated review of source code to detect potential security flaws, coding errors, and unsafe patterns
Dependency vulnerability scan: An automated check of application dependencies for known security weaknesses
Privacy reviews
Four privacy assessments run the same way, with the same review history and downloadable reports.
PII data review: Identifies and documents all personally identifiable information the application collects, processes, and stores
GDPR review: Assesses compliance with the General Data Protection Regulation, including data protection principles, user rights, consent mechanisms, and data processing activities
CCPA review: Assesses compliance with the California Consumer Privacy Act, including consumer rights, notice requirements, opt-out mechanisms, and data security measures
Cookie usage review: Analyzes all cookies the application uses, including their purposes, lifespans, and the data they collect
The reports are yours to download and share. They support your own review process rather than replacing it — a passing review is evidence for your compliance file, not a substitute for your judgment.
Administrative control and governance rules
The Governance page gives administrators a single place to see every application in the account and to constrain what those applications may do. Navigate to Governance in the top navigation bar.
Access to the Governance page requires an Aha! Builder seat and the governance administrator role. Account, billing, and customization administrators do not have access by default. To grant it, navigate to the User menu -> Settings -> Account -> Users, open the user record, and under Product administration, select Aha! Builder governance.
Governance rules
Rules apply to every application in the account unless a template overrides them. The following rules are available:
Allow signup: Controls whether new users can create accounts in applications
Require authentication: Requires users to sign in to access applications
Enable authentication methods: Controls which identity providers applications may use
Application owners can deploy applications: When disabled, only governance administrators can deploy. Use this when your organization requires an approval step before an application goes live.
Applications can access the internet: Controls whether applications can make outbound network requests to external services and APIs. When disabled, applications cannot connect to external systems, including any configured integrations. This is one of the most restrictive controls available, so evaluate the impact before disabling it.
Applications can send emails: Controls whether applications can send email to users
Enable AI usage: Controls whether builders can include AI functionality in the applications they build
Application owners can share code: Controls whether owners can generate and send code download links to external developers
Default IP address restriction: Restricts application access to a list of permitted IP addresses. This rule overrides per-application IP settings and applies immediately without requiring a deployment. Filters accept individual IPv4 addresses, CIDR blocks, address and netmask pairs, and address ranges.
Clickjacking protection: Prevents applications from being embedded on other websites. This rule is off by default, so applications can be framed unless an administrator turns it on. Changes take effect immediately, without a deployment.
Two properties of this model matter for a review:
Disabling a capability is absolute. When a capability is disabled, it is removed for all users of the affected applications, even where an individual role would normally permit it. Enabling a capability does not elevate anyone beyond what their account and role permissions already grant.
Rules can be applied differently by application group. A rules template applies its own rule set to the applications assigned to it, taking precedence over the account defaults. An application can be assigned to one template at a time. Applications with no template use the account defaults. Deleting a template returns its applications to the defaults.
Oversight and audit trail
The Applications tab on the Governance page lists every application in the account. Default columns cover Application name, Deployment status, Application authentication, Application rules template, Application tags, and Application last active date.
Additional columns can be added, including the results of all eight security and privacy reviews, along with the application's creator, creation date, and description. This gives an administrator a single view covering this information on every application in the account: its deployment status, how users authenticate to it, which rules govern it, when it was last used, and whether it has passed its reviews.
Each row also opens:
Secrets: The credentials configured for that application
API requests: The external domains that application makes requests to
Delete: Permanent deletion of the application. This action cannot be undone.
Within an individual application, Operate -> Configuration -> Server logs records HTTP requests, database activity, rendering, and errors, with Preview and Production kept separate. Implement -> Code -> History records every change, supports review of past versions, and allows rollback.
Business continuity
Every application carries a business continuity record at Documents -> Business continuity, which states the following:
Monitoring: Production applications are constantly monitored and automatically restarted if issues are detected.
Deployment: Production deployment switches between application versions, so a release is immediate and reversible.
Database availability: The database runs in high-availability mode with a hot replica in a separate data center.
Code backups: Code is automatically backed up. Most code changes are also stored separately in a revision control system, which enables fine-grained rollback.
Database backups: Database backups are generated hourly and retained for 30 days.
Code ownership and portability
Your organization owns all code and intellectual property created in Aha! Builder. Aha! makes no claim on anything you build.
Full visibility: The complete source is available at Implement -> Code. Developers can read and edit it directly.
Export at any time: Select Download ZIP on the Code page to download the entire codebase.
Runs independently: An exported application can be hosted and run outside Aha!
Dependencies to recreate: An exported application relies on services Aha! provides. Single sign-on, user management, file upload and storage, AI functionality, and email delivery would need to be reconnected in a new environment.
Aha! Builder Scale plan customers can also invite a developer to inspect an application using the developer guest pass, which grants a technical reviewer two hours of access without requiring a seat.
Bring this to your review
If you are preparing to discuss Aha! Builder with your IT, security, or compliance team, the following will make that conversation shorter.
Run the reviews and bring the reports: During a trial, run the four security assessments and four privacy reviews against a real application and download the reports. Your security team can then evaluate an actual application rather than a vendor description of one.
Decide which governance rules you will accept upfront: Arriving with a proposed rule set covering who may deploy, whether applications may reach the internet, and which authentication methods are permitted turns an open-ended risk conversation into a configuration decision.
Name an owner for every application: The Governance page tracks the creator and last active date. Knowing who maintains an application and when it was last used answers most lifecycle questions before they are asked.
Share the hosting and business continuity details: Both cover most of what a standard vendor security questionnaire asks.
If you have questions this article does not answer, please reach out to our Customer Success team.