NODES AI 2026 - Building Secure Services with AI Agents: Patterns From Real-World Engineering

In this talk, the speaker, Marat from Booking, discusses the integration of AI agents in building secure services, particularly within the context of payment systems. He begins with a personal experience of testing an AI agent that unexpectedly attempted to modify his development environment, highlighting the risks associated with allowing AI agents unfettered access. Marat emphasizes the need for strict security measures when deploying AI agents, such as creating a Docker container with limited privileges and implementing a command whitelist. He also suggests utilizing multiple AI models for code reviews and maintaining human oversight throughout the process. The speaker concludes by advocating for a structured approach to integrating AI into workflows while ensuring robust auditing and continuous monitoring to prevent potential security breaches.

[music] >> Hello. Good day. My name is Marat. And yeah, I work for Booking where we try to build secure services with AI agents. So, and I want to start with a question. So, imagine that you ask security engineer about AI and AI agents today. Most usually you would get two reactions. First one would be horror because of this chain of attacks, all this awful things that

happen. Second might be some kind of excitement. But most of the people they pretty they they are not sure about the agents. So, I as a my experiences says, um security biased person, security heavy person, and I consider myself as a second person who does um I consider myself as a person who was biased against the agent. So, we work at Booking where I build and maintain

and uh design and implement our payment systems. And in our world, move fast and break things. It's not a motto. It's a threat. It's a security nightmare. It's a possible problems with compliancy. So, if you break things, people don't get on flights, people won't get their vacations, and hotels won't get paid. So, naturally idea of letting AI agents write whatever they want, whatever they think it's a

good idea, It's not a great idea. So, we need to think about what we want to put to production. And a year ago, I had this feeling like I was I was trying to experiment with agent and this is what happened. So, let me tell you what happened what exactly happened. I wanted to experiment with agents. I wanted to do something. Uh and I chose a super

simple basic task. I I asked agent, "Can you please update dependencies in my service and run some tests?" Super simple. Nothing should be broken. when I watched the log, I saw like agent tried to do some discovery. It found some dependency declaration files, pom.xml's. It updated versions, so it it it was happening as expected. It ran in and some tests, so but build failed. And then it

was asking for help. It decided to fix the environment. I looked away for the 30 seconds and when I looked back, agent wasn't editing my project anymore. It navigated to my home directory and tried to do some configuration with my build system. It tried to rewrite uh some RC files for my shell, so it tried to fix the environment and by the environment it was like my

whole laptop. And although it looks very suspicious and it looks like agent tried to do some nasty things, the reality is that it was trained to do that. It was trained to be super helpful. It was trained to be aggressively useful and try to fix the problem no matter what happens. So, I was able to stop it in time, but that moment felt left left me with

a choice. I either give up on agents or I can watch them constantly or sorry, I either give up on agents and watch them constantly and I don't have any automaticity and I basically have a new employees to manage or I build an environment, a system where it doesn't matter if agent can do a mistake or agent can uh break things. So, and that I tried the

first approach is that I thought that I could make agent uh teach agent educated to do good things. Uh so, create a better prompt, skills, or rules, or something else. Uh but this myth uh this is this called myth because it's not true. So, prompts are not guidelines. They are guardrails. So, if you look on the left side, you will see that uh if you put this

into the prompt, you might think that agent will stop doing mistakes because you ask it to do, right? So, it should uh value that. Unfortunately, it's not true. So, and reality is that prompt injections may happen all the time. Agent act probably agent agent are not deterministic. So, you don't know what may happen. You can put uh something and uh you cannot predict the result. It may

uh act unpredictably whenever whenever it happens. So, yes, prompts are not uh guidelines. They are guardrails Sorry, prompts are not guidelines. They are guardrails, not guardrails. Prompts are guidelines, not guardrails. Uh if you rely on prompt to stop an agent from hallucinating, your library or putting back into your code, you don't have security strategy. You have hopes and prayers. Models are not deterministic. No amount of instruction

