
Security and trust
Your code. Your data. Our posture.
A single page for procurement and security review: how we handle the model layer, the cloud, secrets and the audit trail, and what we are not certified for yet.
Below is how our CTO’s practice handles security on production work for clients of Elegant Software Solutions today. For each Bravo engagement, the approved model providers, hosting region, data access, review gates and audit evidence are agreed in writing before work starts.
Where the AI models run
Our CTO's current work uses frontier models from providers including Anthropic, OpenAI and Google. Provider, plan, data use and retention terms vary, so we document and approve the route for each client workflow before processing its data.
Day-to-day engineering can run on paid interactive plans. A production agent may need an approved developer API or a client-owned model environment. The processing route and any no-training commitment are written into the engagement rather than assumed from a model name.
Secrets are not stored in source code. If you have enterprise model agreements, we can assess using your keys and contracts, with the access and audit requirements recorded in the design.
Where your code and data live
Infrastructure is set up per engagement, in your cloud tenant or ours by agreement. There is no shared account that clients are pooled into.
Our defaults are Azure US regions for ERP, EDI and enterprise integration, and Vercel with Supabase in US regions for web work. Data moves only between systems approved for the engagement, and new destinations need approval before they are added.
Encryption and retention
Data is encrypted in transit with TLS and at rest using the cloud platforms' built-in encryption.
How long engagement data is kept, and how it is returned or deleted when an engagement ends, is written into each engagement agreement.
How secrets are handled
Secrets never live in code, in committed configuration files or in chat. We use a business password vault with service-account access, and per-environment key vaults with managed identities on Azure engagements.
Sensitive partner credentials are regenerated from their source of truth when needed and are scrubbed from documentation and handover packets.
Review and audit
An independent reviewer checks the version a builder produced before release. The published MDSi autonomous bug-fix pipeline has a three-model adversarial gate for its defined class of work; that is an example of a specific implementation, not a default promise for every engagement.
For each client workflow, we define which actions, approvals, exceptions and results must be recorded, who can inspect them and who authorizes production. Those controls are acceptance criteria, not a blanket assertion that every possible event is already logged.
What we’re not, yet
Stated plainly, so nobody wastes a call on it:
- We are not SOC 2 certified.
- We are not HIPAA certified. If protected health information is central to your workload, scope and business associate agreements must be discussed first.
- We are not ISO 27001 certified.
- We are not FedRAMP authorized.
- We do not yet hold enterprise-tier contracts with the model providers ourselves. If you have one, we will run on your keys.
- We are not a managed-cloud or hosting provider. We build and operate software; we do not sell hosted infrastructure.
If any of these is a hard requirement for you or your buyer, tell us before anything is signed. We will scope around it, bring in a partner who holds it, or tell you honestly that we are not the right fit.

Security review is part of the first conversation.
Bring your questionnaire. Specific account, configuration and tenancy details are shared under NDA during review.