MCP server for anomaly detection on Supabase

Anomaly detection on Supabase is useful, but it still helps to know what an unauthenticated stranger can already reach. Auth holes, open buckets, and loose RLS show up before fancy alerts. That first outside pass on vibe-coded apps is what https://rowly.me is for.

This is an interesting direction. I’d separate baseline security/posture checks from behavioural anomaly detection, otherwise the signal could get noisy very quickly.

Before the “agentic” layer, I’d detect deterministic issues such as:

* tables exposed without appropriate RLS;

* unusually permissive policy changes;

* public/open Storage buckets;

* auth configuration drift;

* spikes in failed authentication;

* unexpected use of privileged/service credentials;

* sudden schema or permission changes.

Then I’d add behavioural baselines for things like query volume, connection patterns, row/byte growth, auth activity and unusual access by role.

For the MCP interface specifically, I’d make it read-only by default, expose narrowly scoped tools instead of arbitrary SQL, avoid returning secrets/raw credentials to the model, and make every anomaly explainable: evidence, affected resource, confidence/severity and a suggested remediation.

A useful feature could be an “investigation bundle” for each alert: what changed, when it changed, which role/user was involved, relevant policy/configuration state and the smallest safe diagnostic query. That would make the server much more useful for agents without turning the agent itself into a privileged database operator.

Other features I’d consider later: RLS/policy drift, schema drift, bucket exposure changes, anomaly suppression/baselining, Slack/webhook alerts and an audit timeline.

The main thing I’d optimise for is: high-confidence, actionable anomalies before adding lots of sophisticated detections.