Security and Privacy
AgentPost's security model, data privacy practices, and responsible disclosure policy
Security and Privacy
AgentPost is designed to handle sensitive email data securely. As a self-hosted platform, you maintain full control over your data and infrastructure. This page documents our security model, privacy practices, and how to report vulnerabilities.
Authentication
API Key Authentication
All API requests require authentication via API keys:
- Keys use the prefix
ap_sk_for identification - Keys are hashed with SHA-256 before storage -- the full key is shown only at creation time
- Keys can be scoped to specific permissions (e.g.,
inboxes:read,messages:write) - Keys can be restricted to specific environments
- Keys can have an expiration date for automatic rotation
- Revoked keys are immediately rejected on all subsequent requests
User Authentication
The web console uses JWT-based authentication:
- Access tokens expire after 15 minutes
- Refresh tokens use rotation -- each refresh issues a new token pair and invalidates the old one
- Multi-factor authentication (TOTP and WebAuthn) supported for additional security
- SSO via OIDC and SAML for enterprise identity provider integration
- Password hashing uses bcrypt with a cost factor of 12
Role-Based Access Control
AgentPost enforces role-based access at multiple levels:
| Level | Roles | Controls |
|---|---|---|
| Organization | Owner, Admin, Member | Resource management, billing, settings |
| Environment | Admin, Member | Access to environment-scoped resources |
| API Key | Custom scopes | Fine-grained API permission control |
Encryption
In Transit
All data transmitted between clients and AgentPost is encrypted with TLS:
- API server enforces HTTPS for all endpoints
- WebSocket connections use WSS (WebSocket over TLS)
- SMTP and IMAP protocol servers support STARTTLS
- Internal service communication between AgentPost and AWS SES uses TLS
At Rest
- Database -- PostgreSQL supports Transparent Data Encryption (TDE) at the storage level. Enable it through your PostgreSQL configuration.
- Attachments -- Stored in Cloudflare R2 (or S3-compatible storage) with server-side encryption enabled
- Sensitive fields -- OIDC client secrets are encrypted with AES-256-GCM at the application level before database storage
- API keys -- Stored as SHA-256 hashes, never in plaintext
Data Isolation
Organization Isolation
Each organization's data is logically isolated:
- All database queries include
org_idfiltering - API keys are scoped to a single organization
- Cross-organization data access is impossible through the API
- Admin API operates separately with its own authentication (admin keys)
Environment Isolation
Within an organization, environments provide additional isolation:
- Resources (inboxes, messages, domains) belong to exactly one environment
- API keys can be restricted to specific environments
- Members can be assigned to specific environments
- Cross-environment access is blocked by the environment access middleware
Email Content Storage
AgentPost stores email content in PostgreSQL:
| Data | Storage | Retention |
|---|---|---|
| Message headers | PostgreSQL | Until message is deleted |
| Message body | PostgreSQL | Until message is deleted |
| Attachments | R2/S3 object storage | Until message is deleted |
| Delivery events | PostgreSQL | Configurable (default: 90 days) |
| Audit logs | PostgreSQL | Tier-based (7 days to 2 years) |
Self-Hosted Advantage
Because AgentPost is self-hosted, your email data never leaves your infrastructure:
- No third-party data access -- AgentPost (the project) has no access to your deployment
- Your compliance, your rules -- Configure retention, encryption, and access policies to meet your regulatory requirements
- Geographic control -- Deploy in the region(s) that meet your data residency requirements
- Full audit trail -- All API access is logged with actor, action, and timestamp
Infrastructure Security
Recommended Deployment Practices
- Run behind a reverse proxy (nginx, Caddy) that handles TLS termination
- Use a firewall to restrict database access to the API server only
- Enable PostgreSQL SSL connections
- Store secrets in environment variables or a secrets manager (HashiCorp Vault)
- Run as a non-root user in Docker containers
- Keep Node.js and all dependencies updated
AWS SES Security
- SES credentials should use IAM roles with minimum required permissions
- Use separate SES identities for production and development
- Enable SES event publishing to SNS for delivery tracking
- Monitor SES sending quotas and reputation metrics
Responsible Disclosure
If you discover a security vulnerability in AgentPost, please report it responsibly:
- Email [email protected] with details of the vulnerability
- Do not disclose the vulnerability publicly until we have issued a fix
- Include steps to reproduce, potential impact, and suggested fix (if any)
Our Commitment
- Acknowledgment within 48 hours of your report
- Assessment and severity classification within 5 business days
- Fix timeline communicated within 10 business days
- Credit in the security advisory (unless you prefer anonymity)
We do not pursue legal action against security researchers who:
- Act in good faith
- Do not access, modify, or delete data belonging to others
- Do not disrupt the service for other users
- Report the vulnerability before publicly disclosing it
Security Headers
The AgentPost API sets the following security headers:
| Header | Value | Purpose |
|---|---|---|
X-Content-Type-Options | nosniff | Prevents MIME type sniffing |
X-Frame-Options | DENY | Prevents clickjacking |
Strict-Transport-Security | max-age=31536000 | Enforces HTTPS |
Content-Security-Policy | Restrictive policy | Prevents XSS and injection |
Questions
For security-related questions that are not vulnerability reports, ask in the Discord #security channel or open a GitHub Discussion.