Security Overview

Last updated 28 October 2026

This page describes the safeguards architecture.dev maintains for Customer Content in the architecture.dev platform and its hosted environment. Agreements that refer to the architecture.dev Security Overview, including the architecture.dev Rider to the Gridlight Terms, refer to this page.

Hosting and physical security

Customer Content in the hosted environment is stored and processed in the United States, on Amazon Web Services. Physical security of the data centres, including access to the buildings and to the hardware, is provided by AWS. The other providers that process Customer Content are listed on the Subprocessors page.

Encryption

Customer Content is encrypted in transit. Every connection to the platform uses TLS, both from the browser to Cloudflare’s network edge and from the edge to architecture.dev’s servers. The architecture.dev domain is on the HTTP Strict Transport Security preload list, so browsers refuse to connect to it without TLS.

Customer Content is encrypted at rest. Server storage volumes use AWS EBS encryption. Application secrets, including database credentials and API keys, are held encrypted in AWS Systems Manager Parameter Store and never stored in source code, images or logs.

Separation between customers

Each customer’s data is held in its own tenant, and each tenant is a separate database schema. A query runs against the schema of the tenant that made the request, so it cannot reach another customer’s data by omitting a filter.

Within a tenant, the platform checks every action twice: whether the user’s role permits the action at all, and whether the user may perform it on the particular record or party concerned.

Access by architecture.dev personnel

Access to Customer Content is limited to personnel who need it to provide the service, and is granted on least privilege.

• Personnel sign in through a single identity provider, Microsoft Entra ID. There are no shared accounts and no local account stores.
• Multi-factor authentication is required for every account with access to an architecture.dev system.
• Servers accept no SSH connections, and no SSH keys exist. Administrative access to a server is only through AWS Systems Manager Session Manager, under an individual, named AWS identity.
• Servers accept inbound traffic on ports 80 and 443 only.
• Access is removed when a person’s role changes, rather than accumulated from previous roles.

Changes to the platform

Changes to the platform are made through pull requests, and each change is attributable to a named person. Security-sensitive code, meaning authorisation, tenant separation and the handling of secrets, is reviewed line by line, whoever wrote it. Builds install dependencies from a committed lockfile, so a build cannot silently pick up a different dependency than the one reviewed.

AI processing

The platform sends Customer Content to the AI model providers listed on the Subprocessors page only to generate Output for the customer that submitted it. architecture.dev does not sell Customer Content and does not use it to train AI models.

Incident response

architecture.dev operates a written incident response process with defined severities, owners and escalation. When a security breach affecting a customer’s Customer Content is confirmed, architecture.dev notifies that customer without undue delay, and in any event within 72 hours.

Reporting a security issue

Report a suspected vulnerability or security incident to support@architecture.dev, with “Security” in the subject line. Please include enough detail to reproduce the issue, and do not access or change data that is not yours while investigating.

Changes to this page

architecture.dev updates this page when its safeguards change. The date at the top of the page shows when the text last changed.