Abundly is built on enterprise-grade cloud infrastructure with security and compliance at its foundation. All data is stored in EU data centers, encrypted at rest and in transit, and protected by comprehensive access controls. This page provides the technical details enterprise security teams need.Documentation Index
Fetch the complete documentation index at: https://docs.abundly.ai/llms.txt
Use this file to discover all available pages before exploring further.
Data residency
All customer data is stored in EU data centers, specifically in Stockholm, Sweden:| Component | Location |
|---|---|
| Database | AWS eu-north-1 (Stockholm) |
| Agent Service | GCP europe-north2 (Stockholm) |
| File Storage | GCP europe-north2 (Stockholm) |
| Task Queue | GCP europe-north2 (Stockholm) |
EU data residency ensures compliance with GDPR and other European data protection regulations. Data does not leave the EU.
Encryption
| Type | Standard |
|---|---|
| At rest | AES-256 encryption for all stored data |
| In transit | TLS 1.2+ / HTTPS for all communication |
| Secrets | RSA-OAEP with SHA-256 (see Credentials) |
Web and API transport hardening
In addition to TLS encryption, Abundly uses security headers across the web portal and API surfaces to reduce browser-based attack risk.| Surface | Header strategy | Security goal |
|---|---|---|
| Web portal | Strict browser headers including Content Security Policy (CSP), frame protections, permissions policy, referrer policy, and MIME-type protections | Reduce XSS and clickjacking risk, restrict browser features, and limit data leakage |
| User app renderer | Served from a separate usercontent subdomain with its own CSP profile that allows the embedding and external assets needed by user-generated apps | Isolate untrusted user-generated content from the main app via cross-origin sandboxing |
| Agent service API | API-focused hardening headers (HSTS and related Helmet protections) for non-HTML responses | Enforce HTTPS and protect API consumers from common browser-side header attacks |
CSP is applied on web responses where script and content execution rules matter. API endpoints focus on transport and response hardening headers.
User-generated content isolation
Interactive Apps and HTML documents created by agents can contain arbitrary code. To prevent this code from accessing the main application or its session, the platform serves all rendered user content from a dedicatedusercontent.abundly.ai subdomain that is separate from the main app.abundly.ai domain.
Because the browser treats these as different origins, code running inside an embedded app is fully sandboxed by the browser’s same-origin policy: it cannot read cookies, local storage, or the DOM of the main app, even when displayed inside it. The main app domain refuses to serve the renderer, and the usercontent domain refuses to serve anything else, so the boundary cannot be bypassed by linking or redirecting.
Compliance status
| Standard | Status | Notes |
|---|---|---|
| GDPR | Compliant | EU data residency in Stockholm |
| Data Encryption | Met | AES-256 at rest, TLS 1.2+ in transit |
| Access Controls | Comprehensive | Role-based permissions |
| SOC 2 Type II | Planned | Certification in progress |
| ISO 27001 | Evaluation | Under consideration |
Audit trails
Every agent action is logged with complete context:| Field | Description |
|---|---|
| Timestamp | When the action occurred |
| Actor | Which agent performed the action |
| Trigger | What initiated the action (email, schedule, chat, etc.) |
| Plan | What the agent intended to do |
| Execution | What tools were called and what happened |
| Result | The outcome of the action |
Audit logs are immutable and cannot be modified or deleted after creation.
- Activity log — Real-time and historical view of agent actions with full details
- Agent diary — High-level summary of what each agent has been doing
Data retention
| Data Type | Retention |
|---|---|
| Account Information | While account active; deleted within 30 days of account deletion |
| User Content | Retained to provide services; deleted within 30 days after deletion |
| Log Data | Up to 90 days for security and troubleshooting |
| Usage Data | Anonymized data may be retained for analytics |
| Backups | Data may remain in backups up to 9 months |
System architecture
The platform is built on cloud-native infrastructure:| Component | Technology | Location |
|---|---|---|
| Web Portal | Vercel, Next.js/React | Vercel Edge Network |
| Agent Service | Google Cloud Run, Node.js | GCP europe-north2 |
| Database | MongoDB Atlas | AWS eu-north-1 |
| Task Queue | Google Cloud Tasks | GCP europe-north2 |
| File Storage | Google Cloud Storage | GCP europe-north2 |
Availability and disaster recovery
| Feature | Implementation |
|---|---|
| Cloud-native resilience | Automatic failover via Vercel and GCP |
| Automated backups | Daily with point-in-time recovery |
| Backup retention | 9 months with cross-region replication |
| Health monitoring | Continuous monitoring with alerting |
| RTO (Recovery Time) | 24 hours for critical services |
Security monitoring
| Activity | Approach |
|---|---|
| Infrastructure monitoring | Automated via GCP, MongoDB Atlas, Vercel |
| Alert configuration | Email notifications to technical team |
| Active monitoring | Daily dashboard review |
| Incident response | Critical alerts within 1 hour (business hours) |
| Penetration testing | Annual third-party testing |
Legal documentation
Privacy Policy
How we collect and use data
Terms of Service
Service agreement and terms
Data Processing Agreement
DPA for enterprise customers
Sub-processors
List of third-party data processors
Enterprise compliance
For enterprise customers, we can provide:- Custom data retention policies
- Dedicated compliance documentation
- Audit support and reports
- Custom DPA terms
Contact Us
Need custom compliance arrangements? Contact our team.