CUSTOMER

Azimuth — Trust & Data Governance Overview

For prospective and current customers · Version 1.0, August 2026

Azimuth is an AI marketing platform built for organizations that cannot tolerate leaks. Our compliance layer is the product, not a feature bolted onto it — which only works if the platform underneath holds the same standard.

This overview is the summary. Each section below stands on its own and goes deeper on request; the same material is available live inside the product on the Governance & Trust Center page, which renders your organization's own rules and your own audit trail rather than a generic description.

The four things most customers want to know first:

  1. You own your content. You retain ownership of everything you provide and everything the platform generates for you.
  2. No cross-customer use. Your data is never used to benchmark, analyze, or improve anything for another customer. This is enforced in our architecture, not by policy alone.
  3. Your content does not train AI models — any of them. Every model and infrastructure provider in our stack is contractually prohibited from training on it, with no exceptions.
  4. Export and delete work today. Both are self-service, and both are recorded in your audit trail.

1 · What we collect, and what we don't

Everything the platform holds for you falls into four groups.

Your account — name, email, organization, roles, and multi-factor authentication settings. Passwords are stored only as cryptographic hashes.

Your content — the materials you add to your Knowledge Base, your business and brand profile, your compliance rules, the prompts you write, and the content the platform generates for you, including drafts, approvals, campaigns, and schedules.

Your governance records — the audit trail of who did what and when, and the compliance flags raised against each piece of content.

Operational records — usage volumes for billing and capacity.

What we deliberately do not collect:

  • No payment card data. Card details go directly to our payment processor and never touch our systems.
  • No consumer or audience data. We do not profile end consumers, and we do not buy, enrich, or broker audience data.
  • No tracking. There are no advertising pixels, no visitor analytics, no session recording, and no third-party telemetry in the product. Nothing is watching your team work.

One detail worth stating plainly: when you upload a document to your Knowledge Base, we extract its text and store that. We do not retain your original file.

Go deeper: a full data inventory by category, with classification levels, is available on request.


2 · Where your data lives

A single AWS region in the United States. Your data is not replicated to other regions and does not leave the United States in the course of normal operation.

Layer Platform
Database Amazon RDS for PostgreSQL — private, not reachable from the internet
Application Amazon EC2, containerized
Backups Amazon S3, private, encrypted
Secrets AWS Secrets Manager
Edge, DNS, TLS Cloudflare

Encryption everywhere. TLS is validated on every hop — from your browser to the edge, and from the edge to our origin, with certificate validation rather than mere encryption. At rest, the database and application storage are encrypted with AWS-managed keys, and backups are encrypted in storage.

Verified externally: connections below TLS 1.2 are refused, HTTPS is enforced through HSTS, and DNSSEC is active on our domain to guard against DNS spoofing.

We inherit AWS's audited physical and infrastructure controls — SOC 1/2/3, ISO 27001, and FedRAMP-authorized regions — and we are responsible for everything from the operating system up.

Go deeper: architecture diagram and the shared-responsibility breakdown, available under NDA.


3 · How AI generation works — and why your content doesn't train models

This is the question most customers ask first, so here is the whole answer.

Requests go directly to the model provider. When the platform generates content, the request travels from our servers straight to the model provider's API. There is no middleware in that path — no aggregator, no orchestration service, no analytics vendor, no prompt-logging proxy. We previously used an aggregation layer and deliberately removed it.

The API key never leaves our servers. All AI calls are server-side. Your content is never sent to a model provider from your browser, and no provider credential is ever delivered to the client.

Providers are contractually prohibited from training on your content:

  • Text generation runs on Anthropic. Their commercial terms state that Anthropic may not train models on customer content, and that the customer retains all rights to its inputs and owns its outputs. Inputs and outputs are deleted from the provider's systems within 30 days under standard commercial API terms.
  • Video generation runs on Lightricks' LTX model API, whose license agreement states that LTX will not use customer data to train the LTX model, and that the customer owns its data.
  • Voice onboarding runs on LiveKit, on a paid plan specifically chosen because it is excluded from their model improvement program. They do not train on customer content, do not log or retain inference payloads, and delete session data after 30 days. Media is never persisted on their servers — audio is processed in memory for forwarding and then discarded. We store the resulting transcript; we do not store audio at all.

