Agents your security team can sign off on
RunAIAgents was built privacy-first: your cloud, your keys, your data residency, and a complete audit trail for every run. Below is exactly what's implemented today, grouped so both a founder and a security reviewer can find what they need.
Your data, encrypted, and your keys stay yours
For non-technical reviewers: we never store your model provider credentials in plain text, and if you bring your own cloud, your agent's inputs and outputs never touch our servers.
Bring your own cloud (BYOC)
Deploy agents into your own server. Inputs and outputs stay in your infrastructure — for BYOC we store only run metadata (duration, cost, status), never payload content.
Bring your own keys (BYOK)
Your model and OAuth credentials are encrypted with AES-256-GCM and used only at runtime. We never proxy, log, or retain your provider tokens.
One audited encryption module
Every stored credential — API keys, OAuth tokens, connector secrets — passes through a single AES-256-GCM module (apps/web/lib/encryption.ts). No inline or ad-hoc crypto anywhere else in the codebase.
Right to delete & export
Delete your account and all associated data in a single cascade, or export everything as JSON, on your own timeline.
Least privilege, enforced at every layer
Roles gate what a teammate can do; multi-factor auth gates who can do it; and every sensitive action leaves a record.
Role-based access control
Every workspace action is scoped to an organization and a role — Viewer, Editor, or Owner. Client-supplied IDs are never trusted for ownership; the server re-checks the caller's role on every request.
Multi-factor authentication
Add a TOTP authenticator or a hardware/passkey (WebAuthn) as a second factor, plus one-time recovery codes if you lose access to both. Once enrolled, sensitive actions — key rotation, billing changes, data export, viewing the audit log — require a fresh MFA step-up (AAL2), even on an already-signed-in session.
Exportable audit logs
Every security-relevant event — sign-ins, key rotations, team changes, deployments, integrations — is written to an immutable, organization-scoped trail. Workspace owners can filter and view it in-app, or export it as CSV for compliance evidence.
Consent-based monitoring
The optional monitoring sidecar reports only what you opt into, enforced server-side by the token that identifies it — we don't trust a client's claim about its own consent level.
A runtime built to contain what it executes
Agents call the outside world and run generated code on your behalf — the isolation model is the difference between a demo and something a security team can sign off on.
Sandboxed code execution
JavaScript runs inside a QuickJS WebAssembly isolate — no host filesystem, network, or process access, with a 64MB memory ceiling and a 5-second hard timeout. Python runs on Pyodide (CPython-WASM) in a disposable worker thread, spawned fresh per call, with the JS/host FFI bridge stripped before user code runs.
SSRF-pinned outbound calls
Every outbound connection — an API-call tool, an MCP server, a webhook delivery — resolves and validates its destination once, then connects to that exact IP. The DNS record is never re-resolved at connect time, closing the DNS-rebinding race that lets a hostname pass validation and then redirect to an internal address.
Rate limiting on every surface
Chat, agent runs, webhooks, public agent embeds, and audit exports are all rate-limited server-side via Redis (rate-limiter-flexible) — abuse on one workspace can't degrade another's.
Security headers on every response
Strict-Transport-Security (HSTS, 2-year max-age with preload), a tuned Content-Security-Policy, X-Frame-Options, X-Content-Type-Options: nosniff, and Referrer-Policy are set by middleware on every response, not opt-in per route.
Verified webhook & OAuth signatures
Inbound webhooks and OAuth callbacks are verified with constant-time comparison (timingSafeEqual) rather than a plain string match, closing the timing side-channel that a naive comparison leaves open.
Where we are, stated plainly
We'd rather tell you exactly what's done and what's in progress than round up. See the full breakdown on the Trust Center.
SOC 2 Type II — in progress, not yet certified
We are actively building out our SOC 2 program against the underlying controls (encryption, access control, monitoring, audit logging) that are already live in the product. We do not claim certification until an auditor has issued a report.
GDPR & Data Processing Addendum
A DPA is available to execute as part of your agreement, covering our commitments as a processor: encryption of stored credentials, role-based access control, and assistance with data-subject requests and breach notification.
Subprocessors, listed
Every third party that touches customer data to help us run the service — hosting, database, email, payments, error monitoring, LLM inference — is listed with its purpose and the data it processes.
Data residency / GCC
Run in the region and account you choose. Built with regulated and GCC (UAE, Saudi) deployments as a first-class case, not an afterthought.
Found something? We want to hear about it
Good-faith security research is welcome, with a documented safe harbor.
security.txt (RFC 9116)
Machine-readable contact and policy info at /.well-known/security.txt, so researchers and scanners find the right channel automatically.
Safe harbor policy
We will not pursue legal action against researchers who test in good faith, avoid privacy violations and service disruption, and report the issue before any public disclosure.
Hall of Fame
Researchers who responsibly disclose a valid, previously-unknown issue are credited publicly (or stay anonymous, their choice).
Sending this to a security or procurement team?
The Trust Center is a one-page summary built for exactly that: the controls above, our SOC 2 readiness checklist, and every legal document in one place. Enterprise SSO (SAML / OIDC) is available on request, and we’re happy to share data-flow documentation under NDA.
Found a vulnerability? See our security.txt or email [email protected].