A useful dealership assistant needs context. It does not need unrestricted database access.
Those two ideas are often confused. The shortest demo is to connect a model to a warehouse and let it write queries. The safer production design is to give it a small set of tools that already know the store's definitions, permissions and limits.
A tool is a contract
Consider the question, "How many used units did we sell last month?" Raw table access asks the model to discover the schema, choose the date, identify retail versus wholesale, handle unwinds and decide which stores the user may see.
A governed tool can be named get_delivered_units. It accepts store scope, date range and sale type. The query inside it is owned, tested and versioned. It always excludes wholesale unless explicitly requested. It logs who called it and returns the definition with the answer.
The model still provides a natural interface. The business logic stays outside the model.
Least privilege and least agency
The FTC Safeguards Rule requires access controls, encryption, multifactor authentication, monitoring and service-provider oversight for covered customer information. OWASP identifies excessive agency as a major risk in systems where a model can take actions through tools.
The practical response is to separate capabilities:
- read tools return approved aggregates or limited records;
- draft tools prepare a message or action without sending;
- approval tools present the exact target and payload to a person;
- action tools enforce caps, permissions and idempotency;
- receipt tools record what happened and link it to the source request.
A user who may see one rooftop should not gain group access because the assistant has a broad service account. A drafting agent should not inherit send authority. A recall workflow should not be able to query finance fields.
Put definitions in code, not prompts
Prompts are useful instructions. They are not hard controls. "Never count wholesale as retail" belongs in the query and test suite. "Never contact a customer more than twice in seven days" belongs in the send function. "Do not expose SSNs" belongs in the view and permissions.
NIST's AI Risk Management Framework emphasizes documented roles, oversight, testing and measurement. A tool layer makes those controls inspectable. It also makes the assistant easier to improve because the store can tell whether the failure came from language understanding, business logic, data or authorization.
The production checklist
- Inventory the questions and actions users actually need.
- Create the smallest tool for each job.
- Return source dates, definitions and row counts with answers.
- Enforce user and store scope outside the model.
- Require approval for customer contact, data export and material operational changes.
- Add duplicate guards, frequency caps and retry safety.
- Log every call, result, approver and final outcome.
- Test denied actions as seriously as successful ones.
AI becomes valuable when it can reach the store's real context. It becomes trustworthy when that reach is narrow, explainable and receipted. Give it tools, not the keys to every table.
The takeaway
Encode dealership definitions and permissions inside narrow tools, then let the model choose among those tools.
Sources and further reading
- FTC - Safeguards Rule: what your business needs to know
- NIST - AI Risk Management Framework
- NIST - AI Resource Center
- OWASP - LLM06:2025 Excessive Agency
External sources support the public facts and frameworks above. Store-level outcomes remain qualitative unless they are already published and verifiable.