Security

Security features and best practices for Airbuild projects.

Platform Security

Authentication:

• Email + password with strong password enforcement
• Google and GitHub OAuth
• Optional Two-Factor Authentication (2FA)
• Session management with automatic expiry

Data Protection:

• All projects are private by default
• Only you and the team members you invite can open a project — no other Airbuild customer can reach it
• Airbuild staff access project content only on a need-to-know basis, for support and incident response, under confidentiality obligations, least privilege and MFA-protected administrative access — there is no product feature through which staff browse customer content; see the Data Processing Agreement
• Published sites are public at their *.airbuild.space URL
• Source code is stored encrypted at rest

Infrastructure:

• HTTPS everywhere — TLS 1.2 or higher, certificates managed by AWS Certificate Manager
• All production compute, databases and storage run on AWS in eu-central-1 (Frankfurt): ECS, RDS, Aurora, EFS and S3
• CloudFront serves static assets from its global edge network; all origins stay in eu-central-1
• AES-256 encryption at rest via AWS KMS; project secrets are additionally encrypted at the application layer
• Project code runs under an unprivileged system user, separate from the account the platform itself runs under, and each workspace has its own project directory
• Where the runner host allows it, egress firewall rules additionally block the cloud metadata endpoints, Redis, PostgreSQL and internal service ports; where it does not, VPC security groups limit what a workspace can reach
• Regular security updates

Secret Detection

Airbuild automatically detects sensitive data in chat messages:

• API keys (OpenAI, Stripe, AWS, etc.)
• Passwords and tokens
• Connection strings
• Private keys

When something is detected, a banner appears with the value masked and a suggested variable name. It does not hold the message back and it does not mask anything in the message itself — the two actions are Save to .env, which stores the value as an environment variable the generated code can read, and Ignore, which closes the banner. If the model should never see a value, take it out of the text before you send.

Environment Variables

Best practices for managing secrets:

• Store API keys in the Environment tab, not in code
• Use separate values for Dev and Prod
• The AI is instructed to reference env vars instead of hardcoding secrets, and the secret scan that runs before publishing blocks the release if a key ends up in the code
• Integration-managed vars (DATABASE_URL) are read-only

Team Security

• Role-based access in a project: Owner, Admin, Editor, Viewer — see Team & Roles
• Role-based access in an organisation: Owner, Admin, Member and Viewer, plus custom roles an organisation defines itself with its own permission set. Billing Admin and Security Admin can additionally be assigned when a member is invited
• Admins can invite and remove members
• Ownership transfer available
• Each team member has an isolated workspace

Published Site Security

• Automatic HTTPS via CloudFront
• CORS headers configured per project
• Generated backends apply authentication per endpoint, and every publish lists any endpoint left without a security requirement for you to confirm — see Validation Before Release
• Database connections are encrypted