AI coding tool spend is projected to top $13 billion in 2026, compounding at more than 60% a year. That's an entire category showing up at once, according to the recent Palo Alto Networks'[ _Secure AI Coding_](https://www.paloaltonetworks.com/blog/2026/09/secure-ai-coding-governing-every-agent-artifact-and-identity) _Secure AI Coding_ report.
These agents don't just autocomplete a line of code anymore. They plan. They act. They call tools, run commands, and touch other systems on your behalf. This is pretty different from the assistant that used to live in your IDE sidebar. And that's exactly where the risk lives.
An AI coding agent is software that writes, tests, and ships code independently. This level of autonomy earlier tools never had. It doesn't wait for you to accept a suggestion line by line. It takes a goal, breaks it into steps, and executes.
To do that, it makes three kinds of calls:
Each of those calls is a connection leaving your environment. And each connection is something you either control or don't.
This is why securing an AI coding agent isn't only about reviewing the code it writes. It's about governing the traffic it generates along the way. If you want the mechanics of one piece of that traffic, this piece on [_MCP gateway_](https://konghq.com/blog/learning-center/what-is-a-mcp-gateway)_MCP gateway_ is a good place to start.
Palo Alto Networks found that 68% of organizations lacked visibility into the AI tools their developers were actually using. And another 57% of developers used AI coding tools without formal IT approval at all.
That gap has a name. It’s called ***Shadow AI***. And it carries consequences like source code and secrets leaving through prompts, insecure generated code reaching production, token spend running past any budget, and tool access nobody signed off on.
None of that means coding agents should be blocked. It means they need to be governed, the same way APIs and cloud services earned governance once they went from experiment to infrastructure.
But governance cuts both ways. Lock down IT approval too hard, and developers route around it, reaching for tools quietly instead of through sanctioned channels. That's how shadow AI starts in the first place. Leave access too open, and token spend climbs with no ceiling in sight. The goal isn't control for its own sake. It's finding the point where code quality holds, approval stays light enough that developers don't abandon the process, and cost stays predictable. That balance is what a governance framework is built to hit.
The OWASP GenAI Security Project published the[ _OWASP Top 10 for Agentic Applications_](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) _OWASP Top 10 for Agentic Applications_ in December 2025. It gives the industry a shared taxonomy for these risks: tool misuse, unexpected code execution, and identity abuse, among them. Mapped onto coding agents specifically, a few show up over and over.Gartner reaches a similar conclusion from a different angle. Its [_AI TRiSM framework_](https://www.gartner.com/en/articles/ai-governance-trism)_AI TRiSM framework_, argues that policies alone can't keep pace with AI that acts on its own. Real governance needs enforcement built into the system, not just a document describing intent. Mapped onto coding agents specifically, six risks show up most often:
Models generate code the way they generate anything else: by predicting what's likely, not what's safe. They don't carry security context unless you give it to them.
In fact, the numbers back this up. Veracode's[ _AI-generated code security_](https://www.veracode.com/blog/ai-generated-code-security-risks) _AI-generated code security_ report tested more than 100 LLMs across 80 coding tasks and found only 55% of the output was secure. That's close to a coin flip.
Scanning that code is important. Static analysis and code review are their own discipline, and they should stay in place. But scanning the output is a different job from governing the connections that produced it. You need both, not one instead of the other.
Keep a human in the loop. Automated scanning catches patterns, not judgment. A human reviewer should stay at the last checkpoint before any AI-generated code ships, every time, no matter how good the model's track record looks on paper.
OWASP groups this under prompt injection, and for coding agents it's a path to code execution, not just a bad answer. A malicious instruction hidden in a file, a commit message, a linked ticket, or a tool's response can redirect what the agent does next. Because the agent is already trusted to run commands, a successful injection can look exactly like normal developer activity.
That's what makes it hard to catch after the fact. There's no separate error to flag. Just an action nobody asked for.
OWASP calls this excessive agency: giving an agent more reach than the task in front of it needs. Most MCP servers expose every tool they have by default, so an agent wired up for one narrow job can often see a server's entire surface area, file systems, deployment pipelines, ticketing systems, whatever happens to be connected.
The risk isn't that an agent will misuse that access on purpose. It's that a bug, a bad prompt, or an injected instruction gets a much bigger blast radius than it should.
Every prompt a coding agent sends can carry more than a question. It can carry source code, API keys, customer data, and anything else sitting nearby in the codebase. Send that to a third-party model, and you've made a disclosure decision without meaning to.
Kiteworks surveyed the space and found that 83% of organizations lack automated controls to keep sensitive data out of public AI tools, per its[ _AI security gap survey_](https://www.kiteworks.com/cybersecurity-risk-management/ai-security-gap-2025-organizations-flying-blind/) _AI security gap survey_. That's not a policy gap. That's an enforcement gap, and policy alone doesn't close it. You need a chokepoint where guardrails apply automatically, every time, regardless of which tool a developer picked that day.
Every coding agent needs credentials to reach models, repos, and tools. Most get provisioned the fast way: a shared API key, or a developer's own token borrowed for convenience.
Multiply that across every agent, every tool, and every team, and you get a population of non-human identities nobody tracks as carefully as they track human accounts. Gartner's research on AI governance makes the underlying point directly: policy can state who's allowed to do what, but it can't enforce it at runtime. That enforcement has to live in the identity layer itself.
Token usage doesn't look like a security risk until the invoice arrives. An agent that can call any model, any number of times, with no budget attached, can burn through spend as fast as it burns through tasks, especially once it starts looping on a hard problem or retrying a failed tool call.
That's not a hypothetical. It's the same rogue spend risk raised earlier, just visible in a different place: the billing dashboard instead of the audit log.
Together, OWASP's agentic risk taxonomy and Gartner's AI TRiSM framework land on the same point from two different directions. These risks don't go away with a policy document. They need controls that run continuously, while the agent operates, not guidelines it's trusted to follow on its own.
None of this calls for a ban. It calls for a framework, one that treats agent traffic with the same discipline you already apply to APIs and identity. Six steps cover it.
This is the shape of a real[ _AI governance platform_](https://konghq.com/solutions/ai-governance) _AI governance platform_: consistent controls applied at the infrastructure layer, not bolted onto each tool one at a time. Three of these steps deserve a closer look.
An agent isn't a user, and it shouldn't authenticate like one. It's a non-human identity, and it needs to be treated as a first-class citizen in your identity system, not an afterthought bolted onto a developer's account.
That means brokering token exchange with the identity providers you already run, and enforcing least privilege at the moment an agent takes an action, not just at login. Developers already feel the tension here. Stack Overflow's[ _developer survey_](https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/) _developer survey_ found that 81% have security and data-privacy concerns about AI tools, even as 84% use or plan to use them. Identity done right is how you let both of those numbers coexist.
Most MCP servers expose every tool they have by default. That's convenient for a demo and dangerous in production, because it means an agent can see and use far more than any one task requires.
Put a gateway between your agents and the MCP servers they call, and use it to restrict which tools each agent can reach, apply authentication consistently, and log every call for review. That's the direct answer to the governance and observability question enterprises are asking about MCP traffic today, and it's what a dedicated[ _MCP governance solution_](https://konghq.com/solutions/mcp-governance) _MCP governance solution_ is built to do.
Data protection and cost control have the same enemy:*** inconsistency. ***Applied tool by tool, both break down eventually.
Centralize them instead. Apply PII sanitization and semantic prompt guards at the gateway, so sensitive data gets caught before it leaves, no matter which coding tool sent the request. Pair that with token-based rate limiting and per-team quotas, and cost becomes something you set on purpose instead of something you discover on an invoice. Kong's guide to[ _PII sanitization for AI_](https://developer.konghq.com/how-to/protect-sensitive-information-with-ai/) _PII sanitization for AI_ walks through the pattern in detail.
Here's the throughline across all the steps: every one of them gets enforced at the same layer, because every one of them depends on the same thing. Agent access happens through connections. LLM calls, MCP calls, agent-to-agent calls. Connectivity is the layer where control actually sticks.
Put one gateway and one control plane in front of that traffic, and platform and security teams get unified access control, data protection, tool scoping, cost control, and observability. All of it, across every agent and every coding tool, without stitching together a different set of controls for each one.
Worth being precise about scope, too. An AI gateway isn't a code scanner. It isn't an agent framework. It isn't endpoint DLP. It's the control layer for the traffic agents generate, and it does that one job well, working alongside the other tools in your stack rather than replacing them.
Kong has published its own pattern for[ _governing Claude Code_](https://konghq.com/blog/engineering/claude-code-governance-with-an-ai-gateway) _governing Claude Code_ with Kong AI Gateway, and it maps directly onto the framework above.
Route the agent's LLM and MCP traffic through the gateway. Apply PII sanitization and prompt guards at that entry point. Restrict tool access so the agent only reaches what it's authorized for. Set per-team token budgets so cost stays predictable. Export everything through OpenTelemetry, so every call is auditable after the fact. The related walkthrough on[ _securing MCP servers_](https://konghq.com/blog/product-releases/securing-observing-governing-mcp-servers-with-ai-gateway) _securing MCP servers_ covers the MCP-specific controls in more depth.
That's the framework, applied end to end, on a tool teams are already shipping with.
If you're ready to see what this looks like on your own traffic, our team can walk you through it.[ _Request a demo_](https://konghq.com/products/kong-ai-gateway) _Request a demo_ of Kong AI Gateway.
**What is an AI coding agent?** An AI coding agent is software that plans and executes coding tasks with autonomy, rather than just suggesting code for a human to accept. It makes LLM calls to reason, MCP calls to use tools, and increasingly agent-to-agent calls to delegate work.
**Are AI coding agents a security risk?** They introduce risk in specific, well-understood categories: insecure generated code, data leakage through prompts, over-privileged tool access, and unbounded cost. None of that is a reason to avoid them. It's a reason to govern them.
**How do you govern AI coding agents in an enterprise?** Follow six steps: discover and inventory agents, establish non-human identity with least privilege, enforce data guardrails at the point of egress, scope MCP tool access, control cost with token budgets, and centralize observability across all of it.
**Is AI-generated code secure?** Not by default. Veracode found only 55% of AI-generated code was secure across more than 100 LLMs and 80 coding tasks. Code review and scanning need to stay in the pipeline alongside traffic governance.
**What is MCP and why does it matter for securing coding agents?** MCP, the Model Context Protocol, is how coding agents access external tools and data. Most MCP servers expose every tool by default, so gating and scoping that access is one of the highest-leverage controls you can put in place.
**How do you control the cost of AI coding tools?** Apply token-based rate limiting and quotas at the gateway, attributed per team. That turns spend into something you set intentionally instead of something you find out about later.
**Should AI coding tools be blocked or governed?** Governed. Blocking pushes usage underground and recreates the shadow AI problem you're trying to solve. Governance lets teams keep the productivity gains while closing the visibility and control gaps.
**What's the difference between an AI gateway and a code security scanner?** A scanner inspects the code an agent produces. A gateway governs the connections an agent makes to get there, LLM calls, MCP calls, and agent-to-agent calls. They solve different problems, and you need both.
This post is based on Kong's webinar on token cost management. Watch it below, or keep reading for the breakdown. Token cost management is how a business tracks, controls, and governs what it spends on AI model usage, the same way it already track
AI adoption is outpacing the speed at which many organizations can establish standardized oversight. In fact, Stanford HAI reported that 78% of surveyed organizations were using AI in 2024, a significant jump from 55% the previous year ( AI Index Re
An AI agent isn't magic. It's a reasoning engine that makes decisions based on what it knows at a given moment. That "what it knows" is its context — the information available to it right now. Context is everything. Give an agent the wrong context,
You Can't Govern What You Can't See AI spending will reach $2.59 trillion in 2026. I regularly like to share what we're seeing in production at Kong. Not projections or analyst forecasts, but actual traffic flowing through Kong AI Gateway from
Your infrastructure already has the raw materials: compute (VMs, containers, serverless), event streaming (Kafka, Kinesis, Pub/Sub, RabbitMQ), data stores (warehouses, databases, object storage), and AI endpoints (any hosted or self-hosted LLM). Tho
iPaaS — Integration Platform as a Service — was built for a world of deterministic applications. The mental model is simple: you have systems, they have APIs, and iPaaS connects them. Data flows from point A to point B according to rules you define.
Over the last few years, enterprises have made a genuinely impressive leap. They moved from rule-based automation to large language models capable of reasoning, planning, and acting. The intelligence layer is dramatically better. But the integration