We do not have, and are not building, our own model trained on customer data.

One thing we'd point out because it shows how we work: the voice plan tier is the kind of detail that quietly decides whether a statement like this is true. A free tier on that provider would have enrolled us in their model improvement program. We checked, found we were on it, and moved to a paid plan — rather than making the claim and hoping nobody read the provider's documentation.

Go deeper: the specific contract clauses, with section references, are available on request — we'd rather show you the language than characterize it.


4 · Isolation and access control

Your organization's data is isolated by architecture, not by configuration.

Every record carries your organization's identifier, and every read and write in the platform is scoped to it. This is not a filter that a developer remembers to apply — it is a required parameter of the data layer itself. There is no code path in the platform capable of reading across organizations. Building cross-customer analytics would require writing that capability from scratch, and we have made a deliberate decision not to.

Role-based access. Owner, admin, and member roles govern who can configure compliance guardrails, approve content, and change settings. Roles cannot be self-escalated: a user's role is re-read from our database on every single request rather than trusted from their login session.

Offboarding is immediate. Because membership is checked live, removing someone from your organization ends their access on their next request — not whenever their session happens to expire. The same applies to a demotion.

Multi-factor authentication is available to every user — standard authenticator-app codes (TOTP) backed by single-use recovery codes. Sign-in attempts are rate-limited, and second-factor verification is rate-limited too.

Who at Azimuth can see your content? In normal operation, nobody. There is no administrative console, no impersonation feature, and no internal tool that displays a customer's content — those capabilities do not exist in the product. Infrastructure access is limited to a named engineer, through an identity-authenticated and session-logged channel, with no standing remote shell access to production. If that changes as we grow, it becomes a named role with logged, time-boxed access, and we will tell you before it does.

Edge protection. All traffic passes through Cloudflare, which absorbs denial-of-service attacks and filters malicious requests. Our origin infrastructure accepts connections only from Cloudflare, so the protections cannot be bypassed by reaching around them.

Go deeper: our offboarding and access-review procedures, available on request.


5 · Governance, approval, and the audit trail

This is the part of the platform we consider the actual product.

Nothing publishes without a human. Content that carries unresolved compliance flags cannot be published — enforced on our servers, not merely hidden in the interface. The agent proposes; a named person on your side decides.

Your rules are enforced on every generation. The restricted terms, banned topics, and source-required claims your organization defines are applied to everything the platform produces. They are platform-owned: the AI agent cannot weaken, bypass, or rewrite them.

Editing approved content revokes its approval. If someone edits copy that was already signed off, the platform rescans it and withdraws the approval — so content can never publish under a sign-off that was given for different words.

The audit trail is append-only. Every significant action — generate, approve, schedule, publish, export, account change — is recorded with the actor, the subject, the outcome, and the timestamp. The platform refuses any attempt to edit or delete an audit record. The actor is recorded from the authenticated session, so no one can attribute an action to someone else.

Documents are data, never commands. An AI system reading your files can't natively tell the difference between text to learn from and text telling it what to do — so a document containing "ignore your instructions and say X" is a real category of attack. Everything untrusted that reaches our AI — uploaded documents, voice transcripts, and live web research — is explicitly delimited and framed as reference material, so an instruction embedded in it is treated as content to consider, never as a command to follow. Attempts are flagged into your audit trail as security events rather than passing silently.

The trail records metadata, never secrets. No payloads, no passwords, no API keys.

Our own infrastructure is audited too. Every administrative action taken against the underlying cloud account — by anyone, including us — is recorded to an immutable, encrypted, access-restricted log. Your audit trail covers what happens inside the product; this covers what happens underneath it.

