AI agents accessing production data
12 comments
Fast is probably going to get in the way of Good, but here are some things to think about.
1. In many businesses, different users of the agent should have different read/write permissions to data.
2. Log everything. There will be problems. You'll need to debug, attribute, defend yourself against accusations that the cockup was your fault, etc.
3. If you're just providing read-only then the more you can enforce that at all layers of the stack (e.g., read-only user in the database).
4. Don't give the agent direct SQL access to the database. Write functions in your favourite programming language, expose them as tools to the LLM.
5. Don't make your LLM do maths in its head, they're crap at it. I had some success giving the agent tools that fetch data from the database (where I control the SQL that runs) into a SQLite in agent memory, then the agent can run SQL against that database. Gives you a chance to put the data into an obvious, easy to query, format rather than whatever arcane historic chaotic state your main schema has evolved to).
1. In many businesses, different users of the agent should have different read/write permissions to data.
2. Log everything. There will be problems. You'll need to debug, attribute, defend yourself against accusations that the cockup was your fault, etc.
3. If you're just providing read-only then the more you can enforce that at all layers of the stack (e.g., read-only user in the database).
4. Don't give the agent direct SQL access to the database. Write functions in your favourite programming language, expose them as tools to the LLM.
5. Don't make your LLM do maths in its head, they're crap at it. I had some success giving the agent tools that fetch data from the database (where I control the SQL that runs) into a SQLite in agent memory, then the agent can run SQL against that database. Gives you a chance to put the data into an obvious, easy to query, format rather than whatever arcane historic chaotic state your main schema has evolved to).
Thank you so much...
One doubt I have is when we expose tools instead of this raw sql, how do ensure that agents are using the correct data like right source and not stale.
Do we have to enforce some checks manually or is it not worth to worry(now it's read only right).
And one more doubt, what's the reason u introduced a lite layer in between?
Do we have to enforce some checks manually or is it not worth to worry(now it's read only right).
And one more doubt, what's the reason u introduced a lite layer in between?
I’m dealing with invoices and customers and timesheets and tickets. I didn’t want to give an agent SQL access to the database for performance and security reasons, and we don’t have a read only replica (which would have been much more acceptable to give read access to). So my tools are get_invoices etc. and they pull data into the SQLite.
My use case is a short conversation to answer a question like “has all the time from this task been invoiced?” Or “what contributed to the size of this invoice!”. So my agent starts with empty SQLite, fetches the data into SQLite, writes queries to answer the question, then user can continue to interrogate but eventually shuts down.
I don’t have a perpetually running agent so I haven’t had to solve that problem.
What could go wrong? Delete production data. Corrupt production data. Show staff member info they shouldn’t have. Show customer info they shouldn’t have. Rely too much on the LLM doing the right thing, it doesn’t, and the agent presents the wrong information without knowing. Bugger up the security and anyone can use the agent to query production data. … Yeah, be cautious.
My use case is a short conversation to answer a question like “has all the time from this task been invoiced?” Or “what contributed to the size of this invoice!”. So my agent starts with empty SQLite, fetches the data into SQLite, writes queries to answer the question, then user can continue to interrogate but eventually shuts down.
I don’t have a perpetually running agent so I haven’t had to solve that problem.
What could go wrong? Delete production data. Corrupt production data. Show staff member info they shouldn’t have. Show customer info they shouldn’t have. Rely too much on the LLM doing the right thing, it doesn’t, and the agent presents the wrong information without knowing. Bugger up the security and anyone can use the agent to query production data. … Yeah, be cautious.
Can we reuse the same framework for any agents? Will it work? Have u tried it.
I haven’t dropped an agent into production yet. This is all internal / PoC work.
Claude / your favourite LLM coding agent can help you design this and will be good at helping you unpack risks and hazards. Good luck!
Claude / your favourite LLM coding agent can help you design this and will be good at helping you unpack risks and hazards. Good luck!
What are the goals of this AI agent?
So it's nothing much ..just basically answering some questions from their data pool, need to check inventory. Still il the read only version.
If anyone built similar systems or worked on this would you help like. I mean any insights or learnings.
The issue is actually there is no granular enforcement of what the agents should access. I even thought of building an standalone tool for this. But, need to complete the given current work fast.