Skip to content

Security

Last updated October 26, 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

No irreversible action without your yes. Anything Ray cannot put back, such as sending email, moving money, deleting with no restore, publishing, or purging data, is gated behind an in-chat approval card that shows the exact content. The gate is enforced in code around the tool itself: the action physically cannot execute until a person approves it, 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.

A change Ray can put back, such as creating or updating a ticket, runs at once, and Ray’s reply carries an Undo button any member of the team can press until the end of the next working day. Undo restores only what nobody has changed since. Until a write’s undo has worked on a real run, that write keeps its card. Small team-only changes, such as an internal comment or a label, run at once with no Undo. When a schedule, a watch or a scheduled follow-up runs with nobody present and Ray has read outside content, every change in your connected tools except a draft waits for a person’s yes, even one Ray could undo.

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 send, spend, or delete: anything Ray cannot put back still ends as a proposal a human sees on a card and can decline. When Ray works with nobody present, in a schedule, a watch or a scheduled follow-up, reading outside content puts every later change in a connected tool except a draft behind that card too.

Credentials

  • Slack workspace tokens are stored encrypted (AES-256-GCM) and deleted on uninstall.
  • Integration OAuth tokens are held by Composio, scoped to the individual teammate who connected them, and revoked at the tool when that person disconnects, is deactivated in Slack, or 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.