Secure AI solution development
We develop custom AI solutions with a security focus: an internal knowledge base search tool, an integration with your existing systems, or an AI agent. We build in access control and logging from the design stage.
What we build
Three types of solution, each with its own risks
With a search tool, the question is who can see what in the answers. With an agent, it is also what the agent can do on the user’s behalf.
Internal knowledge base search
It answers employees’ questions from the organization’s own documents. Systems like this are also called RAG (retrieval-augmented generation): before answering, the model pulls the relevant passages from internal sources.
Integration into existing systems
The AI feature goes into an application you already use, for example to summarize, classify, or process documents.
AI agent
Beyond answering, an agent also takes action: it reads files, sends email, or calls APIs. The more tools it can reach, the more damage a malicious instruction can do.
The process
How development proceeds
-
Requirements specification
We document what problem the solution solves, who will use it, and which data and systems it needs to access.
-
Architecture design
We design where the model runs, where it gets its data, which tools it may call, and what the system logs.
-
Development and testing
We build the solution and test it before go-live. Testing also checks whether the access rules actually hold in practice.
-
Go-live and handover
The solution goes into production, and we hand it over to users and administrators together with documentation. Ongoing operation after rollout is available under a custom agreement.
Security from the design stage
Permissions, tool access, logging
The most common serious flaw comes from the permissions the model runs with.
With the user’s own permissions
The solution reads data on behalf of the user, with that user’s permissions. If a shared service account read the file share, anyone could use the assistant to reach whatever that account can see, even the payroll list.
Narrowly scoped tool access
With an agent, the questions are which tools it may call, where its output has to be checked before it runs, and which actions need human approval.
Traceable logs
After the fact you can still see who asked what and when, which sources the answer was built from, which tool the system called with which parameters, and what the output was.
Deliverables
What you get at the end
items handed over
- Requirements specification and architecture design
- Development, testing, and go-live
- Data handling and logging that follow user permissions
- User and administrator documentation
Related services
What comes before and alongside development
Reviewing a system that is already running, running models locally, and preparing users are separate services.
Security review of LLM and AI agent infrastructure
Architecture and configuration review of in-house or adopted language models, AI agents, and RAG systems, based on the OWASP LLM Top 10.
Local (on-prem) AI deployment
Running a language model on the organization’s own infrastructure, so the data stays in-house.
Security and AI usage training
Live training tailored to your company, for managers and staff: classic security awareness and the safe use of AI tools in one program.
Frequently asked questions
The questions we hear most
Can prompt injection be fully prevented?
Not fully. A language model cannot reliably tell instructions from data, because both are text. The indirect variant is more dangerous: the malicious instruction hides in a document, web page, or email that the system processes. Protection is therefore built so that even a successful injection has a limited effect. We covered the risks in detail in our article on security risks of enterprise AI adoption.
What should be settled before development starts?
First, what data the system will see and how sensitive that data is. Then whether the data leaves the organization, and if it does, whether there is a contract and a legal basis for it. You also need to decide in advance what happens when the model makes a mistake or is unavailable.
If the model runs locally, is security taken care of?
The risk of data transfer goes away, because the data does not reach a third party. Prompt injection and permission issues, however, remain no matter where the model is deployed.
