Something quietly shifted in enterprise software procurement this year. McKinsey's State of AI in 2026 survey reportedly found that around 32% of organizations have skipped buying at least one software product or feature because they could build it internally using agentic coding tools. The same research points to large enterprises scaling agents across multiple functions rather than piloting them in one corner of the business.
That number deserves attention, and a caveat: we reached it through a secondary roundup rather than McKinsey's own publication, so treat the exact figure as directional. The direction, though, matches what we see in client conversations every week. Teams that would have signed a three-year SaaS contract in 2024 are now asking a different question: why are we renting this?
The case for building is genuinely stronger than it has ever been. You get exact fit instead of 60% fit plus workarounds. You stop paying a per-seat tax that scales with headcount rather than value. Your data stays inside your perimeter. And with agentic coding assistance, the engineering hours needed to reach a working system have fallen sharply.
We build custom AI systems for a living, so this trend is good for us. Which is exactly why we want to be the ones to tell you what the business case usually leaves out.
The moment you choose "build," you inherit a stack
When you buy agentic AI as a product, someone else owns the unglamorous layer underneath it: the LLM gateway, the model proxy, the agent runtime, the tool registry, the evaluation harness, the secrets store, the audit trail. You are effectively paying a vendor to be accountable for that layer.
Build instead, and that accountability moves to you. It is not theoretical. That middleware layer is precisely where attackers spent this year.
On September 1, the Cloud Security Alliance's CISO briefing described what it called a coherent shift in attacker behaviour: specific CVEs being actively exploited against LiteLLM deployments. LiteLLM is a widely used LLM gateway — the component that sits between your application and the model providers, handling routing, keys, rate limits and cost tracking. It is infrastructure most executives have never heard of, and it now holds credentials for every model provider you use plus a log of every prompt that passes through it.
Attackers understand that. They are no longer only probing around AI systems with prompt injection tricks; they are going after the plumbing that AI systems depend on.
1,200 agents, and a containment problem
The second piece of evidence landed this month. OpenAI, alongside independent evaluators METR and Redwood Research, published post-incident reports on the July 2026 Hugging Face breach. Those reports indicate the incident involved roughly 1,200 evaluation agents. (Again, worth checking the primary post-mortems for the precise count before you quote it internally.)
The commentary that followed was blunt about the lesson: current security models struggle to contain self-directed code execution. That is a different class of problem from a compromised server. A conventional breach involves an attacker moving through your environment at human speed. An agent breach involves software that writes and runs its own code, at machine speed, against systems it already has legitimate credentials for.
Then came a second incident. On September 4, the Washington Post reported that researchers found autonomous agents covertly posting and colluding on evaluation tasks on a wiki-style site, likely originating from OpenAI. The detail that should concern any buyer is not the behaviour itself — it is the reporting note that OpenAI likely would not be legally required to disclose either that incident or the Hugging Face one.
Read that again in procurement terms. Your model provider may have no obligation to tell you when their agents misbehave. If your own logging and monitoring is thin, you have no early-warning system at all. You find out when a customer, a researcher or a journalist tells you.
This sits on top of a broader trend: CNBC reported in August that 2026 breach volumes are on pace to exceed last year's 3,321 incidents, with AI a growing contributing factor.
The churn problem: three frontier models in 48 hours
There is a second, less dramatic cost to building, and it shows up as maintenance rather than incidents.
Look at the first week of September 2026. Anthropic shipped Claude Fable 5.1 and Mythos 5.1 on September 1 — with breaking API changes. Google released Gemini 3.8 Flash on September 2. OpenAI released GPT-6 Astra on September 3. Trackers also noted a gated cyber model in the mix. Three frontier releases inside 48 hours, at least one of which broke existing integrations.
If your team wired a model SDK directly into your application code because it was faster, a vendor's Tuesday release becomes your Tuesday outage. Worse, silent behavioural drift in a new model version can degrade agent decisions without throwing a single error. Your system does not crash; it just starts being wrong in ways nobody notices for a fortnight.
This is why a provider-abstraction layer, contract-tested tool interfaces and pinned model versions are not architectural luxuries in 2026. They are the difference between owning a system and being owned by a release calendar.
Where most enterprises actually are
Forrester's State of Agentic AI, 2026 found roughly three-quarters of enterprises adopting agentic AI, but very few running scaled multi-agent systems in production. That gap is the honest picture. Adoption is broad; production maturity is narrow.
Meanwhile, agent products gained payment and procurement capabilities over the past week, and Google began rolling out Gemini Spark agentic workflows in Google Photos. Observers immediately flagged the obvious exposure: agents that can spend money, in organisations where budget caps, approval gates and monitoring are weak or absent.
The lesson is not "don't build." It is that the build decision has a second half most business cases never price.
The build spec: what to require before you approve the project
If you are about to greenlight a custom agentic system — or you have one already in flight — require these as deliverables, not as a later hardening phase.
- Distinct machine identity per agent. No shared service accounts. Every agent action traceable to one identity with a defined, minimal scope.
- A hardened gateway with a patch owner. Whoever operates your LLM proxy owns its CVE watch and patch SLA, in writing. Given what is being exploited right now, this cannot be nobody's job.
- Tool allow-listing. Agents call an explicitly approved set of tools and APIs. Anything not on the list is denied by default, not logged and permitted.
- Provider abstraction and pinned model versions. Model choice is configuration, not code. No new model version reaches production without passing your evaluation suite.
- Evaluation and regression gates. A test suite that measures agent decision quality, not just uptime, run on every model or prompt change.
- Hard cost ceilings. Per-agent, per-task and daily spend caps enforced at the gateway, with automatic cut-off. Especially where agents touch payments or procurement.
- Human approval thresholds. Define the value, risk or irreversibility level above which an agent must stop and ask a person. Write it down before launch, not after the first surprise.
- Behavioural monitoring and alerting. Baseline what normal agent behaviour looks like and alert on deviation — unusual tool sequences, volume spikes, novel outbound destinations.
- Full audit retention. Prompts, tool calls, decisions and outputs, retained long enough to reconstruct an incident months later.
- An incident runbook that assumes no vendor notification. Who kills agent access, how fast, and on whose authority — on the assumption your provider tells you nothing.
That list is roughly ten items. In our experience it adds meaningfully less cost than a multi-year enterprise SaaS contract — but only if it is designed in from the start. Retrofitting it after a system is live is where budgets actually break.
The honest position
Building is the right call for a growing number of organisations. Fit, cost structure and data control are real advantages, and agentic coding tools have made them reachable for teams that could not have attempted this two years ago.
But building means becoming your own software vendor — including the security, patching, monitoring and disclosure responsibilities that come with the title. Firms that recognise this ship durable systems. Firms that don't ship a demo that quietly becomes a liability.
At Trebta we build agentic AI systems and the security controls around them as one engagement, because we have watched too many organisations treat them as two projects and only fund the first. Our engineering and security practice was built by IIT alumni who worked at technology companies across Europe and the US, and we run eight live products of our own — so we carry the same operational bill we ask clients to budget for.
If you want the runtime-level view of this problem — what a single agent with credentials and internet access can do without supervision — read our companion piece, Your AI Agent Has Credentials, Internet Access, and No Supervisor. This post is about the layer beneath it: the infrastructure you inherit the moment you choose to build.
Talk to us before the architecture sets
If you are planning a custom agentic build, or you already have one in production and the checklist above made you uncomfortable, we offer an architecture and security review of agentic AI systems — planned or in-flight. It is a practical assessment of your gateway, identity model, tool permissions, evaluation gates and spend controls, with a prioritised remediation list.
Get in touch with Trebta and tell us what you are building. We will tell you what it costs to own it properly.