AI security
What you can safely give an AI service, and what will turn into an incident
A total ban does not work: people still use AI from their personal accounts, and you no longer see what is happening. What works is a short set of rules that says which data may go to which kind of service, and is simple enough that people follow it.
Where to start
Four steps to take before you write any policy
- Make a list of what is already in use: AI services, personal accounts, knowledge bases and agents. Staff are already using AI tools without asking; this is not a theory.
- Sort the services into three classes and the information into six. The same prompt carries a completely different risk, depending on where it is sent.
- Approve which routes are allowed, write the internal policy, and name the people responsible for it.
- Run one safe pilot project with a financial result you can measure, instead of ten experiments that nobody can evaluate.
Service classes
Where the AI runs is more important than which model it is
An employee uses it alone: no company contract, no administration, no control. Public information only.
An external provider supplies it, but the company uses it under a contract, with administration and agreed security settings.
Installed inside the company or managed by it: access control, logging and company rules all apply.
The full K1–K3 × D1–D6 table — six classes of data against three classes of service, with the conditions for each cell — is published on the Russian AI security page. You can read the table without Russian: the answers are YES, NO and CONDITIONAL.
Agents
When the model can act, access control is not enough any more
A chatbot only answers. An agent acts: it calls tools, reads external data, keeps memory between sessions, and performs actions for a person. An attacker can use every one of these steps, and the old question "is this user allowed to read this file" is no longer enough. You need control over the action, not only over the access.
- Prompt injection: a hidden instruction inside the data that the agent was asked to read.
- Tools and MCP servers with much wider permissions than the task really needs.
- Memory that carries a harmful instruction from one session to the next.
- Actions performed for a person, with no record of who approved what.
I can give this as a talk, as a workshop for a security team, or as consulting work on your own system. The practical materials, the analysis of attacks on agents, and the guide to unapproved AI tools are on this site in Russian.