Enhancement Request: Granular Table-Level Access Control

[lperutka]

With the introduction of advanced Agent capabilities, finer control over data access has become increasingly important. At present, access control is limited to a binary decision—allowing or denying synchronization at the entire instance level. While this approach is simple, it lacks the flexibility required for more autonomous and automated use cases.
To better support agents capable of performing actions independently, it would be highly beneficial to introduce table-level access control with configurable CRUD permissions. This would allow administrators to explicitly define what operations are permitted on individual tables, significantly reducing risk while enabling more advanced automation scenarios.
Proposed access modes could include, for example:

• Fully allowed (manual and agent-based operations)
• Allowed for manual actions only
• Allowed for agent-driven actions only
• Not allowed

Alternatively, or additionally, this could be implemented via table-level whitelisting or blacklisting mechanisms.

[arnoudkooi]

That complexity and need for maintenance.
Would adding this to your agent instructions work? In general it follows the user access.
Besides a global createArtifacts.enabled setting was added, would that help?

[lperutka]

I agree that complexity will be a challenge. However, this is ultimately a matter of choice: either the user invests the effort to configure things properly for security reasons, or they choose to ignore it. As a middle ground, there could be options such as regex-based constraints or a more “thematic” grouping—for example, server-side backend logic, base data, stored procedures, UI builder, and similar categories.

One of the core issues with agent instructions is that agents sometimes disregard them. In some cases, the agent assumes it “knows better” and attempts to work around the constraints; in others, it simply does not process the full set of instructions—I have encountered several examples of both. Because agents are highly capable, they can also derive surprisingly creative workarounds. For instance, if deletion is explicitly disallowed, the agent may instead create a scheduled job that runs a few seconds later and deletes the records anyway.

This is why it would be valuable to have additional safeguards to protect against such behavior.

I am also interested in experimenting with delegated development (or whatever the current terminology is), as it may help address at least some of these security concerns.