# Security

**Last updated:** 31 September 2025

This page explains the security features and practices Brew Studio uses to keep your workspace, Developer Content, and customer data safe.

## Data security

Brew Studio applications are secure-by-default, with multiple controls to protect your data.

- **Encryption:** Brew Studio encrypts all sensitive information (API secrets, database credentials, OAuth tokens, Git SSH keys) at rest using AES-256. TLS 1.2+ is enforced in transit. Keys are managed with strict separation of duties.
- **Data-at-Rest:** We apply unique salts and strong hashing where applicable and use tokenization/pseudonymization for sensitive identifiers.
- **SSL/TLS and edge protection:** All connections to brew.studio and app.brewstudio.in are served over HTTPS with valid certificates. Public traffic is fronted by AWS CloudFront and protected by AWS WAF.
- **Private networking:** Brew Studio Cloud connects to databases and external APIs only from compute instances in a private VPC. Egress is controlled.
- **Compliant hosting:** Brew Studio Cloud runs on AWS regions and services that align with SOC 1 and SOC 2. Regular backups protect against data loss.
- **Access control:** Role-based access control (RBAC), least-privilege service roles, and audit logs are standard. MFA/2FA is supported for internal access and available to customers where enabled.

## Brew Studio Agents

Brew Studio Agents uses model providers (OpenAI, Anthropic) for responses and embeddings API.

- **Embeddings and retrieval:** When you upload files or sync repositories, Brew generates vector embeddings & AI generated code context to power search and planning. Embeddings are stored securely in a private OpenSearch cluster accessible only from the VPC.
- **Model use:** We do not use your private code or Customer Data to train general-purpose AI models without your explicit permission.

## Developer Content and repository access

- **Read-only by default:** GitHub scopes are read-only. Brew Studio never writes to your code.
- **Webhook sync:** Repositories are kept in sync via webhooks; removing a repo in Brew cleans up related webhooks automatically.
- **Retention:** On disconnect or workspace deletion, we cease new syncs and delete (or irreversibly anonymize) Developer Content within 7 days; backups age out on a rolling schedule up to 30 days.

## Query security

- **No Data Logging:** Brew’s backend is designed to act as a proxy, without logging or storing responses retrieved from databases or API endpoints. This includes response data and user input.
- **Secure Storage of Queries:** Query configurations and bodies are stored securely. In View mode, this information is not exposed to end users.
- **Credential Handling:** When executing a query, Brew Studio securely appends sensitive credentials server-side just before forwarding the request to your backend. Credentials are never exposed to the client’s browser.
- **Secrets Management:** API secrets and datasource configurations are stored encrypted. In View mode secrets remain concealed; in Edit mode, you can rotate/update but not read existing secret values.
- **SQL Injection Protection:** Prepared statements are enabled by default for SQL datasources to mitigate injection attacks.

## JavaScript security

Brew Studio takes measures to ensure JavaScript security within the platform, and it’s important to understand the context in which code executes.

- **Client-Side Execution:** Custom JavaScript in Brew apps executes on the client. Users can inspect browser-side code; never embed plaintext secrets in client code.
- **Handling Sensitive Data:** Avoid embedding sensitive keys or credentials in code. Follow client-side security best practices.
- **Local Storage Caution:** Avoid storing sensitive values using storeValue(); browser storage can be inspected by end users.
- **DOM API Exposure:** Direct DOM APIs are restricted to minimize risk. Safe framework utilities (e.g., timers like setInterval/clearInterval) are provided where needed.
- **Fetch API Specifics:** The Fetch API is supported but configured to exclude automatic cookies/session credentials by default to reduce leakage risk.

## Login rate limiting

Rate limiting on password-based login attempts is implemented as follows:

## Subprocessors

We use carefully-vetted vendors to help deliver our Services. See the Subprocessors page for details: [/subprocessor](https://brew.studio/legal/subprocessor)

## Security & compliance mapping (informational)

- **OWASP ASVS:** A2/A3 (Auth/Session), A4 (Access Control), A5 (Validation), A8 (Data Protection), A14 (Configuration) reflected in the controls above.
- **SOC 2 (CC6/CC7):** Logical access, change management, monitoring/logging supported via RBAC, rate-limiting, key management, and event/audit logs.
- **GDPR/DPDP:** Data flows, legal bases, retention, and user rights are documented in our Privacy Policy. See: [/privacy-policy](https://brew.studio/privacy-policy)