will make it 100% reliable. So, if we cannot trust the brain, we must constrain the body. And solution for this is to build a playground. In technical terms, playground is a Docker container with strict privileges. So, you have restricted file system. Agent can only see work directory. It literally cannot see anything else. So, there is no scenario where agent can escape and do some problems on your

Second one is you make a command command whitelist. So, you drew the line here. If you make it too restrictive, agent won't be autonomous. you won't be able to to get the all benefits that agent can provide to you. If you make it too loose, that there might be a problem that agent can do unverified stuff, and it can create some problems to you. Mhm. So, yes.

And uh this third one, the most important one, is that mhm under no circumstances, please do not put credentials into the agent context. So, credentials should live in a separate secret managers, and agent should never see any long-lived tokens, anything, any credentials. So, when you treat your environment as a hostile, the agent can then stop maturing. It can try to be malicious or super helpful as we

decided or just stupid, we don't know. But, the result is the same, access denied, it cannot break anything. And also, it gives you a lot of automaticity because you can do other stuff while agent do do its work. So, we have agent in the box and it cannot burn house down. Uh it can still write buggy code inside this box. So, and we need some kind of

security review. This brings us to the second myth that AI will replace uh security review. Some people think that AI is so smart and can do security review for them. Other people think uh that there is no way that AI can be trusted with security because it can do some reward hacking or it can try to find something which is not real. So, and both are wrong.

I would say the answer is uh council, not a single authority, and you should work with your agents and with your LLMs to do the So, you should trust the number For example, I use multiple LLMs to review important code. Because one model can start reward hacking without any reviews. So, and they just color review called council. Uh you probably heard about it because that was uh

one of ideas from Andrej Karpathy. Uh I took it and I decided to play with that and here what I have. Uh so, think of it as a medical consultation. You don't trust one doctor with with serious diagnosis. You get second opinion, maybe third. In my scenario, I have three experts and each expert is powered by four different elements. So, I have 12 opinions. Uh and here

you can see roles. So, first one first role is like uh security expert, PCI expert that follows standards regarding some payment industry. Second one is a reviewer uh as of course quality. What happens with the code? Does it have some smells? Does it have some problems and things like that? Um Uh and arbiter. So, arbiter uh waits uh the opinion of other el- experts and try um

give you a consolidated report. So, and obviously you have a human, yourself, in this loop and you make the final call here. So, don't leave everything to agent. Uh uh Try So, it's it's your decisions, it's your responsibility, and it's your artifacts. >> [clears throat] >> roles can be powered by multiple LLMs. They discuss, they challenge each other, and at the end arbiter uh returns you the

result. Uh let's check the whole agentic workflow as we have it so far. So, we start with brainstorm or research or content or context discovery uh or something else, domain exploration. Uh this stage is about uh gathering knowledge, collecting knowledge. Uh on this stage uh you can use this uh prompt pattern as inverse conversation where you ask agent to ask you questions until the whole context is

clear. This is very useful because I know It's hard for me to formulate what I want to have, but when someone asks me and it's wrong, I obviously can say like, "No, that's wrong. I want this one." And this is why you use this inverted conversation pattern. So, you want agent to ask you questions and these questions should be in the main domain that you explore into.

This is why you also need an After you finish this brainstorm, you can do a plan. So, you break your design into small verifiable bite-size tasks. And um you store it in your repo. Third one is execution. Super straightforward. So, you let your agent handle the tasks one by one. You can try different approaches. My favorite one is sub agents because uh each sub agent has a

clear context and you have the best performance that you might get out of the agent because it has empty context. Uh and compared to other things like uh you continue in the current context. Uh this will give you the best performance. It comes with overhead because this uh orchestration of agents costs you some time and resources, but for me, for big tasks, it's the most beneficial one.

And the last one, you do review. So, you give your task to console. Uh console reviews reviews it and um comes with a verdict. Uh idea here is that now we have uh this brain in a plug. So, we can get the knowledge capab- capabilities whenever they we need them, and we should utilize that. Okay. agents are not replacing us. They amplify our capabilities. So, I can

