Your RLS policies now apply to AI agents (Gateway 0.2.10)

Most teams adding agents to a product already have row-level security in Postgres. Until now an agent’s writes went around it: the gateway wrote back as its own role.

0.2.10 fixes that. Start a run with act_as, and its changes are written back as your end user’s role, with their JWT claims:

{"tenant": 42, "act_as": {"role": "authenticated", "settings": {"request.jwt.claims": {"sub": "u-17"}}}}

Postgres then judges the agent’s insert, update or delete exactly as it would the user’s own. A row the policy hides or refuses stops the whole merge, and nothing is written. Superuser and BYPASSRLS roles are refused.

One-time setup: GRANT authenticated TO <the role the gateway connects as>;

Everything else stays the same: one customer’s rows per run, no Postgres credential given to the agent, every row checked on write-back, and the customer approves what breaks a rule. Merges also take fewer round trips now.

Self-hosted: Docker, Linux service or Helm, every release signed. Tested on Postgres 12–18, Supabase and Neon.

If you run Supabase-style RLS, does writing as the user’s role match how you’d want an agent to behave?

1 view

Add a comment

Replies

Be the first to reply

Have a question or a thought to share? Add a comment above to start the conversation.