Azimuth Cloud Security Posture

Version 1.2 — 21 August 2026

Change log: v1.2 (21 August 2026) — §7 now states that control-plane logging is multi-region and carries log-file validation. Both were already true and neither was claimed; verified against the live account on the same date. No control changed.

Audience: Investors, prospective customers (financial services / GovCon), security due-diligence reviewers

Framework basis: cloud application security practices for financial institutions, NIST AI RMF concepts, and the AWS shared-responsibility model

Change log: v1.1 (20 August 2026) — customer-facing revision; posture stated in present tense.

On certifications: Azimuth does not claim certifications it does not hold. "Aligned with SOC 2 criteria" is not "SOC 2 certified," and we state which is true at any given time.

1. Why security is the product, not a feature

Azimuth sells an AI marketing agent to institutions that cannot tolerate leaks: financial services and government contractors. Our pitch is agent + dashboard + compliance layer — the compliance layer is the differentiator. That only works if the platform underneath it holds the same standard. This document describes that platform posture, organized around the six control areas a financial-institution reviewer will ask about: vendor due diligence, access management, incident identification & monitoring, data security, encryption, and compliance.

2. Architecture & shared responsibility

Deployment model: single-tenant-style AWS deployment.

We inherit AWS's audited physical and infrastructure controls and remain responsible for everything from the OS up — which is where the rest of this document lives.

3. Identity & access management

The reference framework calls for risk-driven access management with conditional controls. Our posture:

• No standing SSH. Production access is exclusively via AWS SSM Session Manager — IAM-authenticated, allow-rule scoped, and session-logged. There are no long-lived SSH keys to steal.
• Federated CI/CD identity. GitHub Actions deploys authenticate via OIDC federation — no long-lived AWS credentials stored in CI.
• Branch protection as the release control. Production ships from a protected main branch: a pull request is required, direct pushes are blocked, and the automated test job must pass before merge. The rule is enforced for administrators, and the deploy environment is restricted to protected branches.
• Least privilege. IAM roles are scoped to task, following least-privilege principles. End users of the dashboard see only their organization's data; administrative functions are restricted to an explicit admin allowlist.

4. Data security & classification

Following the framework's DLP and least-privilege guidance:

• Data classification. All customer data entering Azimuth is classified at intake: public / internal / confidential / restricted. For our client base, restricted explicitly includes program names, export-controlled or ITAR/DFARS-adjacent technical data, non-public financials, and personal data.
• Guardrail scan at ingest. Every document imported into the Knowledge Base is scanned before it becomes agent context; restricted content is labeled and excluded from generated copy (referenced, never quoted). This is DLP applied at the AI boundary — the leak vector that generic DLP tools do not cover.
• Least-privilege data flow. Classified data types are only accessible to the pipeline stages that need them; the agent cannot exfiltrate restricted content into a public post because the compliance gate blocks at the span level.

5. Encryption in all three data states

Per the framework: in transit, at rest, and in process.

6. Incident identification & monitoring

Our monitoring posture:

• Incident response: a named incident owner; customer notification commitments live in contracts (§8); after every incident we preserve logs, run root-cause analysis, add a regression test, and adjust authority or controls.
• Security tooling: cloud-provider-native security tooling is deployed. CloudTrail (multi-region, covering all control-plane API activity) and GuardDuty (continuous threat detection, no findings to date) are live, and Security Hub is enabled.
• Change management lifecycle: every production change follows task → review → merge, all logged and tracked: changes reach production only through a pull request against a protected branch with automated tests passing, and every release is traceable to a commit and a CI run. The same append-only discipline applies inside the product (approval records, content versions).

7. Logging & audit

• Platform audit trail: SSM session logging, CI/CD deploy history (every deploy traceable to a merge commit, its pull request, and the CI run that shipped it), CloudTrail control-plane logging, application logs. The control-plane trail spans every region, not only the one we operate in — so activity somewhere we do not normally run is recorded rather than invisible — and carries log-file validation, which signs each delivered log file so tampering with the record after the fact is detectable rather than merely unlikely.
• Product audit trail: the dashboard writes an append-only audit log of agent runs — model version, prompt version, sources retrieved, outputs, compliance flags raised, human approvals, and publish actions with external post IDs. Nothing is silently overwritten; edits create new versions.

8. Vendor & subprocessor due diligence

We apply the framework's due-diligence standard in both directions — what we demand of vendors, and what we hand customers when they run the same checklist on us.

We require of hosting and AI providers: published security reports covering access management, resiliency and backup, segmentation, encryption deployment, log management, and control-objective compliance (AWS: SOC/ISO reports via Artifact). Contracts must stipulate incident response and notification, configuration responsibilities, encryption-key management, security monitoring, and audit rights.

Model providers specifically: customer content is sent directly to the model provider's API — no third-party middleware or aggregator sits in the path — under terms that prohibit training on customer data, with enterprise/zero-retention options where offered. Provider list, terms, and data-flow diagrams are maintained for customer review.

We provide to customers: this document, the Dashboard Security Posture, the Data Governance document, and the in-product Trust Center (/governance).

9. AI-specific governance

Beyond classic cloud controls, Azimuth governs the agent itself (NIST AI RMF concepts — govern, map, measure, manage):

• Human approval gates: the agent drafts and queues; a human approves before anything publishes or spends. Flagged content is un-approvable until edited or acknowledged.
• Prompt-injection defense: all retrieved content (documents, web pages, comments) is treated as data, never instructions; embedded instructions are reported as security flags.
• Autonomy ceilings: L0–L4 authority model; irreversible or high-impact actions are prohibited by default.
• Evaluation before autonomy: the agent ships in observe/draft mode and gains authority only after passing adversarial test suites (injection, fabrication, restricted-data, and wrong-account cases).

10. Compliance posture

Relevant statutes and standards for our customer base: GLBA (financial data handling), GDPR (EU personal data), PCI-DSS (if payment data ever transits — currently it does not), HIPAA (not in scope; we do not process PHI), and ITAR/DFARS sensitivity for GovCon customers (we treat export-controlled content as restricted-class data; we do not claim ITAR registration).

Our security and governance documentation set — this document, the Dashboard Security Posture, and the Data Governance document — is published and maintained, and our controls are designed to SOC 2 criteria. We state certification status accurately and do not claim certifications we do not hold.

11. Pitch-deck summary (one slide)

• Built for institutions that can't leak: financial services & GovCon.
• Compliance layer at the product level and the platform level — same discipline top to bottom.
• Zero standing credentials: SSM-only access (no SSH keys, no port 22), OIDC-federated deploys, releases gated on a protected branch with automated tests.
• Customer data classified at intake; restricted content can't reach a public post — blocked at the span level.
• Direct-to-provider AI calls under no-training terms; no middleware retention.
• Append-only audit trail from model version to published post ID.
• Encryption in transit and at rest; keys in KMS.
• Controls designed to SOC 2 criteria; certification status stated honestly, never overclaimed.