About this talk
In this talk, Marat Kinzhalatov discusses how to create secure services using AI agents, drawing from his extensive experience in payments and fintech. He shares the journey of designing a greenfield service where he first implemented AI agents for production development. Despite initial successes and heightened productivity, he encountered challenges, particularly violations of PCI DSS compliance due to the agents' actions. To overcome these issues, Marat emphasizes the importance of rigorous planning, maintaining context hygiene, and leveraging sandbox environments to enhance agent autonomy. He advocates for experimenting with agent capabilities while ensuring they operate within safe parameters, ultimately striving for a balance between autonomy and controlled execution in software development.
Full transcript
Hello. Hello everyone. Raise your hand if you can hear me. Excellent. Sound check good. Um My name is Marat Kinzhalatov and today we are going to talk about how to build secure services with AI agents. Um a little bit about myself. I'm a software engineer with more than 10 years of experience. It happened to like most of my experience I had in payments and fintech. I worked
for huge banks. I worked for payment providers and I end up in booking in payment department where I develop and architect payment systems. My first um meeting with AI start happened in 2022 when I tried GitHub Copilot. Back in the time you didn't have to specify which Copilot. It was just Copilot but now we have 3,000 Copilots and we have to live with that. Um and I
was blown away by possibilities that Copilot can provide. The most mind-blowing feature for me was that you can just write a comment and Copilot would write down the whole function for you. It doesn't sound like much today but back in the time it was wow. Uh and this got me idea that you want not just I I wanted not just um to use this tools. I also
wanted to spread the knowledge and this what sparked my opportunity and my passion for learning. And here I am here presenting to you. Uh and also I run some communities where we try to build efficient ways of working with agents. here I am here uh presenting to you. So, before I start my talk, I have a couple of quick questions to you. Raise your hand if you
use agents on your daily work base. Almost everyone. Wow, that's a that's a Tricky question. Raise your hand if you use multiple different agents in your daily workflow. Still a lot of hands. I like the crowd, so that's great. Uh let's begin a story. And as every talk story, it will be kind of ideal story. So, I was handed a perfect task that software engineer can dream
of. This task was about uh designing a service from a scratch. So, it was a greenfield service. Uh and I had to design it, and I had creative freedom, and I had everything. no clients to break, nothing. It was ideal. Uh one uh important caveat was that contracts were already in place, but anyway, you you still have creative freedom to design whatever you want. so, I decided
this is a great idea. This is a great opportunity for me to try to use agents in production development. So, obviously, I tried agents before in my pet projects. I had a lot of fun, but uh I have never tried them in uh production, and especially in a security-heavy environment such as payments. So, I decided to give agents a try. and it felt awesome. So, for the
2 days, I was managed to build the whole service, and I felt super productive, probably how 10x engineer can feel. But, as any fairy tale, evil force came in. In my scenario, it was PM with some edits. So, and then this happened. So, I felt overconfident and I was like, "Okay, it's just some changes. I won't write in new specs. I will just throw prompts into the
agent and try to fix that." I started fixing this. I started changing the logic and started changing features. And as you can see by this picture, so what happened is that I fixed one thing, second thing broke. I fixed second thing, fifth thing broke. You may You You can see that I missed the fourth thing. Yes, agent also missed the fourth thing in my plan. So, it
was a disaster. But, this was like quite manageable. So, I could live with that. Unfortunately, what I couldn't live with is that agent uh violated some set of rules. So, in payments, we have a specific set of rules which uh tells you that whenever you work with payment information, you have to follow this set of rules. And this set of rules called PCI DSS. And uh when
I was developing uh with agent, agent implemented everything. And when I was reviewing it, it broke a couple of important parts of that. And that was uh my red line. I couldn't take it. So, I decided it's time to do something about Uh but before I did the so, it caught uh it got me an idea that um we uh living in a world where trends changing
rapidly. For example, like if we take fashion trends, uh e- in the past, you could have fashion changes at least every two decades. So, you had a lot of time to adapt. Uh but nowadays tre- uh fashion trends change, I don't know, yearly, maybe couple of months. Uh and I discovered that same thing happened to the software. So, what happened to my project and what happened to
a lot of projects across the globe uh which used uh which were developed with agents, they becoming legacy. So, usually when you start greenfield project, you have at least couple of years until it become a heavy legacy. Nowadays, I managed to reduce this time to couple of weeks. So, hooray, yeah. I made legacy so far, so quickly. Uh yes, unfortunately, this is something that I didn't want
to have and didn't want to do. So, I decided that I need to fix some things. And I started with fixing my first mistake. So, I was overconfident. I believed in myself a lot because I have very positive experience with EI agent. And I decided that I will just do vibe coding. And don't get me wrong, vibe coding is a lot of fun. But it's a lot
of fun when you use it in pet projects or when you use it in a tools that doesn't require support. So, you create some utility things or you create your pet project and that's fun. You don't think about the code and then you can forget about the whole thing. That doesn't scale. It doesn't work in production. So, what you want to do and what you want to
have, you want to drop vibe coding. Vibe coding doesn't Uh and in my scenario, my initial success was brought to me not by vibe coding, but it was brought to me by beautifully designed uh specs that I have in beginning. So, what I decided to do instead, I decided to do plans and do specs. Uh and some of you may may tell like in our agents that
we use, they have planning mode already. And that's a valid point. You can have planning mode. But uh what I discovered that most of the agents uh when they work with big code base, plan mode uh may forget about some things or plan mode can lead to some issues because context is too big and agents can start hallucinating. So, what I found very useful is to split
uh development into big parts. First phase is when you do planning. Planning speak with your agents. Uh you can use techniques like inverse prompting when agent ask you questions because we all humans and we all know that it's way simpler for us to prove somebody wrong instead of helping someone. Imagine that uh on the internet someone said some stupid thing and you like, "No, that's wrong. I'm
going to comment about that." >> [snorts] >> So, same goes with agent. You ask agent to ask you questions and then you can answer those and it will be way simpler for you to work with. second phase is execution. So, it's pretty straightforward. The moment that you have a plan uh and your agent becomes a dumb executor. So, what what it what it does, it creates sub-agents
and fix the tasks. So, kind of like Ralph loop. Um And uh what benefit it gives to you that your agents can spawn sub-agent for each task and you will work at the beginning of the context and you will work with the most and best possible performance because what you want to have, you want to have your context as small as possible. So, we covered implementation part.
Let's talk about context hygiene. So, context hygiene, uh aka context engineering or context management, it's a set of techniques that you want to use to reduce size of your context. And uh funnily enough, when I was implementing my first queue, I had exactly opposite problem. I had problems not having enough tools. Uh and nowadays, problem is different. So, you have an issue that you have too many
tools, too many MCPs, too many skills, and they may do even the same thing. And what you want to have in order to not confuse your agent, you should think about what you put into the context. So, it's kind of same idea as like nowadays, implementations is cheap, and you should think a lot what features you want to put into your software. Same goes to the tools.
Don't put everything. If you have MCP for GitLab and skill for GitLab, and then I don't know, skill for Atlassian, skill for Jira, and uh skill for something else, they will confuse agent, and that confused agent may hallucinate, or even worse, it can do something wrong, and uh break the autonomy um the break the autonomy process. So, what specific set of tools for each service that you
have. Uh if you have a lot of time, you may have even specific set of tools or for the specific task a ticket you do. I don't have that much time. If you do, feel free to do so. second part of the second pattern is that you want to have your agents MD up to date. It's pretty straightforward. Create couple of skills and keep your agents MD
up to date. So, spend some time on it. It's not that expensive, but don't always remember that agents MD it's like telling your child to do something. Child can do that, but maybe it couldn't. So, same same same goes to the Agents MD is not a silver bullet. So, if you have deterministic rules, for example, I don't know, each commit should have a Jira ticket tied to
it. So, you should always use CICD guardrails for that. Because if you put that into agent MD, it may work, but it also will cost you some tokens, it will cost you some time, and it will also have always a possibility of going wrong. So, don't do that, please. So, if you have deterministic rules, move them to CICD. Or some other things like linters or other software
products. And let's talk about third pattern, which is building playgrounds. So, after I implemented first two patterns, quality of my code increased dramatically. And it was great with one big problem. I found myself, and I believe it's you know that feeling, when you constantly approving changes for the agent, or you're constantly telling agents, yes, you can do that. You can fetch this file. You can do that,
do this. And um this robbed me of one advantage that agents can provide. Agents should free up your time. You don't have to spend most of your time approving stuff. So, uh what you want to have, you have two ways here. One way is that you do you go Yolo and you let agents to do whatever on your laptop. Unfortunately, I cannot do that because uh we
we all want to book hotels and we all want to stay in that hotels and we all want to uh you know, have our payments processed. So, instead of doing that, instead of going Yolo, I decided to build a sandbox for the agent. And sandbox in my scenario, it's a Docker container. A restricted Docker container where agent works. So, same analogy with children. Instead of uh telling
your child what to do, you create a child-proof environment. Same Same as with agent. So, you create foolproof environment and if even something goes wrong, the worst case that could happen that agent will break a sandbox. And that's fine. This is what sandbox is for. in that sandbox, agent is restricted. It doesn't have access to anything. It doesn't have access to secrets. Uh it doesn't have um
it has no access. Just task and something that it has to do. I want to emphasize that uh if you put your agent into sandbox, it will give you it will increase autonomy of the agent and it will help you to spend time on something else. And fourth one, it's um remember that we are in our faf era, which means f around and you find out. So,
idea is that you want to f around as much as you could the most effective way because this is how you're going to find out. And if you don't find out, you won't get results. And this is the main no one knows what's the best practices are. So, what you can do, you can experiment with things. And what I found the most useful to experiment with is
autonomy of the agents. And I'm not alone. Anthropic engineers did the same thing. Probably most of you heard about MEEthos. And MEEthos is scariest model that Anthropic released. So, and what makes it so scary is it what uh what happens is that MEEthos wasn't taught to be so spooky to exploit stuff. But what what MEEthos was told to do is to be autonomous and has a high
level of autonomy. And this what um helped uh MEEthos to find exploits and execute some complex exploits with multiple zero days tied together, uh and um you know, escape stuff. So, you should do the same. Obviously, not break things, but you should build a environment for your agents which will help them to be uh highly autonomous. Has has them high autonomy level. And uh this guardrails and
this rules, it's not a prison for the agent. It's more like guardrails on a racetrack. So, agent will follow the goal quicker and faster. And this what will help you to deliver with higher level of autonomy. You can do other stuff while agent does uh the implementation. So, the main thought from this is that do not try to control the agent, control the environment, and shape agent
in only way that it can only uh go and fix the task that you asked it to do. So, to summarize what we have here, first of all, spend a lot of time on planning things. So, rule rule of thumb here is that the more on the left of development cycle you are, so in a planning phase, the mistake costs you most of the time. And the
more to implementation you move, the cost of mistake is going to be less. do the context hygiene. So, do the context management. Try to reduce your amount of MCPs that you use. Try to reduce amount of the skills that you use. I understand skills are pretty small, but uh keep them uh keep numbers in line. So, don't spend a lot of uh don't do not add a
lot of skills. It doesn't work, it doesn't Uh build a safe playgrounds because what you want to do, you want to tell agents what to do, and then forget about it. And uh say playgrounds the only thing that allow you to do so. And experiment with autonomy. So, what you want to do, you want your agents to highly autonomous and has high level of autonomy, so they
can do stuff for you and you can do something else. and that's all. Thanks, everyone. If you have questions, I don't know if you can do questions. If you feel free to scan my LinkedIn profile if you want to learn more about agents. So, I'm happy to help you master the agents. >> [applause]
