Russian companies are shifting to systematic security for AI agents instead of point checks

AI agent security can no longer be addressed through manual review of each new tool: LLMs and coding agents have gained access to code, shell, git, networks and secrets, so they must be treated as ordinary services with very broad rights. When such systems are embedded into development, testing and operations, the question is not whether they can be trusted, but what constraints, policies and observability the company has implemented around them. Over the past two to three years, Russian companies have stopped viewing generative AI as a curious experiment and have begun embedding it into everyday processes.

It is no longer just about support chats or text drafts: models help developers, participate in code review, generate infrastructure code, work with configuration and increasingly become part of real products. International recommendations point to the same trend: NIST proposes treating generative AI as an element of critical infrastructure, while ENISA separately examines its role in DevSecOps and engineering automation. The logic is straightforward: as soon as a model gains access to data, tools and the ability to execute actions, it stops being merely an interface and becomes a working node in the system.

Along with this, the threat profile changes. In addition to classical problems like authorization errors and injection attacks, new risks emerge that OWASP Top 10 for LLM Applications describes: prompt injection, unsafe handling of model responses, secret leaks through context, overly broad agent permissions and insecure plugin or tools design. Research on several AI agents revealed a recurring pattern: almost all have shell access through local commands, Docker or SSH; many can work directly with git, create branches and commits; and the configuration often includes dangerous modes like bypassPermissions.

In such a combination, a single successful injection or one unsafely processed model response is enough for the agent to execute arbitrary commands, extract tokens and keys, silently modify code or start traversing internal services and CI/CD chains. The problem is that manual review of each new agent scales poorly. Even if the tool developer has already added a sandbox by default, a module for secret handling, sensitive data editing in logs and security documentation, the security team still has to review almost from scratch how trustworthy these settings are.

Therefore, the author proposes removing the word "AI" from the discussion altogether and treating an agent as a black-box service with broad rights. If such a service can read and modify files, execute commands, call external APIs and push code, then it should be checked through familiar domains: who exactly initiates actions, what rights does the agent receive, where does it run, what directories, networks and tools does it have access to, what is logged and how quickly will the team see an anomaly. This leads to a quite practical security profile.

First, there must be clear authorization rules and minimum privileges: which repository does the agent see, can it write or only read, is it allowed to run tests, migrations or shell commands. Second, isolation is important: a container, separate runner or dedicated environment with strictly limited mounts, without unnecessary access to docker.sock, Kubernetes API and production secrets.

Third, network control is needed with whitelists of domains and clear policies for external requests. And finally, static code and configuration analysis, laboratory dynamic tests with honeypot files and fake secrets, as well as auditing and alerts for unusual agent behavior are mandatory. Such an approach does not prohibit AI implementation but transforms it from a fashionable and poorly predictable tool into a managed component of engineering infrastructure.

What does this mean in practice: security should not hinder the adoption of coding agents, but trusting them by default is not an option. If together with development teams you collect a unified requirements profile in advance, check typical risks in an isolated environment and establish access policies, then the appearance of a new AI tool will no longer turn into an urgent and expensive expert evaluation each time. For business, this means faster implementation of useful automation without unnecessary risk to code, secrets and internal infrastructure.