Datasette gives its agent query permissions, not free rein over the database

Datasette Apps 0.3a0 tightens its integration with Datasette Agent. New tools let the agent add or remove the stored queries available to a specific HTML app. If a query can write to the database, the user must approve the change first.

The release also hardens app creation. The tool checks that each requested stored query exists and that the user may view it. Apps can be tagged with # in chat, and autocomplete only offers apps the user has permission to open.

The agent now manages permissions one stored query at a time

Datasette Apps hosts custom HTML and JavaScript inside Datasette. Apps run in a sandbox and reach data through approved databases or stored queries. Version 0.3a0 carries that boundary into agent workflows: the agent can change the allowed query list without automatically receiving broader access.

The clearest change concerns writes. An agent may request a query that modifies data, but a person keeps the final decision. The same check applies when a new app is created.

For company data, permission scope matters more than polished generated HTML

An LLM can quickly assemble a dashboard or a small internal tool. The risk is larger than a poor color choice or broken layout. What matters is which tables the app can read, what it can change and where it can send data.

Datasette addresses that question with concrete controls. Access is tied to existing stored queries and user permissions, creating a more auditable interface than a vague instruction telling the agent to be careful.

A sandbox is only as safe as the stored queries behind it

Approval does not guarantee safety. An overly broad read query can expose sensitive data, while a poorly designed write query can alter more rows than the user expects. This is also still an alpha release, so it signals a direction rather than finished enterprise governance.

Human attention is another limit. If an agent produces many similar approval requests, users may start accepting them without inspection. Good permissions must be narrow and clearly explained.

Change logs and clear write requests will determine whether the boundary holds

The next meaningful test is operational. Administrators need to see which agent added a query, who approved a write and which app used it.

The approval dialog also has to explain the effect in language an ordinary user understands. That is where this boundary becomes a real safety control or merely another OK button.

Lilith's verdict

The agent can reach the database only through a clearly labeled opening, and writes still require a human at the bell. Audit logs will show whether the guard actually reads what it lets through.