deliver more, I can do more, I have multiplied productivity because of the agent, and I serve as a expert matter expert, so I can provide um knowledge, I can provide context, and agent can quickly amplify that and multiply that. we thought about everything, right? So, we have playground to contain blast radius, we have console to check quality. Uh but I work in fintech for almost 10 years,

and I know one truth, if something go wrong, eventually it will go wrong. So, we need to be ready for this, and as uh Scott said, uh you cannot prevent every incident, but you can prevent every untraceable incident. So, it's our responsibility as engineers do audit, and this is essential things. So, we should be ready for this, and we should um we should collect the most artifacts

that we can have. So, this will help us uh in the future incidents to diagnose things, to understand what went wrong and how it went wrong. So, when agent makes a mistake, it's super hard to debug it because you need to know what is was what is was what it was thinking. Uh so, you need to record chain of thoughts. You need to to record logs of

sessions. If agent tries to escape playground, you need to be aware about that. And you want to know what prompt may trigger and lead to the section. So, audit is answer to everything. Please try to audit as much as you can. And also, don't forget about chain of chain of attacks. And this other things that you should be looking into. Like, you please don't use skills that

you don't know of and things like that. So, here you can see that in this pipeline, you create as many artifacts as possible. So, you want to have as much artifacts as possible. You want to have plans. You want to have design dogs, tests, merge requests, Jira tickets, some other things. So, you want to have a lot lot of things. This brings us to myth number three

that this whole thing is too hard to start with. this playgrounds, rules, councils, audits, it sounds like a lot of work. And we all like we understand that it's a good idea to have it. But sometimes we need to work with business and business don't have time for that. what we going to do about that? you can start simple. Uh you can start with super small thing

that will take you literally 5 to 10 minutes. You can create agents.d. Uh this is standard that supported by most of the agents. And a lot of them provide you with commands that can gather context and uh create this file. So, this your step Uh then, you can find some routine things in your day-to-day activity as a team, and then you can move those things into the

skills. So, you can can specific For example, you can have specific uh Git commit rules in your team. So, make it as a skill. As a result, you will have reliable output from your agents. And the more skills you have, the less friction and the less amount of time work will take you. Uh and then, when you have uh most of your routine things covered by skills,

you can go to fully agentic workflows when you just provide agents with some context and knowledge about domain, and agents can do the implementation for you. So, and later, when you mastered uh the agentic workflows, what could happen is that you can run multiple agents, agents forms, teams, or even clothes that you can uh react on whatever happens in your Jira tickets and things like that. So,

experiment with tools, uh explore tools, explore different approaches uh because everything changes rapidly, and now we at the era where we can automate automation. So, and we can quicker, quicker, and quicker. So, to summarize uh all this, uh let's talk about checklist. So, first one is no secrets in agent context. So, uh your agent should never see any tokens, any secrets. So, you should It should be

isolated. There are different techniques. You can do reverse proxy and things like that. Uh but yeah, be aware of that. Uh build a playground. Don't try to prompt agent into behaving because prompts are not guardrails. They are guidelines. So, it's good to have, but it doesn't mean that it will happen. Keep human in the loop. So, be aware of what's going on. Don't try via coding because

via coding doesn't scale. Uh if you want to build secure systems, you should be aware of what hap- what's happening. Of course, it will lead into decrease of productivity, but uh the benefits are essential because you don't know what happens with your project. And this is the most important stuff. Do cross-validation with a console. So, as I said, you have brain capabilities uh in your socket with

the modern LLMs. So, think about that. Uh try to outsource as much analyzing as you can. Uh and this will help you to save your precious mental resources to something Audit everything. Prompts, calls, sessions, every artifact, every decision that agent made uh because you may need it in the future. And it's better to save it and store it for the future's sake. And start simple, move in

your pace. yeah. Uh move in your pace. Experiment. Everything changes rapidly. So, just be ready to unpredictable future. Yes, stop being afraid, build playground, and uh build uh have a secured uh applications built with those. >> [music]