Deckard Labs · Legal
These are the practices we bring to client engagements. Each engagement agreement makes them contractual and adds anything the client's situation requires.
Client infrastructure, API keys, and vendor accounts are created in the client's name from day one. Access for our engineers is granted through the client's own identity and access controls, scoped to the engagement, and revocable by the client at any time. When an engagement ends, everything keeps working without us, because you always held the keys.
Managed deployments run in a dedicated Google Cloud project per client; we do not commingle client workloads. On request, systems run entirely on the client's own infrastructure or cloud tenancy so data never leaves the client's environment.
Encryption in transit everywhere; least-privilege access; multi-factor authentication on accounts we operate; secrets kept in managed secret stores, never in code; audit logging on automations that touch business records. If we become aware of a security incident affecting client data, we notify the client promptly and without unreasonable delay.
After handoff we retain engagement documentation and the code we authored. We do not retain copies of client business data beyond what an active engagement requires, and we return or destroy working copies at the client's direction at engagement end.
Automations are designed so business data stays inside the client's own systems and accounts. We do not route client data through consumer AI tools, and we do not use client data to train models. Where an automation calls an AI provider, it does so under the client's own account and that provider's business terms.
Engagements touching regulated data (for example, health or financial records) are scoped so that data remains inside the client's existing compliant systems, with our automation operating around it under the client's controls and any required agreements executed before work begins.