Security at BimCode

The single most important thing about BimCode's security model: your Revit project files never leave your machine. The assistant only ever sees the specific elements, parameters or views you point it at, and only while it is actively working on them.

Your plugins then run inside Revit, on your own machine. They check in with us as they open to confirm your subscription, so they do need a connection to start — but nothing about your model is uploaded, then or ever.

Your conversations with the assistant stay on your machine as well. They are stored in your Windows user profile, not on our servers.

When you use the AI features, the content of your request — your prompt and the conversation, the element data and view images the assistant reads from your model, and the code it writes — is sent to a third-party AI model provider to generate the response. Today these providers are Anthropic, OpenAI, Google, xAI, DeepSeek, Moonshot and Z.ai; which one handles a request depends on the model you, or your organization, select. That content is processed under the provider's own terms and privacy policy, not ours, and we keep no copy of it on our servers — only the usage record: tokens, model and cost.

The full disclosure, including what to keep out of your requests, is in our Privacy Policy.

All traffic between the BimCode client, our backend, and the AI providers we use is encrypted with TLS. If your organization connects its own endpoint, its transport is your organization's responsibility. Generation requests carry only the snippets needed to fulfil them, not your wider model.

Sign-in is handled by a dedicated identity provider. Enterprise customers can sign in through single sign-on (SAML/OIDC) with the identity provider they already use, and automate provisioning and deprovisioning through SCIM, so access follows your directory.

Inside an organization there are two roles, member and admin. Removing a member deactivates their membership and signs them out everywhere, and a closed or deactivated account is locked out immediately, on every device.

Every plugin package is encrypted with its own content key. That key is wrapped under a master key held in our managed key store, and the package itself moves between your machine and cloud storage over short-lived links without passing through our servers. Each package is signed (ECDSA P-256) when it is exported, and the add-in verifies that signature before it installs anything.

A plugin checks in with us each time it opens. If a package is revoked, it stops unlocking the next time it opens.

Every version of a community plugin is reviewed by BimCode staff before it is listed, and a newer upload waits in the review queue while the last reviewed version keeps serving. A listing can be taken down and its package revoked at any time.

If your organization connects its own AI provider account or endpoint, the API key is stored encrypted (AES-256-GCM) under a master key in our managed key store. It is decrypted only for the outbound call that needs it, and it is never returned through our API — not even as ciphertext.

BimCode's backend, database and storage run on Microsoft Azure. Credentials live in a managed secret store rather than in code or configuration; every read of a secret is logged, with the identity that read it, to a retained log workspace, and database connections are logged the same way.

The database is backed up automatically, and a separate encrypted copy is taken daily and held outside Azure, so the platform never holds the only copy.

Storage accepts HTTPS only, and the website is served with a strict content-security policy and HTTPS-only (HSTS). Error reports have prompt content filtered out on the server and Windows user names removed by the add-in before they are sent.

If you believe you have found a security vulnerability, we want to hear from you. Email support@bimcode.ai with the details and steps to reproduce. Our contact details are also published in the standard place, security.txt.

We ask that you test only against your own accounts and data, never other users'; that you do not run denial-of-service, spam or social-engineering attacks; that you stop as soon as you have enough to show the problem, and do not download, alter or delete data that is not yours; and that you give us a reasonable window to investigate and fix the issue before you publish anything.

Research carried out in good faith and within these rules is authorized. We will not pursue or support legal action against you for it, and if a third party does, we will make it known that your work was authorized. We are grateful for every report made this way.