The trust boundary is the product.
Most email vendors ask you to route your mail through their servers and trust a policy document. Wraps deploys infrastructure into your AWS account and reads it across a role you create, own, and can delete. The security story is mostly architecture, so this page describes the architecture rather than listing adjectives.
It also says plainly what we do not have. As of August 28, 2026 that includes SOC 2.
How Wraps reaches your AWS account
There is exactly one path, and it does not involve a credential you hand us.
- 1
You create the role, with your own credentials
Running
wraps platform connectuses the AWS credentials already on your machine to create an IAM role namedwraps-console-access-rolein your account. Wraps never holds a credential capable of doing this itself. - 2
The trust policy names one account and one secret
The role's trust policy allows
sts:AssumeRolefrom the Wraps platform AWS account905130073023, gated on ansts:ExternalIdcondition. That external ID is generated per connection, so possession of your account ID alone is not enough to assume the role — this is the standard mitigation for the confused-deputy problem. - 3
Every call uses a short-lived credential
The dashboard assumes the role through STS and receives temporary credentials that expire on their own. No AWS access key or secret key of yours is ever transmitted to or stored by Wraps. For Vercel-hosted sending we use OIDC federation, which likewise issues short-lived credentials rather than storing a key.
- 4
The permissions are namespaced, not account-wide
Data-plane permissions are scoped by ARN to resources Wraps deployed —
arn:aws:dynamodb:*:*:table/wraps-email-*,arn:aws:sqs:*:*:wraps-email-*,arn:aws:events:*:*:event-bus/wraps-email-*. Statements are added only for the features you actually enable: no event tracking, no DynamoDB statement. - 5
You revoke it by deleting it
Delete the role — or just the external ID condition's trust — and Wraps loses access immediately, with no ticket and no waiting on us. Your infrastructure keeps running and your mail keeps sending, because none of it depends on Wraps being reachable.
You do not have to take any of this on faith. The policy document is generated by packages/cli/src/commands/platform/connect.ts and the CLI prints it before it creates anything. Read it, diff it against what lands in IAM, and refuse it if they disagree.
What that role can and cannot do
The exact statement list depends on which services you deployed. This is the shape of the maximum.
Can
- Read SES account state: sending statistics, identities, verification status, configuration sets
- Read and write SES templates and, when you enable sending, call SES SendEmail on your behalf
- Read and write DynamoDB tables named wraps-email-* — the event history we deployed
- Read and write SQS queues named wraps-email-* and put events on wraps-email-* event buses
- Read AWS End User Messaging configuration when you deploy the SMS service
Cannot
- Read any DynamoDB table, S3 bucket, or queue that is not namespaced wraps-email-* or wraps-sms-*
- Read your application database, source code, or secrets
- Create, modify, or delete IAM users, roles, or policies
- Modify SES resources that Wraps did not create — existing identities and configuration sets are untouched
- Access your account with anything other than a temporary credential issued through STS
Where every category of data lives
"Your data stays in your account" is true of the sending path and the raw event stream. It is not true of everything — the platform features need a database, and that database is ours. Here is the line.
| Data | Where it lives | Retention |
|---|---|---|
| The emails themselves — content, recipients, headers | Your AWS account (SES) | You decide |
| Raw delivery events (send, delivery, bounce, complaint, open, click) | Your AWS account (DynamoDB, EventBridge, SQS) | You decide |
| Account, organization, and session records | Neon Postgres, United StatesWraps holds this | While your account is active |
| Contacts, audiences, templates, and the send ledger | Neon Postgres, United StatesWraps holds this | While your account is active; deleted on request |
| Recipient engagement metadata (open/click user agent) | Neon Postgres, United StatesWraps holds this | With the send ledger row it belongs to |
| AWS access keys and secret keys | Nowhere | Never stored, at any point |
| CLI telemetry (anonymous, opt-out) | PostHog Cloud, United StatesWraps holds this | 90 days |
| Server logs | Vercel, United StatesWraps holds this | 7 days |
Data in transit is encrypted with HTTPS/TLS on every external connection. Platform data is scoped to your organization and is never combined with another customer's. Full detail, including your deletion and export rights, is in the privacy policy.
Certifications: what we have and what we don't
Wraps is a small company. Claiming an audit we have not completed would be the single fastest way to lose the trust this page is trying to earn, so the list below is blunt.
SOC 2 Type II
Not certified and not currently in an audit window. If you need one to buy, tell us — it moves up the roadmap when a real customer needs it.
ISO 27001
Not certified.
HIPAA BAA
We do not sign BAAs. Do not send protected health information through the Wraps platform layer.
GDPR — data processing agreement
We act as your processor for platform data. Standard terms are published at /dpa.
Penetration test report
No third-party pen test has been commissioned. The entire codebase is public instead — see below.
Source code auditable by you
Wraps is AGPLv3. Every IAM policy, every deployed resource, and the telemetry implementation are readable in the public repository.
Operational practices
Access control
Production access is limited to the engineers who need it. Authentication to the dashboard supports SSO and SCIM provisioning on the Scale plan.
Tenant isolation
Every query against platform data is scoped by organization. This is enforced in code and checked by an automated architecture test that fails the build on an unscoped query.
Dependency hygiene
Dependencies are reviewed weekly and CVE scans run daily against the repository. Findings are tracked publicly as issues.
Subprocessors
Six, all named, with what each one receives. We commit to notifying customers before adding one that processes personal data.
Incident response
If we become aware of a breach affecting your personal data we will notify you without undue delay and within 72 hours of becoming aware, with what we know at the time.
Reporting a vulnerability
Email security@wraps.dev. We will acknowledge within two business days. Please give us a reasonable window to fix before disclosing; we will not pursue researchers acting in good faith.
Reviewing Wraps for your team?
The subprocessor list and the data processing agreement are published, not gated behind a sales call. If your review needs something that is not here, ask and we will either answer it or tell you we cannot.
Last updated August 28, 2026. Wraps is a product of FlatironKids LLC, registered in Colorado, United States.