How we handle your firm's data.

We do not migrate anything. Mail is read through Microsoft Graph. Models and folders are read through Autodesk's Data Management API. Neither your mailbox nor your drawing set is copied to our infrastructure.

Message bodies are never stored. When the platform reads project mail it keeps the extracted fact (a commitment, a request, a decision) plus the message id, subject, and a link to the original. The body is processed and discarded.

Both connectors use delegated OAuth, not application permissions. The platform can read exactly what the person who connected it can read. Connecting does not grant tenant-wide access to your mail or files, and revoking that person's access revokes ours at the same time.

This applies to permissions like Files.Read.All: under a delegated grant it covers one user's accessible files, not the whole tenant.

OAuth tokens are encrypted with AES-256-GCM before they are written to the database. The key exists only in the server environment. The credentials table has row-level security enabled with no policies for browser roles, so a browser session cannot read it.

Row-level security is enabled on every table holding firm data. A signed-in user reads their own firm's rows and nothing else. Server-side reads are scoped by firm as well, so a guessed identifier does not reach another firm's data through our API.

We tested this directly: own-firm reads and writes succeeded, cross-firm writes were denied, privilege escalation was denied, and an anonymous caller saw nothing.

Autodesk access is read-only. Microsoft mail and file access is read-only. The one write the platform performs is sending an email reply after a person has read the full draft and pressed send. Nothing sends automatically. Sending is restricted to firm owners and administrators, and every send is logged.

Every commitment, request, and code finding cites the messages and model data it came from, so it can be verified at the source. Code findings name their standard, edition, and section, and state that a screening check against model properties does not establish compliance.

Connections, disconnections, syncs, and sends are written to a per-firm audit log.

• SOC 2: We have not completed a SOC 2 audit or obtained a SOC 2 report. Current controls include dependency scanning that can block a build, change management, scoped access, and audit logging. If a SOC 2 report is required for procurement, contact us to discuss the requirement and timing.
• Independent penetration testing has not yet been completed. It can be scoped as part of an enterprise security review or deployment.
• Multi-factor authentication is inherited when you sign in with Microsoft, which is the option we recommend. We do not enforce it on email and password accounts.
• Database backups currently use our provider's standard backup configuration. Enhanced retention, point-in-time recovery, and defined recovery objectives can be configured for deployments that require them.

Security requirements vary by firm. Enhanced backup and recovery, penetration testing, authentication controls, and other safeguards can be scoped to support your procurement and risk requirements. Contact us for details.

If your IT team needs something not covered here, write to nate@aechub.org and we will answer directly.