AI-built apps are easy. Safe access to live business data is the hard part, and AWS just moved it

The first AI-built internal app in most companies looks great in the demo and goes wrong a week later. Someone exported a spreadsheet so the app would have data. The numbers are stale by Monday. The app shows every region’s figures to everyone who has the link, because the export did not carry the permissions of the system it came from. Nobody did anything malicious. The app simply skipped the hard part.

We made this argument a few days ago in our analysis of Copilot Managed Runtime: generating apps got easy, and running them is the hard part. AWS has now addressed one specific piece of that hard part for Amazon Quick.

What AWS shipped

Amazon Quick Apps are applications built from natural-language prompts: a user describes what they want and an AI agent writes and deploys a working web app. In a post published October 1, AWS explained that Quick Apps can now query governed datasets in real time instead of embedding a static snapshot at build time. In AWS’s words, the app shows data “current as of right now, filtered to what you are allowed to see.”

The supported sources include Quick Sight datasets in both SPICE (in-memory) and Direct Query modes, Direct Query sources from supported providers, enterprise content and documents, and action connectors such as Jira, Slack and Google Drive.

The permission model is the important part:

• Each viewer queries with their own identity. The app does not run with the builder’s access.
• Row-level and column-level security apply automatically, the same rules defined on the dataset.
• Consent is enforced server-side on every query, and viewers must authenticate as Quick users.

AWS’s post does not say whether the capability is in preview or generally available, and does not list regions for it specifically. Amazon Quick’s regions table lists agentic features in US East (N. Virginia), US West (Oregon) and AWS GovCloud (US-West) among others, but not in US East (Ohio). Confirm both points before planning around it.

Why the snapshot was the real problem

1. Builder exports a snapshot
2. App embeds the copy
3. Everyone sees the same stale rows
4. Viewer signs in
5. Query runs as the viewer
6. Row and column rules apply, data is current

• Copy at build time: Builder exports a snapshot · App embeds the copy · Everyone sees the same stale rows
• Governed path at run time: Viewer signs in · Query runs as the viewer · Row and column rules apply, data is current

Uncontrolled copyGoverned access

A snapshot inside an app fails in three ways at once. It goes stale, so decisions are made on old numbers. It loses permissions, because the copy does not know who was allowed to see which rows. And it is a new copy of business data with no owner, no retention rule and no place in anyone’s inventory, which is exactly the custody problem we described in our piece on custody as the first question.

Querying the governed dataset at run time, as the viewer, fixes all three for the data that lives in that dataset. That is a real architectural improvement, and it is the right pattern regardless of vendor: AI-built apps should consume governed data products, not copies.

What stays your responsibility

The dataset’s rules have to be right. Live access inherits row and column security; it does not invent it. If the dataset was built with broad access because only analysts used it, an app on top now exposes that breadth to whoever the app reaches. Review dataset permissions before you let generated apps point at them.

Reads and actions are different risks. Querying a dataset as the viewer is a read. Action connectors to Jira, Slack or Google Drive write into other systems. Decide which generated apps may use actions at all, and with whose authority.

Load moves to the source. Direct Query sends live queries to the underlying database. A popular generated app can become an unplanned workload on a production system. Prefer curated datasets or SPICE for heavy use, and watch query volume.

Inference location is managed for you. Quick’s documentation says cross-region inference keeps requests within the geography, that customers cannot configure the routing, and that CloudTrail and CloudWatch logs do not record the region where inference happened. For most U.S. workloads that is acceptable; for GovCloud or other regulated environments, check it against your authorization boundary.

Someone still owns the app. Live data removes the stale-copy problem, not the ownership problem. Generated apps still need a registered owner, a purpose and an end date.

What to do now

1. Ban snapshots in AI-built apps by policy wherever a governed dataset exists, and make the governed path the default template.
2. Audit row and column security on the datasets most likely to be used by generated apps before enabling live access.
3. Separate read apps from action apps and require review for any generated app that uses action connectors.
4. Watch Direct Query load on source systems during the first weeks.
5. Register generated apps with owner, data sources and audience, the same way you register agents.

The bottom line

The question for AI-built enterprise apps was never whether an agent can write the code. It is whether the app touches business data through the same governed path as every other consumer. AWS’s live-data change makes that the easy path in Amazon Quick. The permissions it inherits still have to be right, and that work was always yours.