# Entea security architecture

Last updated: 18 September 2026  
Status: Published technical overview; not a certification

## Scope

This document describes controls implemented in the Entea control plane and its customer-cloud deployment workflow. A customer’s selected cloud, model, database, and integration providers have their own security controls and contractual terms.

## Trust boundaries

1. **User boundary.** A request begins with an authenticated user. The server resolves the user, active organization, membership, and role. An organization or workspace identifier is never sufficient authorization by itself.
2. **Control-plane boundary.** Entea stores organization configuration, application requirements, build and deployment records, audit events, and encrypted provider references. Generated applications do not use the Entea control database for application traffic.
3. **Model boundary.** Entea sends the context needed for a requested build through the organization-selected model connection. Model output is treated as untrusted input and must pass source, build, test, and deployment gates.
4. **Build boundary.** Build work executes in an isolated working directory. Attachments are size-limited and screened for executable signatures, disguised binary content, and the standard antivirus test marker. Managed malware scanning remains a production-readiness requirement.
5. **Customer-cloud boundary.** Verified images, application runtime configuration, application databases, and production traffic live in the connected cloud account. Runtime secrets are written to the selected provider’s secret store where that deployment adapter supports it.

## Identity and access

- Passwords are hashed with scrypt.
- Sessions use opaque random values. Only a hash is stored server-side; the browser receives a secure, HTTP-only, same-site cookie in production.
- TOTP two-step verification and single-use hashed recovery codes are supported.
- Organization-wide MFA enforcement is blocked until every active member is enrolled.
- Service tokens are organization-bound, hashed at rest, shown once, scoped, expirable, revocable, and audited.
- High-risk production and database changes can require explicit administrator approval.

## Tenant isolation

Organization-scoped APIs authorize the signed-in actor and filter each query by workspace. Cloud connections, model connections, data sources, applications, build records, databases, deployment targets, service tokens, and audit events retain that organization boundary.

Authenticated end-to-end tests exercise organization isolation. These tests are engineering evidence, not an independent security assessment.

## Deployment controls

- Source is packaged into an immutable image after verification.
- Database migrations are validated, checksummed, approved, and applied under a database lock.
- A candidate deployment must pass health and acceptance checks before promotion.
- Previous verified revisions can be restored without rebuilding.
- Cleanup operations target application-scoped containers, routes, files, secrets, and database resources while preserving shared organization infrastructure.

## Logging and evidence

Security, build, deployment, configuration, and administrative activity is recorded with organization, actor, action, resource, outcome, and supporting metadata where applicable. Credentials and secret values are excluded or redacted from ordinary responses and worker logs.

## Known gaps

- No independent penetration test has been completed.
- SOC 2 and ISO/IEC 27001 certification are pending.
- Managed malware scanning is a launch-readiness item and must not be assumed active from the built-in upload screening alone.
- Final legal terms, regional processing commitments, and contractual service levels require an executed customer agreement.

Security questions or responsible disclosures can be sent to connect@entea.in with the subject “Security report.” Do not include live credentials or sensitive customer data in the first message.