Evgeny Kokuykin on AI Security - AI Dev Podcast (Category AI4SDLC)

I saw it. podcast AI Dev Conf, in which Evgeny Kokuykin, Andrey Dmitriev and I participated. We talked about what happens to security when not only people start writing coders, but also agents with different tools, accesses and rights to change. Speaking about the guest, Evgeny Kokuykin is CEO of HiveTrace, co-founder of Raft, head of AI Security Lab at ITMO and member of OWASP Agentic Security. That is, this is the point of view of the AppSec/AI security practice, which sees both the technology and the attack surface.

The main idea of the issue revolves around the fact that in agent development, security becomes part of the process architecture: who acts, on whose behalf, what rights get, what is logged, where approval is needed and how quickly you can roll back. Our communication can be divided into separate blocks.

1Why coding agents have moved so fast In conventional GenAI applications, it’s hard to know how good the answer is: the user puts his finger up or down, but that’s weak feedback. It's different in development. We already have compilers, linters, tests, git history, bug trackers, CI/CD and code revision. You can take an old bug, restore the state of the repository, give the agent a task and test the solution with the same tests. The SDLC already contains a blank for evals. That's where autonomy grows. The agent can solve the problem, get feedback from the tests, restart the attempt, transfer the changes to the review. For an external client, the “try again” mode would look strange, and within the development of retry, tests and revisions become a normal part of the circuit.

But then the unpleasant part begins. If an agent becomes a member of an SDLC, it cannot be taken as a harmless clue in an IDE. It is similar to an internal employee or service account: identity, accesses, tokens, the ability to read repositories, pull APIs, view logs, sometimes deposit or help with incidents. The problem of service accounts was painful before, but agent development multiplies it by an order of magnitude.

Often talk about AI security quickly goes into the field of prompt injection, jailbreaks and beautiful attacks on the model. But in many real-world scenarios, a more boring layer breaks down: access rights, secrets, supply chain, dev/stage/prod separation, action and dependency audits. Evgeny gave examples from the world of coding assistants, MCP servers, Postmark, LiteLLM and other supply-chain stories. The pattern here is simple: if an agent or its instrument has tightened an infected addiction, conventional unit tests may not notice anything.

2Economics and metrics It’s easy for businesses to promise to “replace half of development with agents,” but the reality is more complicated. It is necessary to consider not only tokens and GPUs, but also the platform: gateway, routing between models, sandboxing, authentication, authorization, quotas, observability. Benefits cannot be reduced to the number of AI codes: it is more interesting to look at specific jobs inside SDLCs - migrations, bugfixes, reviews, tests, incidents, repeatable changes.

3Reliability If the SRE agent is in 2 In the morning, you can get a history of the incident, it is useful. If it can restart services, change configurations, or execute a recovery plan, that’s another risk class. If every dangerous action of an agent leaves for senior approval, the bottleneck simply moved to the busiest people. So we need more subtle risk policies: what the agent can do on its own, where the second circuit of verification is needed, where isolation of the environment is required, and where the action is always prohibited.

4Responsibility We discussed the agent almost like a classic principal-agent couple. (theory)A person or company sets a target, an agent acts on their behalf, and then misalignment, side effects, and the question “Who is answering?” appear. This logic from management now seeps into the technical circuit of one engineer and his agents.

For engineers, the main conclusion is this: AI security in SDLC is not a separate “check of information security”, but the design of the production system. We need evals, threat modeling, least privilege, sandboxing, environment separation, audit trail, model routing, secret control, policy for non-human identities, and agency visibility.

And even more practical: if there are coding agents in the company, then you should not start with the question “which model to choose”, but with a map of rights and consequences. What's the agent reading? Write what? What tools does he call? Can he get the data? Can it deplose? Who will see his actions? How to stop, roll back and investigate the result? Without these questions, “accelerating development” is very easy to turn into accelerating risk.

#AI #AI4SDLC #Security #Engineering #Architecture #DevSecOps #Agents