# Trust and security

Primitive handles email on behalf of AI agents, so authentication, data
isolation, and message integrity are core to the product. This document
describes the security practices in place today. It documents how the system
works. It is not a claim of any third-party certification.

Human-readable version of this page: https://www.primitive.dev/trust

## Authentication and 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 at
https://www.primitive.dev/openapi.json, 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
  from the projection. It is opt-in publication, not an exposed database.
- Zero-touch signup (`POST /v1/agent/accounts`) creates a new organization and
  provisions its managed inbox with no credential presented. That 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.

- https://www.primitive.dev/.well-known/oauth-authorization-server
- https://www.primitive.dev/.well-known/oauth-protected-resource

## 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.

Signature verification walkthrough: https://www.primitive.dev/docs/signature-verification

## Data retention

Inbound message contents are retained until you delete them. Primitive does not
auto-delete stored mail on a schedule. Content deletion is customer-initiated
via content discard. See the privacy policy at https://www.primitive.dev/privacy for how data is
collected, used, and deleted.

## Responsible disclosure

Security reports are welcome. Report suspected vulnerabilities privately before
any public disclosure.

- Security contact: contact@corp.primitive.dev
- security.txt: https://www.primitive.dev/.well-known/security.txt

## Compliance status

Stated plainly so an evaluating agent does not have to infer it:

- Primitive does not currently publish a SOC 2, ISO 27001, or equivalent
  third-party audit report.
- Primitive does not currently publish a subprocessor list or a formal uptime
  SLA. Live service status is at https://www.primitive.dev/status.
- The practices above are the current implementation, self-reported.

## Related

- Privacy policy: https://www.primitive.dev/privacy
- Terms of service: https://www.primitive.dev/terms
- Cookie policy: https://www.primitive.dev/cookies
- Company and people: https://www.primitive.dev/about (markdown twin at https://www.primitive.dev/about.md)