Trust & Security
Primitive handles email on behalf of AI agents, so authentication, data isolation, and message integrity are core to the product. This page describes the security practices in place today. It documents how the system works — it is not a claim of any third-party certification.
Authentication & access
Every endpoint that reads or modifies customer data (mail, domains, functions, and Primitive Memories) requires a bearer token, either an API key prefixed prim_ or an OAuth access token prefixed prim_oat_. Tokens are scoped to a single organization.
A deliberately public set of endpoints is unauthenticated: signup and CLI login, the credential-free send-mail demo, the public agent registry and template catalog, the docs question endpoint, service discovery, and health. Within the documented REST API these are marked security: [] in the OpenAPI spec, so that subset can be checked mechanically rather than taken on our word. A few public surfaces sit outside that document: a read-only GraphQL endpoint that serves synthetic sample data, the static SDL alongside it, and the machine-readable discovery manifests under /.well-known.
The boundary that matters for a vetting decision: no unauthenticated endpoint can read a customer's mailbox contents, domains, functions, or Primitive Memories. Those require an organization-scoped token, without exception.
Two public endpoints do touch stored records, deliberately, and are worth stating rather than glossing. The agent registry serves a directory projection: it returns only agents whose owners published them to a public registry and whose membership is approved, with owner-only fields such as organization and endpoint identifiers excluded. It is opt-in publication, not an exposed database. And zero-touch signup (POST /v1/agent/accounts) creates a new organization and provisions its managed inbox with no credential presented, which is how an agent onboards without a human in the loop. It is rate-limited, and it can only bring a brand-new tenant into existence; it cannot read or alter an existing one.
Primitive operates an OAuth 2.0 authorization server. Authorization-server metadata (RFC 8414) and protected-resource metadata (RFC 9728) are published at the conventional .well-known locations so an agent can discover how to authenticate without manual setup.
Tenant isolation
Every authenticated request is scoped to the organization that owns the token, and data belonging to one organization is isolated from every other. An agent can only read and act on the mail, domains, and functions that belong to its own account.
Email authentication
Outbound mail is signed and authenticated with managed DKIM, SPF, DMARC, and TLS-RPT, on both managed *.primitive.email subdomains and connected custom domains. Domain authentication records are generated and verified through the API, so an agent inherits production-grade deliverability without configuring DNS by hand.
Message integrity
Webhook deliveries are signed with HMAC-SHA256 so a receiver can verify authenticity before acting on an inbound message. Mutating API requests accept an Idempotency-Key header, so a retried send is de-duplicated and never produces a duplicate message. All traffic is served over HTTPS/TLS.
Data retention
Inbound message contents are retained until you delete them; Primitive does not auto-delete stored mail on a schedule. See the privacy policy for how data is collected, used, and deleted.
Responsible disclosure
Security reports are welcome. Our security.txt lists the current security contact, or email contact@corp.primitive.dev. Please report suspected vulnerabilities privately before any public disclosure.