Security for sensitive AI and software engagements

Security is part of delivery, not a layer added after the fact.

We design each engagement around a few core principles. Access is provisioned by project, not by convenience. Permissions are scoped to the minimum systems and data needed to deliver the work. Sensitive projects may use segregated environments, dedicated repositories, restricted communications paths, or customer-managed infrastructure. Tooling choices, including AI tooling, are reviewed based on the nature of the data and the obligations associated with the engagement.

For projects with elevated security or compliance needs, we adapt the operating model rather than forcing the work into a generic delivery stack.

Depending on project scope, our baseline safeguards may include encrypted data transmission, encrypted storage on supported managed infrastructure, strong authentication for core systems, managed secret handling, version-controlled delivery workflows, and logging or audit visibility where supported.

Administrative access is restricted and used only when necessary. Sensitive systems and environments are limited to named personnel. Backup and recovery practices are defined based on the hosting and delivery model used for the engagement.

Where a project requires tighter boundaries, work may be delivered inside a client-managed environment or a designated segregated environment rather than through a standard toolchain.

Access is granted on a need-to-know basis and reviewed against actual project responsibilities.

Repositories, environments, documents, storage locations, and cloud resources are scoped to the personnel assigned to the engagement. Administrative permissions are more tightly limited than standard project access. Access is updated or revoked when roles change or when project involvement ends.

Sensitive engagements may require explicit approval before access is granted to specific systems or datasets. External collaborators or subcontractors are not included in restricted projects unless explicitly authorized and subject to the same handling requirements.

AI projects introduce additional confidentiality and workflow risks that require explicit controls.

We do not use client data to train internal models unless that use is explicitly agreed in writing. Model and provider choices are reviewed based on the sensitivity of the project. For some engagements, public or general-purpose AI tooling may be limited or disallowed. Prompt flows, generated artifacts, evaluation pipelines, and derived outputs may be constrained to approved systems only.

Where needed, we can work within customer-approved environments, customer-managed infrastructure, or isolated project setups to enforce tighter control over data movement and tool usage.

For higher-assurance projects, we can adapt how delivery happens.

This may include working directly in a client's cloud environment, using dedicated repositories or storage locations for a single engagement, separating restricted work from standard delivery systems, or limiting the project to approved source-control, documentation, communication, and deployment workflows.

This model is often appropriate when work involves sensitive industrial systems, defense-adjacent workflows, proprietary internal data, or restricted technical documentation.

The systems used to deliver a project are part of the security posture of that project.

For sensitive engagements, we review the project toolchain before work begins. This can include cloud providers, source control, CI/CD systems, model providers, documentation tools, ticketing systems, monitoring tools, storage systems, and communication platforms.

Not every tool is appropriate for every project. Where necessary, we narrow the toolchain to approved vendors and approved environments only.

If we identify a security issue affecting project systems, data, or delivery workflows, we respond through a defined escalation path.

That process includes triage, containment, impact assessment, preservation of relevant evidence where available, customer notification through the agreed communication channel, and remediation planning.

For projects with additional contractual or operational requirements, incident-handling expectations can be aligned during onboarding.

Security in consulting engagements is shared.

We are responsible for the controls and practices within the agreed scope of our delivery. Clients remain responsible for their own system configurations, internal access decisions, legal classifications, and broader regulatory obligations unless those responsibilities are explicitly assigned to us in writing.

Where a project depends on customer infrastructure, customer policies, or customer-approved tooling, the final control posture is shaped jointly.

Not every engagement needs the same level of rigor. We define the appropriate control model based on the sensitivity of the work, the systems involved, and the client's requirements.

During scoping, we can discuss restricted-access workflows, approved-tooling-only delivery, segregated environments, customer-managed infrastructure, and AI-tool usage restrictions for sensitive projects.