Who Approved That Refund? Governing AI-Built Apps at Work
How Superblocks adds permissions, SSO, security scans and audit logs to AI-built internal apps, using a CRM refund workflow as a case study.
What happens after the AI-built app actually works?
An employee uses an AI tool to build an internal app, it works, and they share it with coworkers. The problem shows up later: nobody defined who can see what, who can approve what, or where the record of a decision lives. Superblocks addresses this by wrapping AI-generated apps in the same controls IT already expects from internal software: single sign-on, role-based permissions, automated security scanning, and audit logs. The goal isn’t to stop people from building with AI. It’s to make sure what they build can be governed once other people start depending on it.
TL;DR
- AI app builders are great at a first version, but a working demo and a safe internal tool are different things once more than one person uses it.
- Superblocks demonstrated this gap with a customer support CRM where a support agent requests a refund and a manager approves it, each role needing different information and different permissions.
- The platform separates interface permissions from enforcement: hiding an “approve” button from the wrong user is not the same as the backend actually verifying that user’s role before processing the refund.
- Every app ships with SSO login by default, so the app already knows who is signed in and what group they belong to, instead of letting users self-select a role.
- Automated security scans run at build, publish, and in production. In the demo, the scan caught the app trusting browser-supplied identity data and skipping a check against the original order total.
- A security center gives IT a company-wide view of every app, who built it, and what vulnerabilities exist, separate from the business records (refund amount, reason, decision) that live inside the app itself.
- A cloud-prem deployment option runs the app, its data, and AI inference (through Amazon Bedrock) inside the company’s own AWS account, keeping company data and prompts off third-party infrastructure.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Why does permission checking matter more than it looks like?
The demo built for this workflow was a customer support CRM: a system holding customer records, support tickets, orders, and refund history in one place. The business rule was simple. A support agent can request a refund. A manager decides whether to approve it.
That single rule creates two different jobs inside one app. The support agent needs the order details, the ticket, and the customer’s history, plus a way to add notes and submit a refund request with a reason. The manager needs the same context but a different set of actions: review the reason, check the amount against the order total, and record a decision that stays attached to the original ticket.
The risk isn’t that the interface shows the wrong button to the wrong person. It’s that the underlying operation, the thing that actually changes a refund’s status in the database, has to independently verify that the person calling it is actually a manager. Hiding a button is a UI convenience. It is not a permission check. If the backend logic trusts whatever the browser sends it, anyone who can reach that endpoint can approve their own refund regardless of what the screen shows them.
This is why Superblocks separates two layers of access control. One layer is org and app permissions: who can open the app at all, and who can edit or deploy changes to it. The other is a business rule enforced inside the app’s logic: who can take a specific sensitive action, like approving a refund, checked against the identity of the actual signed-in user.
How does SSO change who gets to claim a role?
In most self-built internal tools, a role is just a dropdown or a setting someone configures once and forgets. Superblocks apps come with single sign-on by default, meaning the app already knows who is logged in and which group in the company directory they belong to, rather than relying on the user to self-identify as “agent” or “manager.”
That distinction matters because it moves role assignment out of the app and into the company’s existing identity system. The support agent view and manager view in the CRM demo aren’t two different apps or two different logins typed in manually. They’re the same application responding to who SSO says is signed in. IT doesn’t have to trust that an app was built correctly to control who can reach which screen. The identity layer does that regardless of how the app’s internal logic was written.
What do the automated security scans actually catch?
Superblocks runs security checks at three points: when the app is built, when it’s published, and again once it’s running in production. In the refund CRM demo, the scan run at publish time found two issues in the refund request flow. The app was trusting identity information sent from the browser instead of verifying it server-side, and it wasn’t checking the requested refund amount against the original order total before processing it.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Both issues matter because they’re exactly the kind of thing that looks fine on screen but isn’t actually enforced underneath. A refund form can display the correct order total and still let a modified request through if nothing on the backend cross-checks the number. A clean-looking approval screen can run perfectly while never confirming that the person clicking “approve” is authorized to.
After running an automatic fix and rescanning, a follow-up report showed one remaining low-severity advisory tied to the fact that the simulated approval decision still happened in the browser rather than through server-side authorization, a reminder that for a real production rollout, that step still needs hardening. The scan turns “does this look secure” into a specific, checkable answer rather than a guess based on how polished the interface looks.
Where does the audit trail actually live?
Two separate records exist, and they answer different questions. Inside the CRM itself, there’s a business record: the refund request, the dollar amount, the stated reason, and the final decision. That’s the data a support agent or manager needs if someone picks up the ticket later and asks what happened.
At the platform level, Superblocks keeps a second kind of record. Audit logs track every change made to the app itself. A security center gives an admin visibility across every app in the company, including who built each one and what vulnerabilities, if any, it currently carries. That’s a company-wide view IT can use to answer a different question: not “why was this refund approved,” but “what apps exist, who’s responsible for them, and are any of them currently exposed.” Both records matter, and conflating them is a common gap in ad hoc internal tools that never had IT oversight baked in from the start.
Is cloud-prem deployment worth considering for sensitive data?
For internal apps touching real customer data, where the app runs is as much a governance question as who can log in. Superblocks offers a cloud-prem option that runs inside a company’s own AWS account rather than a connection to it. The application, its data, and the AI inference calls (routed through Amazon Bedrock) all stay inside that environment.
That setup matters for any internal tool where prompts to an AI assistant might include actual customer records, order details, or support ticket content. Running inference inside the company’s own cloud account keeps that data from transiting third-party infrastructure, which is typically one of the first questions a security team asks before approving any AI-assisted internal tool for production use.
Frequently Asked Questions
What is Superblocks used for?
It’s a platform for building and governing internal business applications, including ones generated with AI assistance, with built-in permissions, SSO, security scanning, and audit logging aimed at IT oversight.
How is this different from tools like Lovable?
General AI app builders are focused on getting a working first version quickly. Superblocks is positioned for what happens after that version needs to run under company login, with defined roles, security review, and a record of who built and changed it.
Does hiding a button in the UI count as a security control?
No. Hiding an action from a user’s view is a UI convenience, not enforcement. The actual operation behind that action still needs to independently verify the signed-in user’s permissions before it executes.
What does the security scan check for?
One coffee. One working app.
You bring the idea. Remy manages the project.
Based on the CRM example, it flagged the app trusting browser-supplied identity data instead of verifying it server-side, and failing to check a requested refund amount against the original order total. Scans run at build, publish, and in production.
What is Clark in this context?
Clark is Superblocks’ AI assistant, used to plan and build the app, pulling from a company’s existing knowledge base (such as a design system) so generated apps match internal standards.
