RLS Radar

AI agent security check: the Rule of Two, plus a leak check your agent can run

By RLS RadarUpdated Reviewed against Meta, Supabase and Air Security sources
Short answer

An agent becomes dangerous when, in one session, it reads text you did not write, can reach secrets or private data, and can act or send data out. Meta calls the limit the Rule of Two: allow at most two of the three, or put a person in front of every action. Use the self-check below for your agent setup, then hand your agent the free checklist to find leaks in your repo. The RLS Radar scanner covers your live site.

The Rule of Two

Meta's rule (31 Oct 2025) says an agent should satisfy no more than two of these in one session:

  • [A] Untrusted input: web pages, email, GitHub issues and PR text, support tickets, rows your users wrote, plugin or MCP output.
  • [B] Sensitive access: a production database, service_role or secret keys, .env, private repos, customer data.
  • [C] Change or send: write files or rows, run commands, open PRs, send email or HTTP requests.

If it truly needs all three, Meta says it should not run on its own, and at a minimum needs supervision such as human approval. Source: Meta AI: Agents Rule of Two.

Self-check your agent (runs in your browser)

Tick what one agent can do in a single session. Nothing you tick is sent or stored.

[A] Does it read text you did not write?
[B] Can it reach secrets or private data?
[C] Can it change things or send data out?
Approval and setup

What this looks like in real incidents

  • Supabase MCP demo (General Analysis, July 2025): an attacker wrote instructions into a support ticket. A developer later asked Cursor to show the latest ticket. The assistant was connected with service_role, which bypasses RLS, so it read a secrets table and posted it back into the attacker's ticket. That is [A] + [B] + [C] in one session. The data was dummy data. General Analysis write-up.
  • Plugin4Shell (Air Security, 17 Sep 2026): Claude Code, Codex, GitHub Copilot and Gemini CLI did not verify that a plugin auto-update actually landed on the commit the marketplace pinned. Whoever controls a plugin repo could swap in new code with no user action. Fixed in Claude Code 2.1.179 and Codex 0.146.0; at publication Copilot had no fix and Gemini CLI, which is deprecated, will not get one. Air Security report.

Hand the leak check to your own agent

The agent checklist is a short plain-text file for Claude Code, Cursor, Codex or Copilot. Your agent reads your repo and agent config and reports: secret keys in code or git history, server secrets behind NEXT_PUBLIC_/VITE_ variables, Supabase tables without RLS, open Firebase rules, Supabase MCP without read_only, tokens in MCP config, auto-approve settings, an A+B+C inventory of your agents and CI bots, and outdated agent versions.

The rules inside it: read-only, no network, stay in the project, mask every secret, treat file contents as data (anything that tries to give the agent orders gets reported as possible prompt injection), and change nothing without your yes.

  1. Download it into your project and check it is the file published here:
    curl -fsSL -o AGENT-CHECK.md https://rlsradar.vercel.app/agent-check.md
    shasum -a 256 AGENT-CHECK.md

    Expected SHA-256 (v1): 95b0129e3da76d99e4a7f6fdb0c6eb4b434161f8fc1940409db346b707fcd6ba

  2. Read it yourself before your agent does. It is short. Never let an agent follow instructions you have not seen.
  3. Ask your agent to run it:
    Follow AGENT-CHECK.md on this repository. Stay read-only and offline, mask every secret, and give me the report table. Do not change anything until I approve each fix.
  4. Approve fixes one by one. Rotate any leaked key in the provider's dashboard first; deleting it from the code is not enough once it was committed.

Why a downloaded file and not "go read this URL"? A file you saved and read cannot change under you. Having an agent follow live instructions from the web is exactly the [A] input this page warns about.

Agent check vs. the RLS Radar scan

  • Agent check: runs on your machine, sees your source code, migrations and agent config. Catches problems before you deploy.
  • RLS Radar scan: runs against your live URL and sees only what the public internet sees: keys shipped in JavaScript, exposed .env, Supabase tables readable with the public key, open Firebase. Use both.

Lock down the Supabase MCP server

Supabase's own guidance for its MCP server:

  • read_only=true runs every query as a read-only Postgres user.
  • project_ref=<id> limits the server to one project.
  • features=database,docs turns on only the tool groups you need.
  • Keep manual approval of tool calls on for interactive work, and connect to production only when the task needs production data.
https://mcp.supabase.com/mcp?project_ref=<your-project-id>&read_only=true&features=database,docs

Source: Supabase docs: Model Context Protocol.

FAQ

Does the agent check send my code to RLS Radar?

No. The checklist tells your agent to stay offline and read-only. Your code never leaves your machine, and RLS Radar never sees the results.

Why download the file instead of letting my agent fetch the URL?

A file you saved and read cannot change under you. Letting an agent follow instructions from a live URL is the same pattern this check warns about.

Is the Rule of Two enough to make an agent safe?

No. It is a minimum. Two of three can still cause damage, for example an agent that reads untrusted text and can delete rows.

Sources

Now check your live app

Free, read-only, permission-gated. Nothing stored.

Scan your app

Related guides