There is a temptation in AI product development to give the intelligence direct access to the data layer. It simplifies the architecture. It speeds up development. It also creates a system that is nearly impossible to secure, test, or reason about.
We drew a hard line early: the AI never touches the database. Every operation flows through a typed service layer - dozens of service classes, each owning a specific domain, each enforcing its own validation and authorisation rules. The AI calls services. Services call the database. There is no shortcut.
Why this matters more for AI
In a traditional application, the code that constructs queries is written by developers and reviewed in pull requests. In an AI application, tool calls are constructed from natural language at runtime. The inputs are unpredictable by definition. If those unpredictable inputs can directly influence query construction, you have a security surface area that grows with every conversation.
The service boundary is a firewall. Every input is validated through typed schemas before it reaches a query. Every operation checks that the requesting user actually belongs to the organisation they are operating on. Every query selects only the columns it needs and enforces result limits. These constraints exist in the service layer, not in the AI's tool definitions, because services are testable and reviewable in ways that runtime AI behaviour is not.
The consistency principle
When the AI creates a content piece and when a user creates a content piece through the interface, the same service method executes. The business logic lives in one place. This means we do not maintain parallel implementations that can drift apart. It means a bug fix in the service layer fixes the behaviour for both the AI path and the human path simultaneously.
The testing dividend
Because services are stateless, independently instantiable, and rely on injected dependencies, they are straightforward to test in isolation. We do not need to simulate an AI conversation to verify that a data operation enforces the correct authorisation rules. We test the service directly.
This matters enormously at scale. As the platform grows and the AI gains new capabilities, the service layer is what lets us move fast without worrying that a new tool call might accidentally bypass a security check that exists in some other part of the system.
The cost
The cost is real. Every new capability requires both a tool definition and a service method. It is more code, more files, more surface area to maintain. But the alternative - giving an AI direct access to your users' data with only prompt instructions as a guardrail - is not a serious option for software that businesses depend on.
Discipline at the boundary is what makes everything above it possible.
- Cleo's Team