The API Has Become the Attack Surface: A Conversation with Nireesha Mandala

For most of the past decade, the conversation about enterprise security centered on networks, endpoints, and the perimeter. That center has moved. In 2025, 87% of organizations reported an API-related security incident, and APIs overtook web applications and network infrastructure as the single largest attack surface for large enterprises. The reason is structural. Every mobile app, every cloud integration, every microservice, and now every AI feature runs on APIs underneath. The connective tissue that lets enterprise systems talk to each other has become the place where the most sensitive data lives, and the place attackers most want to reach. The harder problem is that this surface is mostly invisible to the teams responsible for it.

Nireesha Mandala, a Software Engineering Manager with more than 14 years building integration architecture and platform infrastructure for enterprise software, has spent much of her career on the side of this problem that rarely makes headlines: governing how systems are allowed to connect in the first place. She has designed integration frameworks from scratch for high-traffic, customer-facing platforms that serve thousands of enterprise customers. Her focus is the inbound edge, the question of which traffic should reach production at all and how a platform decides.

We spoke with Nireesha about why integration security gets overlooked until it fails, how she rebuilt the way a major enterprise platform vets inbound traffic, and what changes now that AI agents are starting to make API calls of their own.

Integration usually gets described as plumbing. Why does the security of it get overlooked until something breaks?

Because plumbing is exactly how most organizations treat it. An integration works, data flows, nobody looks at it again. The problem is that an integration is also a standing invitation. Every connection you open is a path into your system that somebody, eventually, will try to use in a way you did not intend. When it is working, it is invisible, and that invisibility is the whole risk.

The teams who get burned are usually not the ones with weak authentication. They are the ones who lost track of what was connected. Old integrations nobody owns. Service accounts created for a project that ended two years ago. Inbound calls from sources that were authorized once and never reviewed again. You cannot defend a surface you cannot see. So the first real security work is not building a wall. It is building an inventory and a decision: for every connection, who approved it, what is it allowed to touch, and does that still hold true today.

You built a system to govern that inbound traffic directly. What does it actually do?

It sits in front of production and treats every inbound API call as something that has to earn its way in. The average enterprise now runs around 3,000 APIs that carry sensitive data, and roughly 12% of them have known security weaknesses. On a high-traffic, customer-facing platform, that is not a number you manage with good intentions. You need a registry: a single, authoritative record of which service accounts and which sources are permitted to call production, and what they are permitted to do. Everything else gets stopped at the door.

The practical effect is that unrecognized traffic never reaches the systems that matter. If a call comes from a source that is not on the list, it is blocked before it can do anything. That also catches a quieter category of problem: unintended changes pushed to production from accounts or sub-environments that were never meant to write there. A lot of damage in large systems is not malicious. It is a forgotten script in a test environment talking to production because nothing ever told it no. The registry is the thing that tells it no.

How do you tell legitimate traffic from rogue traffic without slowing down a platform that cannot afford latency?

That tension is the entire engineering problem. Security people want to inspect everything. The platform team will not accept a layer that adds latency to every call in production. So you do not inspect content on the hot path. You make the decision about trust upstream, at the level of identity and source, so that by the time a call is in flight, the question of whether it is allowed has already been answered. The check is fast because it is a lookup against authorized identity, not a deep inspection of every payload.

The harder part is the edge cases. A legitimate source changes its address. A new region comes online. An integration that was dormant suddenly resumes. If your default is to block, those look exactly like attacks, and you will take down real business traffic if you are not careful. So the design has to make adding and verifying a source deliberate and traceable, with a clear owner, rather than a quiet manual edit nobody can later explain. Getting that workflow right matters as much as the blocking logic. A control that is painful to operate is a control people route around.

Compliance can force a redesign that no amount of best practice would. You went through one around federal data. What broke, and what did you have to rebuild?

The forcing function was a federal compliance program. Once you are handling regulated government data, the line that a service account has broad access because it always has stops being acceptable. The requirement was hard: certain service accounts could not be allowed to reach tables that held federal data, even through inbound integrations everyone had trusted for years. That meant going back through legacy integrations built in an era when internal traffic was assumed to be safe, and rebuilding them so they physically could not reach what they were not cleared to see.

That assumption of internal trust is exactly what attackers exploit at scale. 43% of the security flaws added to the U.S. government's actively-exploited vulnerability list in 2025 were tied to APIs, and a large share of API incidents arrive through authenticated, legitimate-looking sessions, not some exotic break-in. So redesigning for federal compliance was really a preview of where everything is going. You stop trusting a connection because of where it sits in your network, and you start enforcing, per integration, exactly what it is allowed to do. The hard part was doing all of that underneath live customers without anyone noticing a difference in their day.

You serve as a peer reviewer for the International Conference on Information Systems. Does evaluating other people's research change how you approach your own engineering?

It does, more than I expected. Serving as a peer reviewer for the International Conference on Information Systems means reading work whose only job is to prove a claim rigorously, and you develop a low tolerance for arguments that sound good but do not hold up. That habit comes straight back into engineering. When a team tells me a design is secure or a system will scale, I ask the same questions a reviewer asks. Where is the evidence? What is the failure case you are not showing me. What did you actually test versus what you assumed?

The other thing it does is keep me current. Reviewing forces me to read carefully across areas next to my own, and a lot of what becomes standard practice in industry shows up in that literature years earlier. Identity, trust models, the failure modes of distributed systems. You see the problems being named before most engineering teams feel them. For someone whose job is to build the layer that decides what to trust, that early signal is worth a great deal.

There is a lot of vendor noise around API security right now. What do you think the industry still gets wrong?

The biggest mistake is buying a product before you have done the boring work. A team feels exposed, so they purchase a tool that promises to find and protect their APIs, and they install it on top of an environment nobody has actually mapped. Now they have a dashboard full of alerts and still no answer to the basic question of which connections are supposed to exist. A tool can tell you what is talking to what. It cannot tell you what should be. That second question is governance, and no vendor can do it for you.

Zero trust is the right instinct, but it gets sold as a thing you buy rather than a decision you make about every connection. The teams that get it right are almost boring about it. They keep a real inventory. They give every integration an owner. They review access on a schedule instead of when an auditor shows up. None of that is exciting, and none of it demos well, which is exactly why it gets skipped. The unglamorous habits are the ones that hold up when something goes wrong at two in the morning.

Where does this get harder next? What is still unsolved in how platforms govern what connects to them?

AI agents. We spent years building the discipline that every connection has a known owner and a defined scope, and now we are introducing software that makes its own API calls, with legitimate credentials, at a speed and volume no human reviewer can sit behind. An autonomous agent acting through a valid token looks exactly like the trusted internal traffic that every old security model waved through. That is the unauthorized-workflow problem all over again, except the actor is not a forgotten script. It is something we deployed on purpose and asked to be clever.

So the work I care about for the next few years is making governance keep pace with that. Every agent is treated as its own identity, with its own scope, its own audit trail, and the same hard answer to the question of what it is allowed to touch. I do not think the answer is to slow AI down. I think the answer is that the registry, the inventory, the per-connection decision about trust, all of that unglamorous machinery, has to become a first-class part of how we build, not something we bolt on after the incident. Get that right and the speed is a gift. Skip it and we are just automating the breach.