Latest / TeqTalk with Jas / Enterprise AI Agent Integration Explained: MCP, Tool Gateways and Security

Transcript

Enterprise AI Agent Integration Explained: MCP, Tool Gateways and Security · TeqTalk with Jas

• speaker-0: To be honest with you, I think it's going to become a much bigger problem in the next 12 to 24 months is prompt injection attacks. speaker-1: Yeah, I think that is scary as well because the real security change with agents is a blast to radius. How I was mentioning before that a manipulated chatbot will only give you a bad answer, but manipulated agent can potentially take bad actions on your behalf. I have been reading the cases and one of the latest cases was about Microsoft that showed this year that a malicious prompt could really influence tool executing it strongly enough to remove the remote code. execution. So it's it's scary, it's happening and speaker-0: companies are split into two camps. Either they've completely blocked access to AI from either at all from touching tools or at the very least they've blocked the ability to write back into systems. They say you can read but you can't write. The other camp are the ones that don't have any controls in place. speaker-1: The real question comes when what exactly can the agent do, which records and fields it can really access like how you just mentioned, and under what conditions? speaker-0: What is different between a human and an agent as you said is the speed at which they can operate. So in 2025 we just raised our series A. Thank speaker-1: Congratulations. speaker-0: you yeah. speaker-1: My guest today is Romain Sestier, co-founder and CEO of Stack One. Romain is working on one of the important infrastructure problems in enterprise AI. How agents can securely connect to and act across business systems. Before Stack One, he spent years across SaaS and Big Tech. Including Google, building products at scale. And the problem that kept coming back was integrations. They were expensive, fragmented, and endlessly repetitive. Later, while Romain was at Google and working with early LLMs, he started asking a pretty simple question. Could AI change the way integrations are built? That became the part of thinking behind Stack One. And in 2025, the company raised a 20 million. Dollar Series A led by GV, which is Google Ventures, bringing its total funding to twenty four million dollars. Thank you so much for joining Tek Talk. How are you doing today? speaker-0: I'm great, thank you for having me. speaker-1: Absolutely. Let's deep dive. One thing I find very, very interesting is that integration has always been one of those problems that looks very simple from outside, right? But it becomes incredibly expensive once you actually start scaling. And now the situation has completely changed when you're using agents. Every new system means every new API, another authentication model, and another set of edge cases. And when you have lived that problem from Decades, right? You stop seeing those as plumbing problem and start seeing more over infrastructure layer as well. I was reading about Stack One. Stack One itself says that you and your co-founder saw this over more than a decade building the SaaS products together. So Romain, take us back to those days. What exceptionally you were working on and what changes you have seen in the market. What made you really build this? Products tack one. speaker-0: Yeah, absolutely. Well, so first of all, what people don't always know about me and my co-founder is that this is the fourth company that we're working at together. So we actually worked together at three other companies previously. I met him at a software company that ended up being acquired by Oracle. And then we worked at other marketing technology companies. And one of the common problems that we faced was building and scaling integrations for the product that we were. building. It was really crucial because our customers were asking for integrations, our partners were asking for integrations. There were battles over who should be building the integration when you're partnering with another company and every time it ended up being expensive, a lot of money left on the table because you're missing potentially months of collaboration work together because the products don't work together. And even when it launched, sometimes it wasn't there. yet because to build a really good high quality integration takes a lot of work. need to make it bi-directional. You need to make it real time. need to, you know, and so a lot of the time slapping the logo of the integration on your website is not sufficient to kind of build a good product. So that was the, that's really how Guillaume and I, that was the context of, of how Guillaume and I kind of felt about integrations before. And then the trigger really happened when I was at Google. And I started working in a sector called area 120, which is Google's labs division with an applied AI. And, and I started touching LLMs and the idea was, can we fix this problem using LLMs? And at the time it was the era of GPT 3.5. So it wasn't particularly advanced, but we thought, you know, this has potential to ultimately eventually with the right infrastructure around it, potentially solve the problem of integrations. speaker-1: So you started Stack One as an integrating platform, right? And and from there the journey moved on further to AI agents. speaker-0: Yes, that's right. And so the idea behind StackOne was pretty simple at the beginning was, can we somehow cut it down from months of work to just a few hours or a few days of work to build integrations? And so initially StackOne was built as the deepest, what was called at the time, unified API. So we were literally mapping the APIs of hundreds of different systems to standards and unified standards that we would create. and selling it to software companies that were building integrations to other systems. And that evolved into what we are today, which is people using agents within their companies and using various AI products need to connect it deeply into all of their AI systems. speaker-1: Yeah. And I think the move is very strategic as per the time, I would say that. And what feels different right now is that the users increasingly give software an outcome, not a sequence of clicks. For example, when you say onboard this employee or resolve this customer issue, that can involve five different systems. And path may change depending upon the context as well. And especially when you have AI agents, it becomes very complicated in that terms. And that starts to challenge an architecture which is built mainly around the predefined workflows. So things have been evolved a lot now. So what change in the market or in the customer behavior that made you realize that AI agents needed a different integration layer than traditional integration platforms? speaker-0: Yeah, to be honest, it was when the moment happened kind of last year. So in 2025, we just raised our Series A. speaker-1: Congratulations. speaker-0: By the you. Yeah, it's been great. So raised the Series A, a lot of people signed up, reached out to us, and we started noticing that the buyer was different. Instead of being software companies building software, was companies being like, you've got a workday. API and it looks easy to use. I give it to my agent? It wasn't even agents at the time. was just like, can I give it to an LLM, so that it can call it. was right at the big MCP was just coming out. People were excited about it, but really nothing really mature at the time. And it was a bit of a leap of faith for us to, realize, okay, the unified layer is not needed anymore. Agents are able to comprehend it and actually needs the depth of information that is provided by the underlying API. So we actually ripped out the unified layer and we exposed the really powerful essentially engine under the hood that was powering the integration. So we've now got over 540 connectors, 33,000 actions on the platform and all of these are designed specifically for agents to call them. But I think to answer your question about when did we realize? think it's the buyer behavior changed and they were asking, I need to access this specific field that only exists in Salesforce or only exists in my custom fields, et cetera. Combined with the fact that letting agents access your systems brings out a host of new challenges to solve. We felt like this was a really interesting space for us to... focus on and build things around security and build around token optimization, et cetera, which you don't really have when you're dealing with just pure API integrations. speaker-1: I think it is one easy mistake to say that we have APIs for the platform integration issues resolved, right? But APIs initially, if you see the history, it was developed for the developers who exactly knew what the endpoint was and what exactly they want based on their use case. And if you talk about the agents, the agents may be choosing one amongst the hundreds or or thousands, right, of those. possible capability. So it's hard shift from connectivity to finding, constraining, executing the right action. Let's talk a little bit on the architecture of Stack One and also for my audience, explain why enterprise simply cannot give AI agent access to their existing APIs and what are the differences. Stack one is embedding to make the work easier for the people working in the enterprises. speaker-0: Yeah, absolutely. maybe just to start with, StackOne is what we call a gateway. So we are a middleware platform. We sit between the AI tools that need to read and write into enterprise systems and those enterprise systems, APIs and MCPs. And so what is the problem? Why can't you just give an agent access to APIs? The answer is really that they were not designed for agents. And I think that's the same realization that we made when we, when we evolved the product last year for StackOne to be dedicated to agents is that if you give an agent an API spec, it's going to be inaccurate. It's going to cost a lot of tokens. You have to deal with all the authentication. So there's a lot of infrastructure, deterministic infrastructure you have to build around calling these APIs. And, and that's exactly what prevents agents from just calling an API directly. just that it just can't figure it out. And I think, yes, maybe simple APIs like your calendar API or something like that. There's not that much complexity, although we'll get to it in a second. But when we're talking about enterprise software, you're talking about Workday, SAP. Oracle, they've got thousands, if not tens of thousands of API endpoints. They've got customizations. There's really sensitive data within them. So you can't let the agents kind of do whatever they want. I'll kind of extend your question a little bit because I think you can't give it agents access to APIs. Similarly, you know, when MCP came out, it was It was hailed as this all of a sudden agents can talk to all of your systems, but the reality of MCP, think is the same as API. I think to your point, it was designed for developers. MCP, MCPs are essentially an abstraction layer over these APIs. However, they're designed in a generic way. They don't necessarily expose all of the complexity or all of the actions that the underlying APIs can. And on top of that, they don't have any security feature. They don't have any ways to optimize them. And very quickly you realize that's easy. MCP is there. And then you realize, but I can't give, you know, hundreds or thousands of tools to my agent because the context window runs out or my agent becomes really bad at calling the right tool. you were saying. And so my Really where we are today is that enterprises are realizing, yes, this is really powerful. And yes, we want to connect all our tools to these different systems. But there's something missing in between. We need connectivity and we need governance. speaker-1: So stack one is the whole layer. So in simplest terms, when there is any work which is given by any user to the LLM, for example, find out who is the manager of jazz, right? So this is going directly to the gateway, which is stack one. And based on the different tools available, it's the gateway which will identify which tool has to be found out from which platform and provides the answer. Is my understanding correct? speaker-0: Yeah, that's exactly right. So StackOne is like an assistant to your assistant, so to speak. Claude or Co-Pilot or Glean or Gemini Enterprise, when they're connected to StackOne via MCP, have access to new functionalities thanks to StackOne, such as, tell me what you need to do. This is literally what we say to the agent. The agent will tell us, hey, I need to search for manager by employee name and I need to search by email address or I need to, know, whatever the agent has access to at that point. And StackOne responds with these are the tools that are connected that this user has access to and has permissioned you to access at that point. And then the agent says, yep, perfect. The first one or second one is what I need to call, call StackOne and then we execute the underlying architecture. the security, we secure the calls as well. can scan to make sure there's no attacks coming through, et cetera. And then we respond to the agent. So we essentially give the agent a secure way to access the key information and act within the underlying systems of various companies. speaker-1: I was going through your website and it also says somewhere that it reduces eighty percent of your token prices. speaker-0: So where do token costs come from? It's kind of the main question, right? So I think a lot of people think token costs come from the models only. by choosing a cheaper model, you're going to reduce costs. Obviously, yes, that is one way of doing it. However, I think they're missing sometimes the point, especially in enterprise applications. They're missing the point that, you know, they're a financial analyst or they're a marketer or they're a product manager and they're throwing... millions and millions of tokens of context into the agent's context window and not realizing that this is kind of adding to the cost. Because whenever an agent is calling your call recordings or searching for emails or searching for tickets, et cetera, it's kind of loading all of this in the context window in order to decide what's relevant or not. The way that StackOne works is because it sits between the agent and the tools, we have the ability to pre-process the data before it hits back the context window. And so a couple of examples of this is that, as I was saying earlier, instead of giving all the tools upfront to the agent, which breaks the majority of agent platforms out there, we dynamically release those tools specifically for what the agent's trying to do. Another example is that we can pre-cache the data from underlying systems like your HR system, your finance system, et cetera. in a secure database so the agent can actually just do queries on that data, even if the underlying API doesn't allow it. So without going into more technical depth here, at a high level, StackOne essentially pre-processes a lot of data that never hits the context window, and we only give what's relevant for the agent. And so that really saves a lot of tokens. That's another strategy to save on tokens for very data-intensive tasks. speaker-1: I think this is so important because a lot of places, a lot of enterprises, the first thing being discussed is how to reduce the price or how to go nominal in pricing. It's so h easy to hit the token limit, right? It you wouldn't realize and it's all gone. So where do you draw the line between that what a model should actually reason about and what infrastructure should it completely hide from the model? speaker-0: Well, at a high level, I think there are some lines that you can draw fairly easily. Security should be deterministic, right? So I think things like guardrails, permissions. I speak to so many enterprises today that are like, literally can't give access to AI. And some of the biggest companies, I can't name them, but I can tell you that some of the companies that are selling agents to their customers can't give access to their own employees. to their own systems because the IT teams and the security teams realize that there's some risks. so I think that, and so they're all kind of looking for platforms like ours that are a gateway that kind of protect the cause and help them to enact governance. And so that needs to be deterministic in order to have true adoption within the enterprise. I think we're gonna get to a point where there's some flexibility around like maybe we can... have some of the newer models like Jev and Clef that can potentially make some decisions as well. That's the direction that we're going into with our policies. I think, however, where there's a little bit of flex between the model and the infrastructure, I'd be curious to hear also what you see, but what I'm seeing is that sometimes in order to reduce costs, increase accuracy, increase speed of agents, you can have a very expensive model that does the decisioning or the planning and then some smaller models and maybe some smaller pieces of infrastructure like pre-existing workflows, et cetera, that can execute those tasks. And I think that's a common pattern that we're seeing as well. But the only one that I think really needs to be deterministic in the infrastructure is security and some token optimization and pre-processing of the data. speaker-1: Yeah, that's what even we are seeing and you touch based on JEV. So that's pretty interesting kind of model which has come up and a lot of hype is being there. And I I I I believe it's gonna be a token saving or optimized way of getting yes no answer or things which are already determined. What kind of security and identity and governance measures you are putting in the stack one? speaker-0: Well, I think that the simplest answer is that literally right now companies are split into two camps. Either they've completely blocked access to AI from either at all from touching tools or at the very least they've blocked the ability to write back into systems. They say you can read, but you can't write. The other camp are the ones that don't have any controls in place and are very scared about shadow AI use and people connecting MCPs and, neither is better than the other because on the one hand, you're kind of losing out on a lot of potential productivity gains for your company. And on the other hand, you're potentially exposing your company to a lot of risks. And so like what makes the biggest difference with stack one and why When people reach out to us, the main reason is they need to be able to put in place guardrails that allow them to give their employees the freedom to experiment and to actually be productive with AI without carrying the risk for the company. So a couple of examples of this is you need user level permissions on all of the connectors. You need what we call policies, which are essentially rules that govern, you know, agents that are built by people from this team can access such and such information down to the field level or can write pricing on a quote, but they can't put the price higher than X amount, for example. So if you can import these policies, if you can build these policies within the middleware layer, you can enforce them by your agents, regardless of where the agents run. That's really the value. so it changes from a world where they are they have to make a choice between shutting everything down or letting the risk go wild to a world where they're able to find a better balance between the two. And they're actually able to confidently roll out AI to all of their employees. That's really the key thing. And I think security and in general identity is such a complex topic when you think about agents taking actions compared to just agents reading that it needed a new kind of tooling. specifically designed for this kind of use cases. speaker-1: Yeah, and I think eventually we need something close to an employee record for an agent, right? Who actually owns it, why it exists, what systems it can access, and when that access should be removed, reviewed. I think that's already started to happen in the identity governance space as well. speaker-0: The way we think about it is that it's a multi-layered approach. have the agents have access to at the most what the employee creating these agents has access to. That's kind of the bare minimum, but that's not sufficient these days. Now you need to also look at agent identity and restrict further the agent's purpose and the agent's kind of the reason that the agent was created. Does it need to have access to all of these extra tools? So being able to add a layer of governance on top of that. And then on top of that, you have policies done to field level or done to, know, what if there's a prompt injection attack? Does it matter for this agent? Does it not matter for this agent? What's the risk? What's the blast radius that you're expecting for this agent or for this person? speaker-1: saying this agent has access to work, right? Is too broad. The real question comes when what exactly can the agent do, which records and feels it can really access, like how you just mentioned, and under what conditions? It's so important to know. Agents may actually need much tighter controls than humans. Agents can act in a larger scale. So it becomes very difficult to control them if anything bad happens. So a little bit Let's touch base on how granular should agent governance become. For example, allowing an HR agent to access employee information while preventing it from seeing compensation or other sensitive fields. speaker-0: Yeah, that's a really good, really good point. think what is different between a human and an agent, as you said, is the speed at which they can operate and the fact that they can connect dots way faster than a human would. And so what I'm hearing from CIOs and IT leaders, their main concerns, obviously you could be worried about a lot of different things, but I would say that their main concerns are generally that number one, an agent should not be able to see certain pieces of data or write certain pieces of data. So a good example is we have a lot of customers in the healthcare sector. These customers have HIPAA compliance regulations. They need to be HIPAA compliant. So they can't expose certain fields from their clinical research software, from their HR software, et cetera, to the LLMs. That's just not something they can do. So at that point, you need to add a layer that filters out what comes back from the API and it needs to be deterministic because if it's not, you are non-compliant. So that's one example. Another thing that I'm hearing a lot is how do I make sure that everything is tracked, right? Because you, yes, with humans, we have logs, but with agents that take way more actions by volume, you need to be able to... review these logs and analyze these logs to detect and especially prevent malicious or ill-intended behavior. And we have a whole team dedicated to what we call agent alignment. detecting when the agent is straying off what it's supposed to do. And then the final piece, I think, to be honest with you, I think is going to become a much bigger problem in the next kind of 12 to 24 months is prompt injection attacks, which I know you wanted to talk about as well, but prompt injection, I think is just beginning and I think will become a much, much bigger thing over time. speaker-1: Time. Yeah, I think that is scary as well because the real security change with agents is a blast to radius, right? How I was mentioning before that a manipulated chatbot will only give you bad answer, but manipulated agent can potentially take bad actions on your behalf. And prompt injection, which is no longer new, I have been reading the cases and one of the latest cases was about Microsoft that showed this year that a malicious prompt could really influence tool. Executing it strongly enough to remove the remote code execution. So it's it's scary, it's happening. And there was another report which came from OWASP. Now they have dedicated top 10 for agentic applications. Essentially a it's a kind of security checklist basically that is covering all the risk prompt injections, excessive permissions and tools execution before actually agents have to move live to production. So they have that checklist. Prompt injection is a big topic which is going to start. People will be watching it closely. Next twelve to twenty-four months are very important. What kind of preventive measures have you taken in stack one? Make sure that, all these security things, prompt injections, agent sprawling is being controlled. speaker-0: So the two ways to fight prompt interaction, broadly speaking, are either you don't give access to the agent to do anything bad, which is kind of like we're back to square one. possible in other cases. Or you figure out a way to outsmart the attacks. And so when we started looking into this space, Last year, we realized that actually prompt injection has a totally different shape depending on the company, depending on the industry, depending on the use case that you have. Like, for example, if I ask you to send me your sales pipeline for a fictitious meeting that we have next week, who knows if this is an attack of me trying to, you know, like get your agent to send me some sensitive information. And so we realized that there's a new prompt injection defense models that needed to be created that are more specific to the specific use cases. So at StackOne, given the type of tools that we expose are kind of work tools, B2B kind of enterprise tools, we actually created our own datasets and trained our own small models to have a much higher accuracy on the types of attacks that you see already today, but also potentially in the future. in enterprises. it's things like related to sales performance, financial performance, employee information. And we actually open sourced this product called Defender, which reached a higher accuracy than all the other open source models on public benchmarks, as well as on our own benchmarks, and is also significantly smaller because we were able to create a different type of architecture for this model. And so I think this is where it's going. think ultimately you will need to have this the same as with cybersecurity out there and malware prevention, et cetera. Can you catch a hundred percent? No, but can you catch what is the difference monetarily to your business if you can catch 95, 99 % instead of 85, 80%. That's really where we're trying to get to is provide the best defense possible through the best model. speaker-1: So you mentioned Defender, it's a different platform or it's integrated with the stack one platform itself or speaker-0: That's a good question. is both. Defender is given for free as part of all of our connectors, actually. So whenever you use a StackOne connector or even when you bring your own MCP into the StackOne gateway, we run Defender on every call. And we believe that it should become table stakes for any company. And that's why we've also open-sourced it, because we think it's important. However, we also commercialize Defender as... a separate product that you can purchase if you want to embed it inside of your platform. And I think one thing that I keep hearing as well around prompt injection attack and what I'm seeing is it's not the one agent that you're spending, you know, team of 10 people building that's going to have the highest risk because you're going to have the resources. But I'm seeing a lot of companies companies saying, we've got thousands of agents out there built on, clean or like any, any other kind of agent building platform. Some of them include prompt injection defense and they're, really good. However, the fact is that people are building, you have citizen builders everywhere that are building agentic products, giving them a lot of access and. So it's completely unmanageable if you're, you you can't look at one single agent and say, yeah, I've secured it and think that that's the end. need to have a much better security for even citizen built agents where you don't know what they're doing and you don't know how they're working. speaker-1: One area which I've been thinking a lot about is we need to have common platform where the agents are being monitored, reviewed, you know, hundreds and hundreds of agents are being launched. There are a lot of enterprises they are just pushing up now with a couple of agents and will be going to hundreds of agents in coming years. So that those kind of platforms can really help in having the end to end visibility of what actually is happening and that'll make difference. speaker-0: Yeah, I completely agree. Well, I think that, it's, it's a similar situation as with the iPass industry a few years ago, you know, where you had people initially connecting systems together, but you had no governance. You didn't know what data was going where it was impossible, especially for financial system. When you're a public company, you have to report anything that touches these financial systems. You know, there's so many reasons why it becomes a mess when you don't have a centralized control plane. I really believe that, I completely agree. speaker-1: Yeah, at Tech Focus we are building a platform. It's overall the workflow intelligence platform. And we named it as Agently. I'll talk about it later, but it today we are talking more on the stack one. So our focus is on stack one. Romain, tell me what's happening next. What are the upcoming features? What is your vision for next year for stack one? speaker-0: We're doubling down is the short answer. So StackOne is the platform that lets your agents securely access all of your enterprise systems so that you can confidently roll out AI to all of your teams. I think we're just getting started. So there are so many really interesting areas of research around security, around accuracy of agents and around token optimization. These are kind of the three things that we focus on at a very broad level. around security. I mentioned it at some point during the podcast, but agent alignment is really interesting. Like how do you make sure that the policy is not only just within the conversation, but more broadly within your company and within what the agent should do are enforced. So we're researching, we have some really exciting products coming out there. We have some new products, new features coming out with regards to improving the accuracy of agents when they're calling actions so that not only they're faster and they take fewer tokens, but you're able to extract better information from your own data and therefore have agents that give you better insights and take better actions within your systems. And finally, there's some really interesting products that we're working on at the moment around token optimization. That means that you'll be able to do enormous workloads with agents that currently with current agent harnesses you're just not able to do. And so all that is coming out later this year or early next year. speaker-1: Great. So looks like very exciting year coming ahead for you. speaker-0: Yeah, for sure. No, I'm very excited. speaker-1: Great. Thank you so much, Romain. And the big takeaway is that enterprise is moving from intelligence to execution. Enterprises have moved, I would rephrase their statement. And once agents can actually start to act inside the core systems, the conversation changes completely. It's no longer about which model is smarter. It is more about how safely we deploy, how reliable our agents are, what is the visibility we are getting in terms of intelligence and Interaction with different systems, right? The connectivity, integration, identity, permission, execution, governance, all of these are no more the back end plumbing. They are part of infrastructure. So speaker-0: This friend. speaker-1: core infrastructure. speaker-0: That's right. I'll tell you, I'll leave you with this. Last week, I got an email from the CFO of one of our clients, which is a $200 million healthcare organization, who told me that we weren't charging enough. So that's, that should tell you a lot about the feedback that we've been getting has been really strong from companies. think they're very excited about what they're now able to do. And that's been the most. exciting thing for us in the last year or so of our journey is just seeing the change that we're driving inside of these big companies. speaker-1: This is real and this is actually what is democratizing. You are making a product that is cheap and effective. And so that's the real definition of democratizing. Thank you so much, Romain. It has been a really, really thoughtful conversation. speaker-0: Thank you so much for having me. speaker-1: cue.