Skip to main content
Status of this portal. The contents of this portal are AtlaSent’s good-faith representations as of the Last reviewed date in the “How we keep this portal honest” section below. They are not warranties, do not create contractual commitments, and are superseded by the express terms of any executed agreement between AtlaSent and Customer (including the MSA, DPA, BAA, SLA, AUP, and Order Form). AtlaSent’s contractual commitments concerning security controls are set out in the DPA Annex II. Any inconsistency between this portal and the DPA is resolved in favor of the DPA. Customers must independently verify any control they rely on.
This is the single URL to share with a buyer’s security or procurement team. Everything here cross-links to canonical evidence elsewhere in this site (compliance claims matrix, security architecture, legal documents) so the answer to “can we trust AtlaSent with this data?” is one navigation step away from any question.Canonical home: trust.atlasent.io. Cross-document references in the merged legal document set resolve here.

​
What AtlaSent is

AtlaSent is execution-time authorization infrastructure. It sits in the execution path of high-impact automated actions — AI agents, CI/CD pipelines, regulated workflows — and answers one question before any consequential action runs: is this actor authorized to take this action right now, against this target, in this context? We operate AtlaSent as a multi-tenant SaaS service. Customer data is logically segregated by organization_id at the database row-level security layer. The canonical decision evidence is an immutable, append-only, hash-chained audit log (GA today). Portable Ed25519-signed evidence bundles assembled from that log for offline third-party verification are on the published roadmap; see audit and evidence posture below for the explicit boundary between the two trust surfaces. AtlaSent does not, and has not in the preceding 12 months, sold or shared (as those terms are defined in the CCPA) Personal Information. Customer Personal Data submitted to the Service is governed by the DPA; AtlaSent does not use Customer Personal Data to train any general-purpose machine-learning or large-language model. See the Privacy Policy for details. See the compliance claims matrix for the canonical list of what AtlaSent is and isn’t aligned with today.

​
At a glance

Security overview

Encryption in transit and at rest, identity and access controls, audit chain integrity, fail-closed guarantees.

Compliance status

Current frameworks (21 CFR Part 11, EU Annex 11, ALCOA+, GDPR), SOC 2 Type II roadmap, HIPAA BAA availability.

Sub-processors

Every third party that processes Customer Personal Data, with locations and transfer mechanisms. 30-day customer change notification for additions/replacements; 60-day notification for material changes in scope or location.

Legal documents

Terms of Service, Privacy Policy, DPA, BAA, MSA, AUP, SLA — current status and how to obtain each.

Reliability and SLO

Uptime targets, current status, RPO / RTO, incident history.

Security disclosure

Reporting a vulnerability, scope, response SLA. No bug bounty today.

Audit and assurance

Penetration testing status, SOC 2 progress, CAIQ pre-fill availability, customer audit rights.

Vendor qualification (VQP + Deltas)

Parent VQP plus the active Delta chain. Material changes between annual refreshes are issued as Delta VQPs (ADR-013, Accepted 2026-05-18) within five business days of the trigger event (operational target during the pre-pipeline period; see Vendor qualification chain for the contractual-status detail).

Government data requests

AtlaSent challenges overbroad government data requests and notifies affected Customers unless legally prohibited. See MSA §13.14 and DPA §7.7.

Contact

Security, compliance, privacy, and procurement contacts.
Note: AtlaSent’s immutable audit chain (available today, internal to AtlaSent) is distinct from portable signed evidence bundles (roadmap, externally verifiable offline). See Audit and evidence posture.

​
Audit and evidence posture

Two distinct trust surfaces. Procurement and Quality reviewers should not collapse them; the distinction is architectural and material.

Immutable audit chain — GA today

Hash-chained, append-only ledger of every authorization decision and every Console mutation. Permit tokens are bound into each entry by cryptographic reference. The chain is internal to AtlaSent and queryable in-place via the API. It provides event continuity, append-only integrity, and runtime evidence lineage. Customer verification today is API-mediated inspection of the chain. Available today. Cryptographic primitives are documented in DPA Annex II.1 (AtlaSent’s contractual representation).

Portable signed evidence bundles — roadmap

Detached, deterministic, Ed25519-signed packages assembled from the audit chain for portable offline verification by third-party auditors. Specification source is maintained in architecture/evidence-bundles-spec.md. This portal does not represent portable signed evidence bundles as GA until the corresponding customer-facing release and verification surface is published and the trust documentation is updated. They are not currently part of the Service committed under the MSA, DPA, or SLA, and AtlaSent does not warrant availability on a particular date.
The distinction will be preserved on this portal if and when the portable bundle surface reaches GA.

​
Vendor qualification chain

The parent VQP is the authoritative baseline; material changes between annual refreshes are issued as Delta VQPs bound to the parent commit (ADR-013, Accepted 2026-05-18). A customer’s current qualification is the parent VQP plus the applicable Delta chain.
  • Parent VQP: 2026-04-19 (V1 docs gate)
  • Delta chain: available on request from compliance@atlasent.io
  • Latest Delta recorded on this portal: 2026-05-20.01 — trust subdomain cutover (announces canonical URL trust.atlasent.io; URL surface change only, no capability change). Prior Delta: 2026-05-18.02 (signatory completion supersession-in-part of 2026-05-18.01).
  • Operational target. Deltas are targeted for issuance within five business days of a trigger event. Until the automated Delta VQP issuance pipeline is operational, this is an internal operational target rather than a contractual commitment unless expressly incorporated into an executed agreement.
Until the Delta VQP issuance pipeline is operational, Deltas are issued as commits to atlasent-docs/vqp/deltas/ and customer verification proceeds via commit SHA inspection against this repository. The portal does not represent the planned automated manifest, feed, or Console surfaces as currently available.

​
What buyers usually want first

Based on procurement conversations:
  1. CAIQ. Pre-fill is maintained in source control and updated quarterly. Email compliance@atlasent.io for the latest version.
  2. SOC 2 report. Not available yet. No audit firm is engaged and no audit period has started (see Compliance status and the claims matrix). When a report exists, the Type I report will be made available on this portal and the Type II report under NDA.
  3. DPA. Available on request from legal@atlasent.io. EU SCCs Module 2/3 and UK IDTA are incorporated.
  4. BAA. Currently “Not yet available — contact sales” per the claims matrix. The BAA status will not flip to “Available” until AtlaSent has designated a HIPAA Privacy Officer and Security Officer and operationally tested its breach-notification workflow, in line with 45 C.F.R. §§ 164.308(a)(2) and 164.530(a)(1)(i). Pilot customers requiring PHI should reach compliance@atlasent.io.
  5. Penetration test summary. No third-party penetration test has been completed yet. The first engagement is being scoped. When it is done, a summary will be available under NDA from security@atlasent.io.
  6. Sub-processor list. Public, with 30-day change notification for additions/replacements and 60-day notification for material changes in scope or location. See Sub-processors.

​
How we keep this portal honest

  • Last documentation review: 2026-08-21. This date records a customer-facing documentation review; it is not a security audit, certification, or independent assurance opinion.
  • The portal is re-reviewed when a material security, compliance, legal, or operational posture change requires the customer-facing record to change. No page should rely on an unresolved placeholder as the basis for a customer claim.
  • Compliance claims on this portal must match the canonical claims matrix, which is CI-gated against product copy.
  • Any change to the security posture (technical or organizational measures) requires a parallel update here before it goes live and a corresponding update to DPA Annex II.
  • Documents on this portal are versioned; historical versions are accessible at trust.atlasent.io/legal/archive/<doc>/<version>.