{
  "id": 15807852,
  "title": "My AI Agent Never Touches the Database",
  "url": "https://urgent.news/2026/10/20/my-ai-agent-never-touches-the-database",
  "topic": "culture",
  "section": "Culture",
  "published": "2026-10-20T21:59:05.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/vvakim/my-ai-agent-never-touches-the-database-5ecb"
  },
  "original_language": "en",
  "account": "Most AI agent demonstrations place the model on top of a database, but this approach poses security risks. The author of this article is building an AI agent for The Arsenal, a life insurance platform.\n\nThe first version of the agent is read-only, meaning it only retrieves performance data to answer user queries. This design decision stems from the OWASP Top 10 for LLM applications, specifically sensitive information disclosure.\n\nThe data access layer sits between the model and the database, preventing the model from ever accessing the database directly. Instead, the model calls predefined functions that return specific data points. If a function doesn't exist for a particular query, the model cannot answer it.\n\nIdentity is determined by the user's session, not the model itself. When the model requests information by lead ID or client ID, these are treated as parameters. The data access layer attaches the caller's identity to each query and filters the results based on the user's access level.\n\nColumns in the schema are tagged as public, production, or client PII. Each function declares its tier, and the data layer adheres to these tags, refusing to return anything above the declared tier. This way, even if a column is added without a tag, it defaults to PII and remains unrevealed.\n\nThe model politely informs users when the requested data is out of scope, such as a phone number or date of birth. However, the actual refusal is handled by the data layer, ensuring that no sensitive information is ever exposed. The model may attempt to bypass its own restrictions through prompt injection, but it will still reveal no data.\n\nWhile this design eliminates many potential leaks, it relies on the correctness of the data access layer. The author plans to test this assumption by auditing the system as a downline user. The design also doesn't address the model's ability to write data, which would reopen all the security questions. Additionally, the author acknowledges that the design doesn't cover model provider retention and training terms, which are contractual matters rather than code changes.",
  "summary": "Originally published on Medium . Most AI agent demos put the model on top of the database. The agent gets a \"query\" tool, the user asks a question, the model writes the query. It works great in a demo. In production, it means the model's judgment is the only thing standing between a user and someone else's data. I'm building an AI agent into The Arsenal , a platform for life insurance agents. The…",
  "key_points": [
    "AI agent retrieves data through read-only functions, avoiding direct database access",
    "Data access layer filters results based on user's access level and column tags",
    "Model politely informs users when requested data is out of scope, preventing leaks"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}