Stop Shadow AI Before It Owns Your Network | John Capobianco, Itential

As we all know AI agents are moving very fast. But when it comes to enterprise infrastructure is speed means nothing without trust. The real blocker is not building a smart agent. It is giving them safe access to real systems without losing control. And when it comes to agents and controls, these things are like oil and water. They're hard to mix. That is exactly what flow AI is built to solve. And today we have with us John Copy Bianca, head of AI and developer relations at initial to unpack how enterprises can bring AI agents into network operations with governance builtin from a start so you don't lose their capabilities or their trust and get full advantage of AI. John, it's great to have you on the show. So Neil, thank you so much for the introduction and uh you're right. We are entering a very uh exciting time. I would argue a time of opportunity and a time I think a Cambrian period. I think that uh you know I don't want to get too technical too quick but things like the model context protocol is maturing on 2 years. Uh open claw is maturing on to almost a year. uh things have moved very fast in the agentic space and um from individual contributors all the way to large enterprises. So I want to thank you for having me here today and I think it's an important discussion and um you know I like to think of agents almost as a brand new member of your team. Now my team was network operations and architects and um you know designers and security people and everyone who would make up the the team that would manage a network infrastructure. Imagine a new member of the team comes along. My very first task is not going to be a right activity of complexity on some critical piece of infrastructure. I think the same road map is can be followed with these agents in that they can be given readonly access. they can be given day one, day two tasks as if they were a junior or a new member of the team. You know what? Let's document the network. Let's test the network. Let's do some compliance reporting. Let's make sure that our, you know, if we have a source of truth offline that it's accurate and up-to-date and reflects the reality of the network. Let's maybe intercept tickets and try to triage them and add some summary, some analysis without making changes. So the agents have to earn our trust much like a new member of the team kind of earns the trust over time. We can introduce those change right activities where the agent takes on more risk and takes on more autonomy. Um you know a study was done recently by one of our customers and they found that 64% of their operators are doing readonly activities. 64% of a network engineer's job more or less is doing readonly information gathering. They're trying to troubleshoot a problem. They're trying to plan for a change. They're simply gathering information out of the infrastructure. So, why not hand that task off to a an agent that you're in control of and let the agent take care of 60% of your job, you know, and and actually summarize that data and give you root cause analysis. Um, I think we can take huge leaps forward. Uh, swap nil, >> can you quickly tell our audience a bit about initial >> is the agentic platform for enterprise operations. We make it easy to build and execute agents as well as deterministic workflows such as anible playbooks or Python scripts or Terraform jobs. >> What exactly is Flow AI and how does it help enterprises move from deterministic workflows to AI agents in network operations? >> Our Flow AI platform has two different interfaces. You can interface through a skill from Anthropic and do this through specd driven development where you describe in natural language the agent you'd like to build and the outcomes you want to achieve. And there's a traditional guey builder system that lets you input you know the persona of your agent, the outcomes of the agent. And what's neat is at build time we get to select the tools. So it's very safe. It's very full of guard rails. There's rolebased access control. There's OOTH 2 through our MCPS. So we're really excited about the flowi platform. >> When we look at network operations, what roles do AI agent play or what kind of problems they create? So talk a bit about AI workflows, the challenges and the opportunities they create in network operations. >> So the challenge is like uh introducing a new human onto your team, right? We have to make sure that they're following standards and methods of procedures and that they're following, you know, specifically change requirements. Um and I see agents very similar where you're going to incorporate them through readonly safe human in the loop activities. You know almost 65% of what a network engineer does is read only activities. So we see a nice safe onboarding experience for our customers to start incorporating agents immediately with huge value but very very low risk. Over time we start to increase the risk and start maybe introducing right operations. But some of the challenges are are that organizations need to have their own AI governance board and own AI strategy, approved LLMs, um data governance, quality of data. There's a lot of things that go into making a quality agent that are outside of our control. But we work with our customers to make sure they're binding the right tools, they're binding determinism, and uh have a really clean pathway to success. How is network operation different when it comes to AI and network especially? What is the real bottleneck? Is it AI's capability? Is it cost and token consumption? Or is it more about trust? And how does Flow AI address the safety and security concerns that keep agents stuck in sandboxes and chat box because they cannot be trusted enough to actually take actions? >> I think it does boil down to trust. It really does come down to trust. So we we feel that we have a track record and we can earn that trust through again a a road map through readonly activities, human in the loop, human on the loop and then ultimately human in the lead. We want humans to lead these agents. And we have things like role-based access control, things like AAA and audit and audit trails. So we can show you when and what the LLM reasoned as well as the tool and the tool payload that it called. You're in full control as a customer over the model you use and the provider you use. And it's also governed through things like OOTH 2 if you're talking about our model context protocol server with bearer tokens and fine grained access control. I know none of this sounds very sexy to the operator, but it sounds appealing to the leader of the enterprise. These are the things people care about. They're not going to just turn any agent loose that someone has made from an open source project on their network. Network is critical. Network touches everything. Maybe that's why it's a little I don't want to say slower, but more it's a little more hesitant, a little more prudent. Uh networks take a little while to adopt. We've seen the the the lack of adoption of basic network automation for the last 10 years. But I think this is different. I don't think enterprises are going to wait 10 years to adopt AI for network infrastructure. Uh the only advice I can give network operators and network leaders is talk to your peers in the software department that you work in. They have gone through this. They have gone through the pain of getting approved models and getting approved tools and getting access to these tools in a safe confined way. So bridge that gap. It's just like the network automation story. You talk to the developers about Python and how to learn Python and apply it to networks. Now we're doing the same thing except ask those developers, the pitfalls, the gotchas, what they've learned, how to use models, how to uh how to distribute tokens and access to AI. So I think that there's parallels here that we can learn from. >> Can you talk about the architectural difference between build only platform and initial approach of building the reasoning layer and execution layer together under the same governance model? So it actually lets us centralize and allows for a lot of reuse and a lot of um you know multi-tiered projects meaning you can bring let's say the PITS MCP server onto the gateway and now that server is able to host tools that are spawned asynchronously in in separate sessions from various agents. So imagine that, right? Or or let's just take for example the Netbox MCP server for a source of truth or Nbot or Opsmail. They all have MCP servers. Now you could bring those tools onto our platform and attach them deterministically to agents at build time and say, "Listen, I want to use PITS to get the state of my network, maybe IP addresses or interfaces, and I want to put them into my source of truth." That could be an agent. You and I could have built that and run it and have results in Netbox before the end of this conversation. >> We are living in a phase where there are many geopolitical crisis, regulations, governance and of course the whole FU around AI. At the same time there are movements towards sovereign AI. Now as I said the network is at the very center of all this movement. What role does flow AI play in better governance for regulated industries, complianceheavy industries? >> Well, I think it plays a big space in um you know, let's say combating shadow AI where AI is sort of distributed and people are using their own tokens and their own keys or or different models that haven't been approved. Uh we provide that platform and that ease of platform so people have a nice guey experience they can log into. They can use chat GBT or cloud code, excuse me, to chat with our platform through our MCP server or other mechanisms like our skill. It plays a critical role because we don't want just rogue agents. Imagine the sprawl of automation scripts for the past 10 years, distributed scripts, my script, your script, last versions of script, no version control, no source control. So think of our platform as that sort of GitHub for your agents. There's version control, there's source control. The other thing is is that um the model itself, we have a bring your own model approach and bring your own provider approach. So for those airgapped environments, for those environments that maybe are a little bit concerned about the the political overreach and models being maybe withdrawn or access to certain models or they don't maybe trust the cloud hyperscalers to handle their network information, you can bring your own lama server, LM studio server, Microsoft local server, foundry server and host your own local model in your own data center on your premises and our agents are more than happy to make the API calls and use those models. So, right, we want to we want to be Switzerland here and let people bring their own tools, bring their own models, bring their own providers. Uh so that way they can start building agents and start seeing the benefits of artificial intelligence in production. >> Let's go back to Flow AI and it's three core pieces. Flow agent, flow agent builder and flow MCP gateway. Can you talk about how they work together for infrastructure teams that are managing role based agents? >> Right. So the builder is going to be the the seamless building process that anyone can follow. Anyone can dump their domain specific knowledge into this builder experience either through the skill and claude code or through our guey. The gateway for MCP is going to allow you to bring your own MCP server. And MCP servers aren't necessarily just public facing. a lot of enterprises internally starting to make a lot of MCP servers available. So imagine bringing your in-house tools into a platform that then can be bound to the agent and then we have that execution runtime environment where everything is secure and uh you know extremely limited access where the actual agents are executing. Um, in terms of audit and compliance, like I said, there is an audit trail that shows you every decision or reasoning step that the agent may have made as well as the tools that they called. It has the token count and the execution runtime in terms of how long it took to run. So, in terms of compliance over time, right, these agents are being you can audit these agents. You can hand over exactly what happened. Maybe if there was, you know, if you wanted to see how it solved a problem, how it came to the conclusion of a certain problem needed to be resolved. All of that information is available to the operators. >> If I'm not wrong, you folks maintain the position that governance has to be built in at build time, not later at runtime. What does that mean in practice and where do human loop checkpoints fit in? So what we mean by that is sometimes so MC the the the LLM is going to reason and try to pick the best tool um but if it has access to too many tools or the wrong tools there's more of an opportunity for it to I don't want to say hallucinate but for it to pick the wrong tool or or be confused about the the selection of tools or use a tool that that has nothing to do with its its tasks. Right? So at runtime some solutions with agents just let the agent reason and decide what tools to use. We have a different philosophy over the governance of this and the guard rails that at build time when you build the agent that is when you get to pick what exact tools from MCPs or existing workflows or emails or slack or whatever you want for your communication stack. It's all at build time. So when the agent executes it will never call the wrong tool. And if you want to be very careful and do just readonly activities you provide it readonly tools. When you earn trust and want to add a right capable tool that's when you can do so. Right? So there's a lot of governance in the actual building of the agents. We have a lot of faith that they will do what they're supposed to do when they run. But but we can limit the blast radius. We can limit the exposure to our networks if at build time we actually select the right tools. >> For those enterprise leaders who are looking at agentic operations right now, what advice do you have? What is the best place to start without creating new operational risk and be ready for the future since things are moving so fast? >> So I would recommend that um you you know first establish an AI governance board, right? That's the first thing I would recommend to leaders if you do not have one. The other thing is I would strongly recommend you give your team access to local open-source free models that are private and local and let them start experimenting in labs, experimenting with virtual labs. Stay away from production. There's a long way to go. There's a lot to learn. But through virtual labs and physical labs and access to private open-source models, I would look for certain MCPS. I would try to integrate them into your co-pilot or your claw code. Right? So, it's more about accepting some of the risk and looking at the right tools and seeing how they can be applied and learning the lessons from your colleagues in the software development department. >> As Flow AI reaches general availability, what kind of real world use cases or deployment patterns are you seeing that resonate most with enterprise teams today? >> Right. So I did mention a few of them. Uh we we have customers doing a lot of uh ticket triage seems to be very popular. So a ticket come in through service now and through the MCP. The agent can read the ticket and then through other MCPs it can gather information and come to a uh much like a triage like an an early assessment before it goes to a human operator. So now that human operator maybe is saving hours of work doing the research into what the problem's root cause is. And the ticket just tells you we believe this is the root cause of the issue. Right? We could be wrong, but here's our evidence. Here's what we think. Here's what the information we gathered. Other things like testing, documentation are very popular. Sources of truth rec reconciliation to make sure that your offline records match the reality of your network. Um, and then even things like port turnup. Some of our customers are very large and have a lot of interfaces that have to be turned up or turned down over 24 hours. That's a perfect opportunity, a lowhanging fruit, lowrisk opportunity for an agent to step in and handle those port turnups and turndowns. >> John, thank you so much for joining us and sharing these insights on what it takes to make AI agents operationally safe for real enterprise infrastructure. Thank you so much for your time today and I look forward to chat with you again. >> Thank you for having me. I really appreciate it.