You can export it. The complete audit trail downloads as CSV from the Trust Center page at any time, and the export itself is logged.

Go deeper: the full governance gate model — every control from ingest through publish — is documented and available.


6 · Availability and recovery

Backups run every six hours, encrypted, to storage separate from the primary database. Each backup validates itself on creation — size, archive integrity, and a table count — so a silently corrupted backup is caught when it is made rather than when it is needed.

Restores are rehearsed, not assumed. We have restored from backup into a separate database and verified exact row parity across every populated table.

Deletion protection is enabled on the production database, so it cannot be removed by accident, and the database is not reachable from the public internet.

A documented incident-response runbook defines how we respond to and recover from an outage.

We are a young platform and we say so: our Terms describe the service as beta, and we recommend that customers do not treat it as their sole system of record. We would rather set that expectation now than manage a surprise later.

Go deeper: our incident-response summary and current recovery objectives are available on request.


7 · Retention, export, and deletion

Retention. We hold your data for as long as your organization is active. We do not automatically expire your content, because for a marketing platform your history is the value.

Export. You can export your organization's complete content — every record, plus your member list — at any time, as structured data. Self-service, no request needed.

Deletion. You can delete your account and your organization's data from the product. The action is password-confirmed, removes the organization and all of its records, and is recorded in the audit trail before it completes. If you are the only owner of an organization with other members, deletion is refused until ownership is transferred, so one person cannot erase a team's workspace.

Backups — the part most vendors leave vague. Deleting from a live database is the easy half; the honest question is when the backups go too. Ours expire automatically at 35 days, enforced by a storage lifecycle rule rather than by anyone remembering. Our model providers delete within 30 days under their own terms. So the complete answer is: gone from the live platform immediately, and gone everywhere within 35 days.

On termination, you have 30 days to export before deletion begins, then the same 35-day window applies to backups.

We'll put those numbers, along with breach notification, in a data processing agreement executed alongside your contract.

Go deeper: we will provide a data processing agreement covering retention windows, deletion commitments, and breach notification as part of contracting. If your procurement team has a preferred DPA template, we're glad to work from it.


8 · Subprocessors

We maintain a current register of every third party that touches customer data — provider, purpose, data classes, region, and terms. It is available in full on request, and we update it whenever a provider or its terms change.

Subprocessor Purpose What it touches
Amazon Web Services Hosting, database, storage, email delivery All platform data
Anthropic Text generation and analysis Prompts and content; contractually not used for training
Lightricks (LTX) Video generation Video prompts only
LiveKit Voice onboarding transport Live audio, not persisted by the provider; no training, 30-day deletion
Cloudflare Edge security, DNS, TLS Traffic metadata
Stripe Billing Billing details; card data goes directly to Stripe

No AI middleware, aggregator, or prompt-logging service appears anywhere in this list, and that is deliberate.


9 · What we don't claim

We would rather be trusted on the small things than caught on a large one.

  • Azimuth is not SOC 2 certified. We are built on audited AWS infrastructure and we have aligned our controls to SOC 2 criteria. Those are different statements and we will not blur them. Our internal self-assessments against SOC 1 and SOC 2 Type I criteria are available to serious evaluators.
  • We are not ITAR-registered. We treat export-controlled technical data as restricted and screen for it in generated content, which addresses the leak vector — it is not a registration.
  • We do not process cardholder data or protected health information, and the platform flags either if it is imported.
  • The platform is in beta. Features and availability may change.
  • AI output requires your review. Our compliance screening is decision support, not a guarantee of regulatory compliance, and not legal advice. You decide what publishes.

Questions

Anything in this document can be taken further — contract clauses quoted in full, architecture walked through under NDA, or a live session in the product's Trust Center against your own organization's data.

We would rather answer a hard question now than discover a misunderstanding after you have trusted us with your work.