Skip to content

Security & observability

Security model

How RunAIAgents protects secrets, isolates tenants, and locks down outbound calls and code execution.

2 min read

RunAIAgents is built for teams running agents against real credentials and real customer data. This page covers the security invariants that hold across the platform: secret handling, tenant isolation, audit logging, network egress, and sandboxing.

Secrets

Every secret in the system — connector credentials, BYOK provider keys, monitoring tokens — passes through a single AES-256-GCM crypto module. There is no second, ad-hoc encryption path.

Secret fields are never returned by the API. Once a credential or key is stored, API responses omit it entirely rather than masking or truncating it — there's no response shape from which a stored secret can be read back, even by the organization that owns it.

Multi-tenant isolation

Every agent, run, connector, and credential belongs to an organization. Every database query and mutation is scoped by organization, and every mutation is checked against the caller's role before it executes. Client-supplied IDs are never trusted as proof of ownership — access is always re-derived from the authenticated session and organization context.

Audit logs

Admin mutations write an audit log entry as part of the same operation. If the audit log write fails, the mutation is rolled back rather than left unrecorded.

Outbound network calls

Any tool that makes an outbound network call — api_call, MCP tool calls, and webhook delivery — goes through IP pinning: the connection is pinned to a pre-validated public IP before the request is sent, closing the DNS-rebinding window where a hostname resolves to something safe at check-time and something private at connect-time. Private, loopback, link-local, and cloud-metadata addresses are blocked.

Security headers

Every response carries a standard set of security headers and a Content-Security-Policy, applied consistently rather than per-route.

Sandboxed code execution

The code_execution tool runs untrusted model-generated code in isolated sandboxes, not on the host:

  • JavaScript runs in a QuickJS WASM isolate with no host filesystem, network, or process access, a 64MB memory cap, and a 5-second hard timeout.
  • Python runs via Pyodide (CPython compiled to WASM) inside a worker thread, with the JS FFI bridge stripped out — import js fails rather than reaching back into the host.

Guardrails

On top of the platform-level controls above, you can configure per-agent guardrails: allow/deny lists for tools and destinations, PII/secret output redaction (credit-card numbers via Luhn check, prefixed API tokens, SSNs, email addresses), prompt-injection defenses, and approval gates for destructive actions. See guardrails for how to configure them.

BYOC (bring your own cloud)

If you deploy to your own infrastructure over SSH, your data and compute stay in infrastructure you control. SSH private keys used for that connection are held in memory only for the duration of the deploy and cleared immediately after — they're never written to disk or logged.

Still stuck? We're happy to help.

Contact support
Security model · RunAIAgents · RunAIAgents