Russian Companies Move to Systematic AI Agent Security Instead of One-Off Reviews

AI agent security can no longer be handled by manually reviewing each new tool. LLMs and coding agents now have access to code, shell, git, the network and secrets, so they should be treated as ordinary services with very broad privileges. When such systems are built into development, testing and operations, the question is not whether they can be trusted, but what restrictions, policies and observability the company has put around them.

Over the past two to three years, Russian companies have stopped treating generative AI as a curious experiment and started building it into everyday processes. This is no longer just about support chats or text drafts: models help developers, take part in code review, generate infrastructure code, work with configuration, and increasingly become part of real products. International guidance points the same way: NIST suggests viewing generative AI as an element of critical infrastructure, while ENISA separately examines its role in DevSecOps and engineering automation. The logic is simple: once a model gets access to data, tools and the ability to execute actions, it stops being merely an interface and becomes a working node of the system.

The threat profile changes with it. Classic problems such as authorization errors and injections are joined by the risks described in the OWASP Top 10 for LLM Applications: prompt injection, insecure handling of model output, secret leaks through context, excessive agent permissions, and insecure plugin or tool design.

A study of several AI agents showed a recurring pattern: almost all have shell access through local commands, Docker or SSH, many can work with git directly, creating branches and commits, and their configurations often include dangerous modes such as bypassPermissions. In such a setup, a single successful injection or one insecurely handled model response is enough for an agent to run an arbitrary command, extract tokens and keys, quietly alter code, or start moving through internal services and the CI/CD chain.

The problem is that manually vetting every new agent scales poorly. Even if the tool's developer has already added a default sandbox, a secrets-handling module, redaction of sensitive data in logs and documentation for safe deployment, the security team still has to work out almost from scratch how far those settings can be trusted.

That is why the author proposes removing the word "AI" from the discussion and looking at an agent as a black-box service with broad privileges. If such a service can read and modify files, run commands, call external APIs and push code, it should be assessed through familiar domains: who exactly initiates actions, what rights the agent receives, where it runs, which directories, networks and tools it can reach, what gets logged, and how quickly the team will notice an anomaly.

A practical protection profile follows from this. First, clear authorization rules and least privilege: which repository the agent can see, whether it can write or only read, and whether it may run tests, migrations or shell commands. Second, isolation: a container, a separate runner or a dedicated environment with tightly restricted mounts, and no unnecessary access to docker.sock, the Kubernetes API or production secrets. Third, network control with domain allowlists and a clear policy for outbound requests. Finally, static analysis of code and configs, lab-based dynamic tests with honeypot files and fake secrets, and auditing and alerts for atypical agent behavior are essential.

This approach does not ban AI adoption. It turns AI from a trendy, hard-to-predict tool into a managed component of engineering infrastructure.

What this means in practice: security should not slow down the adoption of coding agents, but they should not be trusted by default either. If a unified set of requirements is assembled in advance together with development teams, typical risks are tested in an isolated environment and access policies are fixed, then each new AI tool will stop turning into an urgent and expensive expert review. For business, this means faster adoption of useful automation without unnecessary risk to code, secrets and internal infrastructure.