Set default rules for applications
Default rules define the baseline capabilities available to every application in your Aha! Builder account. Governance administrators use default rules to control which authentication methods are allowed, whether owners can deploy to production, and whether applications can access external services, send emails, or use AI. Default rules apply to all applications unless a rules template overrides them for a specific application.
This article discusses functionality that is available to Aha! Builder Team and Scale plans.
To change any default rule, navigate to the governance page, select the Rules templates tab, and click Default rules. Toggle the rules you want to change, then click Save changes.
Click any of the following links to skip ahead:
Allow signup
This rule controls whether new users can create accounts in the applications in your account. When enabled, anyone who reaches an application can create an account using the authentication methods that application allows. When disabled, only people who already have an account can sign in.
Disabling this rule does not affect existing users. They can continue to sign in as usual.
Require authentication
This rule requires users to sign in before they can reach an application. When disabled, application owners decide for themselves whether their own application requires a sign-in.
Enable this rule when your organization needs every application in the account to sit behind a sign-in, regardless of how an individual owner has configured it.
Limit authentication methods
Control which identity providers are available for application authentication. Each method has its own toggle:
Password: Users sign in with their email 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 via SAML.
JWT: Users sign in via JSON Web Token (JWT).
Any custom single sign-on providers you have added appear in this list by name, each with its own toggle.
SAML and JWT SSO are available to users on the Aha! Builder Scale plan.
When you disable an authentication method here, it becomes unavailable across all applications in the account, even if an application owner has configured it. This is useful when your organization requires all applications to use a specific identity provider.
Enabling an authentication method in the default rules does not automatically configure it for any application. Application owners still need to set up authentication for their own applications through Operate -> Configuration -> Authentication.
Owners can deploy applications
This rule controls whether application owners can deploy to production. When enabled, any user with the owner role on an application can deploy it. When disabled, only administrators can deploy applications.
Disabling this rule is useful when your organization requires an approval step before applications go live. Governance administrators can review application security, authentication, and integration configurations on the Applications tab before deploying to an individual application.
Applications can access the internet
This rule 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.
Consider disabling this rule when your organization needs to prevent applications from sending data to third-party services.
This is one of the most restrictive governance controls, so evaluate the impact carefully before disabling it.
Applications can send emails
This rule controls whether applications can send emails to users. When disabled, no application in the account can send email notifications, reminders, or other messages, even if the application has been configured with email delivery.
Enable AI usage
This rule controls whether builders can include Aha! AI functionality in their applications. When enabled, application owners can add AI-powered features using Elle, the Aha! AI assistant. When disabled, Aha! AI capabilities are removed from all applications in the account.
Elle usage in applications consumes Aha! Builder AI credits. If your organization wants to control credit consumption, you can disable AI usage at the governance level.
Application owners can share code
This rule controls whether application owners can generate and send code download links to external developers. When disabled, owners cannot create those links, and developers outside your account cannot download an application's codebase.
Enable this rule when your teams work with contract developers or need an outside engineer to review generated code. Disable it when code must stay inside your account.
Default IP address restriction
This rule restricts access to applications by IP address across your account. Only users whose IP address matches the filter you enter will have access. A default IP address restriction overrides the IP setting on each application's Security page and applies immediately, without a deploy.
Enter one or more IP address filters as a comma-delimited list. Supported formats:
IPv4 address: A single address, such as 192.168.1.1.
CIDR block: A range in CIDR notation, such as 192.168.0.0/16.
IPv4 address + netmask: An address paired with a netmask, such as 192.168.1.0/255.255.255.240.
IPv4 address range: A start and end address separated by a hyphen, such as 192.168.0.1-192.168.255.255.
Verify that your own IP address is included before you save, or you will lose access along with everyone else in your account.
Clickjacking protection
Clickjacking protection prevents applications from being embedded on other websites. Disable clickjacking protection when embedding is required. Changes take effect immediately.
This rule is off by default, so applications in your account can be embedded unless you turn it on. Turn it on when your organization wants to block other sites from framing an application and tricking your users into clicking something they cannot see. Leave it off when embedding applications in an intranet portal or another internal tool is a normal part of how your teams work.
Application owners can also set clickjacking protection for an individual application on its Security page.