AI App Builder Audits · AI Development Series
Retool App Audit
Retool is the most widely used internal tool platform there is. It also tends to have the broadest database permissions of anything you run.
What Retool actually hands you
Retool is the established leader in internal tooling, and for good reason: building admin panels by hand is slow, expensive work that does nothing for your competitive position. Using it is usually a sound commercial decision.
What a Retool application is made of
- Interface React components, assembled visually
- Data sources Your own Postgres, MySQL, MongoDB, REST or GraphQL
- Queries SQL and API calls defined in the platform
- Logic JavaScript transformers and event handlers
- Access Role-based permissions, plus optional SSO
- Hosting Retool cloud, or self-hosted on your infrastructure
The risk profile is not about generated code quality. It is that you have given a tool a live, privileged connection to production and then let people build things with it — often people who are not developers, and often without review.
Because the database is yours and was designed properly, the schema problems that dominate app-generator audits usually do not apply. What replaces them is a narrower, sharper set of questions about the query layer, the permission model and what happens when someone makes a mistake.
What we consistently find
These are the recurring issues in internal tools built on a production database.
One database identity for every user
Retool connects using a single set of credentials, usually generous ones. Every query every user runs reaches the database wearing that same identity.
Your database therefore cannot enforce anything per person, cannot restrict rows by team or region, and its audit log shows one account doing everything. All the access control has moved up into Retool, which is a thinner place to keep it.
What it costs you: your database's own protections switched off, with everything resting on the layer above.Permissions that hide controls rather than block queries
A viewer does not see the delete button, so a viewer cannot delete. That is how it appears and how it is normally tested.
The question is whether the underlying query is still reachable by someone signed in who knows it exists. If the restriction is only that a control is not rendered, it is a courtesy rather than a boundary — and internal tools are exactly where the sensitive bulk actions live.
What it costs you: staff or a compromised account reaching actions they were never granted.Queries built by joining strings together
Search boxes, filters and dynamic sorting are the core of an internal tool, and the fastest way to build them is to drop the user's input straight into the query text.
That means someone typing the right thing into a filter can change what the query does. Parameterised queries fix it completely and the platform supports them; the concatenated version is simply quicker to get working.
What it costs you: SQL injection, from inside your own admin tool, against production.Irreversible actions with no record
Internal tools exist to change things, so they get write access. What is usually missing is everything around it: no confirmation on destructive actions, no soft deletes, no record of who changed what, and no way back when somebody updates two thousand rows because a filter was not applied.
Most of the damage we have seen from internal tools was done by an authorised person doing something reasonable that turned out to be wrong.
What it costs you: a bad afternoon becoming a restore from backup, assuming the backup is good.Where Retool is genuinely good
We think this category is underrated and Retool is the strongest example of it. Spending months of developer time building an admin panel delivers no competitive advantage whatsoever, and not doing that is usually the right call.
Genuinely well suited to
- Admin panels and back-office tools over a database you own
- Giving non-technical staff structured access to data
- Operational dashboards and internal reporting
- Replacing spreadsheets and direct database access, which are worse
- Work that needs doing but does not differentiate your business
Where it needs engineering behind it
- Anything customer-facing or reachable from outside the organisation
- Tools performing bulk or irreversible actions on live data
- Regulated processes needing a defensible audit trail
- Logic complex enough to deserve review, tests and version control
- Anything the business genuinely could not operate without
The honest summary: Using Retool for internal tooling is usually correct. The mistake is treating it as though the normal rules stopped applying because it is internal, because it is only staff, or because it was quick to build. It is still software with a privileged connection to production.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- It can write to, or delete from, your production database
- More than a handful of people use it, at different levels
- It touches personal data, payroll, pricing or payments
- You operate under rules requiring an audit trail
- The person who built it has left, or is about to
You are probably fine if
- It is read-only over data nobody would mind seeing
- One or two trusted people use it
- It is a dashboard rather than a tool that changes things
- Everything it touches is easy to reconstruct
Questions about auditing a Retool build
The usual weakness is that Retool connects to your database as a single identity with broad rights, and every user's queries run as that identity. Retool then hides the controls a user should not have, which changes the interface without changing what the query can do.
Retool is a mature product used by large engineering teams and a legitimate way to build internal tools. The risk is not the platform. It is that Retool connects directly to production data, so a permission gap in Retool is a permission gap in your database.
Only at the interface. Hiding a button stops it being clicked, but if the underlying query is still available to that user it can be run. Access control has to be enforced by the database or the API, not by which components are displayed.
Frequently, yes. Where one connection serves everybody, the limit on what a user can reach is whatever the interface chooses to show them. Anyone able to modify a query, or reach a resource another way, is not bound by that limit.
It is common and it can be done safely, but not with a single widely privileged connection. The connection should be scoped to exactly what the tools need, and read-only wherever writes are not required, so a mistake in Retool cannot become a mistake in production data.
The two things reviewers ask for are usually the two things missing: access enforced below the interface, and a record of who changed what. Retool can satisfy both, but neither happens by default, and internal tools rarely get looked at until an auditor asks.
Most of it is connection scoping and query permissions, which is configuration rather than rebuilding. Adding a proper audit trail is the piece most often missing. The audit is £495 + VAT and tells you what to change and in what order. Credited back in full against the work.
That depends less on who uses it than on what it can do. Internal tools usually have broader database permissions than anything customer-facing, so the damage from a mistake or a compromised account is larger rather than smaller. If it only reads data that would not matter if it leaked, you are probably fine. If it can change or delete things, being internal is a reason to look more carefully rather than less.
Usually not. Building admin panels by hand is expensive and does nothing for your competitive position. Most of what we find is fixable inside the platform: parameterise the queries, narrow the database user's permissions, move permission checks somewhere they cannot be bypassed, add an audit trail. We only suggest building properly when the tool has quietly become business-critical and the platform cannot support what it now has to do.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not Retool expertise, it is that the thing being audited is SQL, a permission model and a production database, which is what we have been working with since 2008.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Emergent app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what you built and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- The query layer, including how user input reaches your database
- Whether your permission model is enforced or merely displayed
- What the tool can do to production data, and what is recorded
- The database credentials it connects with, and how broad they are
We reply within one working day.
