3 ms·

> AI Agents, instead, directly access the database, completely bypassing this layer. If so, then as the wise man says: "well, there‘s your problem!" I don't d

> AI Agents, instead, directly access the database, completely bypassing this layer. If so, then as the wise man says: "well, there‘s your problem!" I don't doubt there are implementations like that out there, but we should not judge the potential of a technology by the mistakes of the most boneheaded implementation. Doing the same in the bank analogy would be like giving root SQL access to the phone operators and then asking them pretty please to be careful with it.

scott_w 1y ago
> If so, then as the wise man says: "well, there‘s your problem!" Of course, I wouldn't defend this! To be clear, it's not possible to know how every AI Agent works, I just go off what I've seen when a company promises to unlock analytics insights on your data: usually by plugging directly into the Prod DB and having your data analysts complain whenever the engineers change the schema. > we should not judge the potential of a technology by the mistakes of the most boneheaded implementation. I agree.
- hannasanarion 1y ago
  Having the agent plugged into the DB doesn't mean the agent can see everything in the DB. If that plug includes an automatic "where current user has access" filter, then the agent can't know anything the user can't know. That's what the bank agent analogy was meant to tell you. The agent has a direct line to the prod DB through their computer terminal, but every session they open is automatically constrained to the account details if the person on the phone right now and nobody else.
  - scott_w 1y ago
    > Having the agent plugged into the DB doesn't mean the agent can see everything in the DB. If that plug includes an automatic "where current user has access" filter, then the agent can't know anything the user can't know. It depends on how it's plugged-in. If you just hand it a connection and query access then what exactly stops it? In a lot of SaaS systems, there's only the "application" user, which is restricted via queries within the API. You can create a user in the DB per user of your application but this isn't free. Now you have the operational problem of managing your permissions, not via application logic, but subject to the rules and restrictions of your DBMS. You can also create your own API layer on top, however this also comes with constraints of your API and adding protections on your query language. None of this is impossible but, given what I've seen happen in the data analytics space, I can tell you that I know which option business leaders opt for.

scott_w 1y ago

> If so, then as the wise man says: "well, there‘s your problem!" Of course, I wouldn't defend this! To be clear, it's not possible to know how every AI Agent works, I just go off what I've seen when a company promises to unlock analytics insights on your data: usually by plugging directly into the Prod DB and having your data analysts complain whenever the engineers change the schema. > we should not judge the potential of a technology by the mistakes of the most boneheaded implementation. I agree.

hannasanarion 1y ago
Having the agent plugged into the DB doesn't mean the agent can see everything in the DB. If that plug includes an automatic "where current user has access" filter, then the agent can't know anything the user can't know. That's what the bank agent analogy was meant to tell you. The agent has a direct line to the prod DB through their computer terminal, but every session they open is automatically constrained to the account details if the person on the phone right now and nobody else.
- scott_w 1y ago
  > Having the agent plugged into the DB doesn't mean the agent can see everything in the DB. If that plug includes an automatic "where current user has access" filter, then the agent can't know anything the user can't know. It depends on how it's plugged-in. If you just hand it a connection and query access then what exactly stops it? In a lot of SaaS systems, there's only the "application" user, which is restricted via queries within the API. You can create a user in the DB per user of your application but this isn't free. Now you have the operational problem of managing your permissions, not via application logic, but subject to the rules and restrictions of your DBMS. You can also create your own API layer on top, however this also comes with constraints of your API and adding protections on your query language. None of this is impossible but, given what I've seen happen in the data analytics space, I can tell you that I know which option business leaders opt for.