Your API returns "200 OK".
Your PostgreSQL query executes successfully.
Your monitoring dashboard shows no errors.
And you might have just exposed another customer's data.
That's what makes cross-tenant data leaks dangerous.
They don't always crash your application. They don't necessarily trigger database errors. Sometimes, the query works exactly as written.
The dangerous query
Imagine a multi-tenant SaaS application running:
SELECT * FROM invoices WHERE id = 4821;
The query is valid. PostgreSQL executes it.
But where is the tenant boundary?
If authorization depends entirely on application code, one missing check could expose another customer's invoice.
Now imagine this happening across hundreds of endpoints.
How many queries would you need to trust?
What if tenant isolation had another enforcement boundary?
That's the engineering problem behind Agata Proxima.
I built an open-source Rust proxy that sits between PostgreSQL clients and an existing PostgreSQL database.
Instead of blindly forwarding connections, the engine can:
- Verify signed tenant context during connection startup.
- Reject invalid, expired, or missing tenant credentials.
- Map verified tenant identities to PostgreSQL roles.
- Work alongside PostgreSQL grants and Row-Level Security.
- Produce operational metrics and local attestation records.
The goal isn't to replace PostgreSQL security.
It's to make tenant identity verification independent of individual application queries.
What happens when a tenant tries to cross the boundary?
A properly configured tenant-specific database role and RLS policy should prevent access to another tenant's protected records.
But that protection needs testing.
Test valid tenant access. Test cross-tenant access. Test expired credentials. Test missing context.
And test what happens when something fails.
Because a security feature that hasn't been tested against failure scenarios is still an assumption.
The trade-off nobody should ignore
Adding a proxy introduces another infrastructure component.
That means connection handling, latency, availability, operational complexity, and failure behavior all deserve scrutiny.
Those trade-offs matter just as much as the security benefits.
Explore the implementation
The Rust engine is open source:
https://github.com/Agata-Proxima/proxima-engine
Platform:
Here's my question for backend developers:
If your application accidentally removes a tenant filter tomorrow, what prevents PostgreSQL from returning another customer's records?
Your application code? RLS? Database roles? An independent enforcement layer?
I'd genuinely like to hear how you're solving this.
Top comments (1)
Here's what makes this problem interesting:
A cross-tenant data leak doesn't always look like an attack. Sometimes, it's just a perfectly valid SQL query missing one critical condition.
That's why I believe tenant isolation needs more than application-level checks.
With Agata Proxima, I'm exploring how verified tenant identities, PostgreSQL roles, and RLS can work together to create stronger security boundaries.
The Rust engine is open source, and I'd welcome technical feedback on the architecture.
💻 github.com/Agata-Proxima/proxima-e...
For developers building multi-tenant SaaS applications:
What's your last line of defense when an application-level tenant check fails?