As companies move more of their operations to the cloud, one of their biggest security challenges is no longer simply protecting infrastructure. It’s determining who can access what, under which conditions, and how to enforce those decisions across thousands of users, applications, and interconnected systems. A single weakness in identity governance can create vulnerabilities that extend far beyond one application, making access management one of the most consequential architectural decisions in modern enterprise technology
“Few engineering challenges illustrate this complexity better than implementing identity federation at enterprise scale. Kishor Patil, a Senior Engineering Manager, has spent more than 16 years working in software engineering, including over seven years specializing in Google Cloud Platform.
As an IEEE Senior Member and peer reviewer for international technical conferences, he also contributes to the broader engineering community’s evaluation of emerging technologies and approaches. His experience offers a valuable perspective on why cloud security cannot be treated as an isolated technical function, particularly as enterprises adopt increasingly distributed architectures and more sophisticated access models.
In this interview with IntelligentHQ, he explores the engineering decisions behind secure cloud transformation, the growing importance of identity federation, and what organizations often underestimate when designing security architecture for complex enterprise environments. From managing access across distributed systems to building infrastructure that can adapt as organizations grow, he examines the technical and organizational choices shaping the next generation of enterprise cloud security.
You have more than 16 years of experience in engineering, including over seven years working with Google Cloud Platform. What major shifts have you seen in enterprise technology during that time, and how have those changes influenced the direction of your own work?
I started my career as a developer and automation engineer. I wrote code, shipped features, and cared mostly about whether the application worked. The servers underneath were someone else’s problem. You asked for hardware, you waited, and a release was a big event where people stayed late to make sure nothing broke.
Then things started to change. The cloud turned infrastructure into something you could write as code, which suddenly made it feel close to my own world. Kubernetes also changed how we run applications. Now AI is changing it again, and honestly this one is moving the fastest.
What I noticed is that every time this technology got faster, the same question came back: who is allowed to do what? As a developer I used to think about that last. Over time I moved from building applications to building the platforms they run on, and that question kept popping up. I did not plan it, but it slowly became the center of my work. Today, a big part of what I do is exploring new cloud services and making sure teams can move fast and stay safe at the same time.
Your career has expanded from broader engineering and distributed systems into cloud security architecture and identity governance. What drove that evolution, and why have identity and access become such important parts of modern cloud infrastructure?
Security is a big part of my work, but it is not the whole picture. A lot of what I do is discovery. When a new cloud service comes along, I try to understand what it does, how it fits with everything else, and what it takes to use it well. I look at it from a few angles: is it useful, is it practical, and is it safe.
Coming from development helped. As a developer, I know how tempting it is to ask for broad access just so the code works and you can move on. I did it too. So I can see both sides.
What I found, again and again, is that identity sits underneath almost everything. Whatever the service is, the same questions come up: who or what needs access, what should it be allowed to do, and for how long? When something goes wrong, it is rarely a broken server. It is usually access, like a permission that was too wide or an account nobody remembered creating.
It used to be simple. If you were inside the company network, you were trusted. The cloud took that away. Now the question is who you are, not where you are. So identity became the front door, and you cannot fix it later. It has to be part of the design from the start. That is how identity went from a side topic to a big part of my work.
You have worked on multi-region Kubernetes and cloud environments at enterprise scale. What are some of the most difficult engineering challenges involved in designing infrastructure that is simultaneously scalable, resilient, and secure?
The hard part is that these goals fight against each other. More regions make you more resilient, but they also give you more to secure and more to keep in sync. Automation makes you fast, but it can also spread a mistake just as fast.
What I have learned is that small differences hurt the most. One setting that is slightly different in one region, and months later it shows up as an outage or a gap. So a lot of the work is about keeping things consistent, with the same rules and the same setup everywhere.
Failover is another hard one. It is easy to draw on a diagram, but it only counts if it works on the day you need it. So it has to be tested before that day, not assumed.
And one lesson I keep coming back to: if the secure way is slow, people will go around it. So I try to make the safe path the easy path. When teams can move quickly and stay safe, they choose it on their own.
Your technical work has included technologies such as GKE Fleet, KEDA autoscaling, and distributed cloud systems. How do these kinds of technologies change the way engineering teams think about workload management, scalability, and operational reliability?
The biggest change is that you stop thinking about one cluster at a time. With a fleet, you think about many clusters as one group, with the same rules everywhere. That takes a lot of stress off the team. For workloads, it means you can run them in more than one cluster or region without redoing everything by hand each time.
KEDA is a good example of a simple idea that makes a big difference. Instead of scaling when the CPU is busy, you scale when the real work shows up, like a queue getting longer. That fits AI workloads really well, because demand can jump and then drop quickly.
It also changes how you think about reliability. You stop trying to keep every machine alive. You accept that things will fail, and you build so that your users never notice.
Agentic AI is introducing a new class of systems that may act autonomously across cloud environments. What security and identity challenges do AI agents create, and how do you think organizations need to adapt their existing cloud security models?
The thing that makes agents different is that they are non-deterministic in nature. Ask the same question twice and you may get two different paths, unlike traditional software. So you cannot test it once and trust it forever.
Here is a small example. Most teams give an agent a service account, because that is what they do for any workload. But a service account does not know the agent is done. The agent finishes, and the account stays behind with all its access, and nobody owns it. I think an agent’s identity should live only as long as the agent does. When the agent ends, the access ends with it.
Beyond that, I would put fixed rules in place around the agent, so the final decision on anything risky does not rest on the agent. I would keep a short list of approved tools. I would keep a clear record of what happened. And I would make sure there is a person who owns every agent. The old rules still apply. We just need to take them more seriously now.
You have also contributed externally through technical publications and collaborations with Google Cloud engineering, including work involving Workforce Identity Federation. How has publishing and collaborating with other technical experts influenced your approach to solving complex infrastructure and security problems?
Writing is a good test. If I cannot explain an idea in simple words, I probably do not understand it well enough yet. And once something is public, people ask questions I never thought of.
Working with the Google Cloud team on the Workforce Identity Federation case study was a good experience for that reason. I got to see the same problem from the product side, and it made me think harder about what works in real life and what only looks good in a diagram.
The main thing I took away is that a good security idea has to be easy to use, or nobody uses it. That changed how I design things. Now I ask, “Would a busy team actually adopt this?” before I ask, “Is this the most complete solution?”
In addition to your engineering work, you are an IEEE Senior Member and serve as a peer reviewer for IEEE and international conferences. How has participating in the broader technical community shaped your perspective on where cloud infrastructure and security are headed, and what do you see as the next major challenge enterprises will need to address?
Reviewing papers and talking with other engineers pulls you out of your comfort zone. You find out that other people are fighting the same battles: too much access, too little visibility, and not enough time.
From that, I see a clear direction. We are moving away from trusting the network and toward trusting verified identity, and agents will push that even further. Every request will need to answer who is asking, what for, and for how long.
I think the next big challenge is running autonomous agents at scale. Soon a company will have many agents, each with its own access, working faster than people can check. The questions will be simple but hard: who owns this agent, what can it reach, and how do we stop it if something goes wrong? The teams that think about this early will be fine. The others will learn the hard way.
