Security

Last updated July 18, 2026

Ray acts inside real workspaces, on real tools, with real consequences. Its security model is built around one idea: the blast radius of anything going wrong — a model mistake, a malicious message, a compromised input — must be capped by structure, not by hoping the AI behaves.

Human approval is structural

Consequential actions — creating or changing tickets, sending email, purging data — are gated behind an in-chat approval card. The gate is enforced in code around the tool itself: the action physically cannot execute until a person clicks Approve, and a retried run can never perform it twice. No phrasing, prompt trick, or injected instruction can talk Ray past it, because it isn’t a promise the model makes — it’s a wall the code puts up.

Workspaces are isolated at the database

Every stored row is scoped to your workspace, enforced by Postgres row-level security in its strictest mode on every table, with a runtime database role that cannot bypass it. Application bugs aren’t trusted either: our test suite includes cross-tenant attack tests that try to read and write across workspace boundaries through every code path — recall, search, writes, purges — and prove the database refuses even when the application layer is deliberately miswired.

Untrusted content is data, not instructions

Everything Ray reads from the outside — channel history, tracker payloads, web search results, email — is framed to the model as content to reason about, never as instructions to follow, with explicit boundaries that our eval suite continuously red-teams with seeded injection attacks. And because approvals are structural, even a successful injection can’t make Ray perform a gated action: the worst a hostile message can do is propose something a human then sees on a card and declines.

Credentials

• Slack workspace tokens are stored encrypted (AES-256-GCM) and deleted on uninstall.
• Integration OAuth tokens are held by Composio, scoped per workspace, and revoked when you uninstall.
• Secrets and tokens are never placed in model context — the model cannot leak what it never sees.
• Every inbound webhook is signature-verified before anything is processed or logged.

Abuse and runaway-cost controls

Every workspace runs under per-org daily task ceilings, loop bounds on agent runs, per-org concurrency fairness, and global and per-org kill switches that halt processing instantly. Failed or looping work never counts against you or bills you.

Observability without content

Product analytics carry metadata only — tokens, cost, latency, model and feature names — never message content. Operational debugging snapshots are retained on our task infrastructure for at most 30 days (see the Privacy Policy for the full retention picture).

Where we are

We’re a small team and we don’t wave certifications we don’t hold: there is no SOC 2 report today. What this page describes is the actual, shipped posture — structural approval gates, forced row-level security with adversarial tests, encrypted credentials, capped spend — and it will stay accurate as the product grows.

Reporting a vulnerability

If you’ve found a security issue, email support@heyray.io — we read those first and reply.