Security starts with access, data, and deployment boundaries.

Accountability and least privilege come first.

Each engagement has a named accountable human lead. Access to client systems and information is limited to what the work requires, using named accounts where supported. Multi-factor authentication is enabled where available, shared credentials are avoided, and access should be reviewed as responsibilities change and removed promptly when it is no longer required.

Secrets stay out of source code and ordinary project documentation.

API keys, passwords, certificates, tokens, and other credentials are stored using appropriate secret-management or environment-configuration mechanisms. Development, test, and production credentials and environments are separated where the architecture permits it. Suspected credential exposure triggers rotation and incident review.

Client data is minimized and handled for the agreed purpose.

Amidship processes only information needed for the agreed outcome and prefers synthetic, masked, or minimized data for development and testing when production data is unnecessary. Client-specific classification, residency, retention, deletion, and handling requirements take precedence over the baseline.

Before transmitting client information to a material third-party AI, model, or hosted service, the engagement should identify the provider, relevant data categories, purpose, retention or training settings where known and configurable, hosting/residency implications, material subprocessors, and applicable contractual restrictions.

Secure delivery includes the path to production.

Depending on scope and risk, secure delivery can include:

• version-controlled application code and configuration;
• human design and code review proportionate to risk;
• automated tests and evaluations where appropriate;
• dependency and vulnerability review appropriate to the engagement;
• separated development, test, and production environments and credentials where supported;
• explicit authorization and acceptance before production deployment;
• documented architecture decisions, deployment instructions, and reproducible environments where practical.

AI-generated code follows the same acceptance and security expectations as human-written code.

Agent actions are an access-control problem too.

For software that can invoke tools or act on external systems, Amidship defines permitted tools and actions, applies least privilege, adds approval gates for consequential operations, preserves useful action records where appropriate, tests misuse and prompt-injection paths, and provides escalation or disable mechanisms.

The model's technical ability is not treated as permission.

Incidents require containment, evidence, and recovery.

A suspected material security or privacy incident should trigger containment of affected access or processing, preservation of relevant evidence and logs, impact assessment, client notification according to applicable contractual or legal timelines, remediation, credential rotation where needed, and documented follow-up before normal operation resumes.

Engagement-specific requirements take precedence.

Security controls are not one-size-fits-all. A government, regulated, sensitive-data, or higher-consequence engagement may require specific hosting, residency, screening, security classifications, vulnerability testing, audit evidence, incident timelines, approved services, or other controls. Those requirements are identified during qualification and delivery rather than implied by this baseline.

Current assurance posture.

Amidship does not currently claim ISO 27001, SOC 2, CPCSC/CMMC, a Government of Canada security clearance, or another formal security certification unless a verified current credential is explicitly added. Procurement responses distinguish practices implemented today, controls that will be implemented for a specific engagement, client dependencies, and certifications actually held.