Database access

Sooner or later every useful agent needs the database — orders, customers, tickets live there. The design question is how much query freedom to grant, and the answer is a ladder: start at the bottom, climb only when tasks demand it.

The query-tool ladder

1. Fixed lookups — lookup_order(order_id): a parameterized query you wrote, the model fills one typed hole. Zero injection surface, zero surprise cost. Most agent needs live here; your resolution agent stays here.
2. Parameterized templates — orders_by_customer(email, since_date, status?): still your SQL, several typed holes, bounded result caps. Covers 'flexible lookup' without granting query authorship.
3. Guarded SQL — the model writes SELECT statements against an allowlisted schema, and a validator enforces: read-only verbs only, approved tables/views only, mandatory row limits, cost/timeout caps, no joins beyond the approved graph. Powerful for analytical agents; a real engineering commitment to do safely.
4. Raw SQL — no. Not with read-write credentials, not 'just for the demo'. An injected or confused agent with raw SQL is a data incident with a conversation log.

Defense in depth, database edition

• Read-only credentials at the connection level — the same discipline as every connector you've met in this catalog: the tool physically cannot write, whatever the model asks. Guardrails in code beat guardrails in prompts; guardrails in credentials beat both.
• Scope rows, not just tables. A support agent resolving ticket HL-2210 needs that customer's orders — a view or filter scoped to the case, so a confused (or injected) agent can't wander the whole customer table. Least privilege per task, not per agent.
• Shape and cap results in the adapter — 10 rows and a count, like every other tool. A 50,000-row result is a context flood and a privacy incident sharing a trench coat.
• Log queries with task IDs — the audit question 'what did the agent read while resolving this case?' should be one lookup.