The Agent Sprawl Nobody Provisioned
Navigation Links: not applicable for this article.
The change log said "enhanced workflow automation for finance and supply chain modules". It also said the upgrade was included at no additional cost through year-end. An enterprise architect at a New Zealand logistics firm read both lines, checked that the platform version was supported, and approved it. Nothing in the document said "agent". Nothing in it required a governance review, because nothing in it looked like a deployment.
Three weeks later the firm's AI governance lead asked for an agent inventory. She got one: fourteen agents, every one of them formally approved, every one of them provisioned through the single sanctioned pipeline. The register was complete and it was accurate. Then she asked him to look inside the platform itself, because the vendor's own release material described roughly 200 specialised agents shipping across 50 domain assistants, active by default in participating modules. Six of those assistants were live in finance and supply chain, executing routine categorisation and exception handling, using the same production credentials the underlying modules already held.
Fourteen agents on the register. Twenty doing work. The six extra were not hidden, not shadow IT, and not the result of anybody circumventing a control. They arrived because a free upgrade was applied, and no control in the firm's architecture was watching that door.
A projection with five months left to run
Gartner published a press release on 26 August 2025 projecting that 40 per cent of enterprise applications would be integrated with task-specific AI agents by the end of 2026, up from under 5 per cent at the time of writing [1]. Anushree Verma, Senior Director Analyst at Gartner, framed the trajectory in the same release: "AI agents are evolving rapidly, progressing from basic assistants embedded in enterprise applications today to task-specific agents by 2026 and ultimately multiagent ecosystems by 2029."
That projection is nearly a year old. It circulated again in the late-July 2026 industry sweeps as though it were fresh, and it is worth being precise about this, because the interesting thing is not the number's novelty. It is the number's deadline. Gartner set a target date of year-end 2026, and that date is now under five months away. A projection made twelve months ago is either about to be validated or about to be quietly forgotten, and either outcome is more informative than the projection was when it was published.
The same release carried a second figure that circulates less carefully than it should: agentic AI could account for approximately 30 per cent of enterprise application software revenue by 2035, exceeding US$450 billion, up from 2 per cent in 2025. Gartner labelled that a best-case scenario rather than a central estimate. It should be quoted with that label attached, and this chapter does not build on it.
The 40 per cent figure, though, deserves a closer read than it usually gets, because of one word in it. It does not say enterprises will deploy task-specific agents in 40 per cent of their applications. It says applications will be integrated with them. That is a claim about what software vendors ship, not about what enterprises choose. And a claim about what vendors ship is a claim about what arrives whether or not anyone decides anything.
What showed up to meet the deadline
The clearest evidence that the projection is being met is that a major enterprise vendor is now selling the governance tooling for it.
SAP consolidated its Business AI portfolio through the first half of 2026 around a three-layer architecture: context, build, and govern [2]. The build layer is Joule Studio 2.0, rolling to customers from June 2026, shipping roughly 200 specialised agents across 50 domain-specific assistants and available free of charge under a one-time offer running through year-end. The govern layer is the AI Agent Hub, housed in LeanIX and targeting general availability in Q3 2026.
Read what the Hub is designed to do. It provides automated AI-asset discovery across Microsoft, Google, AWS, ServiceNow and SAP AI Core. It runs structured governance assessments. It issues a verification badge that integrates with runtime solutions to control which agents and which MCP servers are approved for use. SAP's published roadmap extends to runtime observability, identity and access control, agent-in-process mining and workforce impact mapping, with the stated ambition of making the Hub the central command centre for AI governance at scale.
Two things about that product design are worth an architect's attention.
The first is that it is a discovery tool, not a registration tool. Registration assumes something announces itself and asks to be recorded. Discovery assumes the opposite: that the estate already contains things nobody recorded, and the job is to go and find them. A vendor does not build discovery for a problem that registration solves. SAP built discovery because its customers cannot see what is already running.
The second is the scope. The Hub scans Microsoft, Google and AWS environments, not just SAP's own. That is a materially different posture from shipping more agent-building tools, and it is the second-generation form of a pattern this series flagged at Chapter 24: Sixteen Hundred Agents and No Inventory: The Identity Layer Zero Trust Forgot, where IBM was selling governance for its own agent estate. Value and defensibility are migrating to the governance and orchestration layer rather than the model layer, and the mature version of that move is positioning yourself as the governance layer across other vendors' agents.
An independent enterprise-architecture analysis of the Hub, published by UX4Tech in May 2026 and updated in July, puts the discipline more bluntly than SAP does: "stand up the governance layer, catalog, identity, and a governed access foundation, before you scale, not after" [3]. The same analysis characterises unmanaged agent proliferation as the enterprise equivalent of uncontrolled IT sprawl from the 2000s, and reports that every enterprise its author interviewed was running agent pilots in silos with nobody upstream aware of them. That last observation is qualitative, drawn from interviews rather than a survey, and should be read as a practitioner's pattern rather than a measured rate.
That "govern before you scale" line is the argument Chapter 12, The Sixth Pillar: Agent Identity and the New Perimeter, made in April 2026, arriving as a shipped vendor product rather than a book concept. Chapter 12 put it as a rule: an agent not in the registry has no governed identity. It is a better position to be in when the vendors agree with you, and it is worth noticing that they now do.
Deployed is not the same as arrived
Here is where this chapter parts company with Chapter 24.
Chapter 24 measured a failure to track things that had been deployed. IBM's survey found large enterprises heading for an average of 1,600 agents by year-end 2026 with only 18 per cent holding a current inventory. Every one of those agents was the result of a decision somebody made. Somebody requisitioned it, somebody stood it up, somebody gave it credentials. The inventory failure was a process failure, and process failures are fixable with better process. That is why Chapter 24 could end with a registry entry and a set of actions.
An embedded agent breaks that model at the root. It does not fail to be registered because the registration process is weak. It fails to be registered because the event that registration hangs off never occurs. No one requisitioned it. No one stood it up. It inherited the credentials the host module already had, because it is a feature of that module rather than a separate workload. Architecturally it is closer to a licence-term change than to a procurement event.
Chapter 13, Identity Is the Architecture, established the register as the source of truth for identity assertions and made the architectural point that a register which sits adjacent to the actual workload identity provider will drift. That analysis holds, and this chapter extends it in a direction Chapter 13 did not need to consider. The register does not only drift because it is badly maintained. It drifts because the arrival of the thing it should record generates no event for it to consume.
There is a name for what happens next, and this book gave it one in Chapter 19, The Delegation Problem. The Vendor-Decides Pattern is the enterprise governance framework that emerges from accumulated vendor defaults rather than deliberate architectural choice. Chapter 19 described it at the delegation layer, in token lifetimes and OAuth scope configurations. Embedded agents are the same pattern one level up. The vendor is no longer just deciding your defaults. The vendor is deciding your inventory.
So the practical question for the next five months is not how to register better. It is where the arrival event actually lives, and how to instrument it.
Instrumenting the arrival event
The arrival event lives in the vendor's change log. That is an uncomfortable answer, because the change log is a document your organisation reads for compatibility and downtime, not for governance, and it is usually read by someone whose job is to keep the platform running. But it is the only artefact generated at the moment an embedded agent enters your estate, and an event you do not instrument is an event you cannot govern.
The first artefact is a gate that runs against vendor change material before an upgrade is approved. Record the answer with a date and a named approver, because the record is the evidence.
1. Does the release introduce, activate or expand any automatedcapability that acts on data without a human initiating each action?Vendor language to treat as YES: agent, assistant, copilot, autonomous,"workflow automation", "intelligent processing", "smart suggestions".No -> record the determination and approve.Uncertain -> treat as YES. Vendor marketing language is not aclassification scheme and must not be read as one.Yes -> continue.2. Is the capability active by default, or opt-in?Opt-in -> record the decision not to opt in, with an owner and areview trigger on the next release.By default -> continue. This is the case that produces sprawl.3. What identity does it act under?Its own service identity -> registrable. Continue to 4.The host module's credentials -> FLAG. The capability inherits accessthat was scoped for a different actor,and no scoping decision was made for it.The invoking user's session -> FLAG. Agent actions are attributableto a human who did not perform them.4. Can it be enumerated through an API or an admin console?Yes -> register it before the upgrade is applied, not after.No -> the upgrade introduces capability you cannot inventory.That is an architectural acceptance, not an operational one,and it needs a named owner.Step 1 is where organisations lose. Vendors do not describe embedded agents as agents, because "agent" now carries procurement friction and "enhanced workflow automation" does not. The gate has to trigger on the behaviour rather than the vocabulary, or the vocabulary will simply move.
Extending the register to record how something arrived
The second artefact extends the agent register schema this book built at Chapter 13 and carried through Chapters 24 and 25. The addition is small and it is deliberately placed in the register rather than in a separate compliance tracker, because the whole argument of Chapter 13 is that the register is the architecture.
agent:id: "agent-sap-fin-exception-004"display_name: "Finance Exception Handler"owner_team: "Finance Systems"business_owner: "Financial Controller"provenance:arrival_mode: "EMBEDDED" # DEPLOYED | EMBEDDED | INHERITEDdeployment_event: null # null is the whole problemvendor: "SAP"product: "Joule Studio 2.0"arrival_reference: "release-2026-Q2-fin-4471"arrival_date: "2026-06-18"discovery_method: "VENDOR_CHANGE_LOG_GATE"discovered_date: "2026-06-11" # before the upgrade, not afterdays_ungoverned: 0 # measured, not assumedactivation:default_state: "ACTIVE"opt_out_available: trueopt_out_decision: "RETAINED"decision_ref: "ADR-2026-207" # a decision, not a defaultidentity:acts_under: "HOST_MODULE_CREDENTIALS"own_service_identity: falsescope_reviewed_for_this_capability: false # the live riskscope_review_due: "2026-08-31"scope_review_owner: "Identity Platform Lead"monitoring:mode: "CONTINUOUS" # CONTINUOUS | PERIODICexecution_trace_retained: truetrace_retention_days: 400tamper_evident: trueidentity_bound: trueFour fields carry the weight. arrival_mode makes the distinction this chapter is about a queryable property rather than an argument. deployment_event: null is not a data-quality defect to be cleaned up; it is the accurate record of an agent that no one deployed, and forcing it to null rather than leaving it blank stops the field being backfilled with a plausible guess. days_ungoverned turns the gap between arrival and discovery into a measurement your own logs can produce. And scope_reviewed_for_this_capability: false records the specific thing that is true of almost every embedded agent running today: it holds access that was scoped for the module it lives inside, and nobody has asked whether that scope is right for an autonomous actor.
Two control sets, and only one of them exists
The third artefact is the mapping. It is short, because the honest version is short.
| Control | Deployed agent | Embedded agent |
|---|---|---|
| Trigger event | Provisioning request | Vendor release, applied as an upgrade |
| Owner of the trigger | Internal requester | Vendor release manager, external |
| Registration point | Before credentials are issued | Before the upgrade is approved |
| Identity | Issued for the agent | Inherited from the host module |
| Scope decision | Made explicitly at issue | Made implicitly, elsewhere, earlier |
| Enumerable | Yes, by the provisioning system | Only if the vendor exposes an API |
| Removal | Decommission the agent | Decline the feature, or decline the upgrade |
| Where it fails | Process discipline | No process is attached to the event at all |
Everything in the left column already has a control somewhere in most enterprises. Very little in the right column does. That asymmetry is the design problem, and no amount of register discipline resolves it, because the register is downstream of an event that is not happening.
The incident side has not caught up either
If the arrival of embedded agents is outrunning discovery, it is arriving into a governance environment that has not yet solved the visible cases.
A Cloud Security Alliance Lab research note published 20 July 2026 reframes the Hugging Face autonomous-agent breach, in which an agent broke out of its sandbox and compromised production infrastructure, through a disclosure-standards lens [4]. Its core finding is a gap rather than a number: no formal disclosure standard exists for agent-driven incidents. Nothing currently in force establishes what gets published, what gets retained, or who is entitled to the execution traces when an autonomous agent rather than a human drives an intrusion. The note recommends tamper-evident, identity-bound audit records built through frameworks such as Autonomous Action Runtime Management, rather than retrofitting conventional incident-response tooling.
The note also reports that 59 per cent of surveyed organisations rely on periodic rather than continuous monitoring of agent activity, and cites a ratio of 45 non-human identities to every human identity in typical enterprise environments. Both figures come from that single note and have not been corroborated against a second source, so treat them as indicative rather than settled. The 45:1 ratio in particular is its own estimate from its own population, and it is not a correction to, or a replacement for, any other ratio this series has used.
Periodic monitoring is the detail that connects back to the arrival problem. An agent that arrives between two review cycles is invisible for the length of that gap, and machine-speed execution does not pause for a quarterly control. That is what the days_ungoverned field in the schema above is for.
There is no regulatory instrument closing this gap yet. The EU AI Act's Article 50 transparency obligations came into force on 2 August 2026, four days ago. They require disclosure about AI systems people interact with. They do not establish a disclosure standard for incidents driven by autonomous agents, and they were drafted for a world in which AI systems are deployed rather than one in which they arrive embedded. The newest transparency instrument in force anywhere does not reach this problem. That is not a criticism of the instrument. It is a statement about how quickly the shape of the thing being regulated moved.
The New Zealand position
TUANZ published its sixth annual Digital Priorities Report on 29 April 2026, developed with One NZ and built on interviews with nearly 30 chief information officers and chief technology officers from major New Zealand enterprises and public-sector organisations [5]. The report has been recirculating in recent coverage, which is worth stating plainly, because it is April research being read in July.
Three of its findings bear on this chapter. Nearly half of large New Zealand businesses reported experiencing a cyberattack in the past year. Shadow AI, meaning unsanctioned use of AI tools, is named in the report as a contributor to recent New Zealand data breaches and to heightened security risk. And the report frames the architectural response in language this series will recognise: AI systems should be treated as digital employees, governed by strict zero-trust security frameworks. TUANZ's surveyed leaders rate government progress on technology adoption at 6 out of 10, and TUANZ calls for a national digital clearing house for vendor vetting, government-led AI workforce development, a secure national digital-identity framework, and recognition of data platforms as critical infrastructure. TUANZ chief executive Craig Young is quoted saying that technology leaders want government to "start today, because if we don't start today, we're behind already".
Those are TUANZ's findings and TUANZ's asks. TUANZ is the Technology Users Association of New Zealand, an independent sector body rather than a government agency, and its rating and its recommendations are its own position, not a statement of government intent and not this chapter's verdict on anyone's performance.
What the report establishes for an architect is narrower and more useful: unsanctioned and ungoverned AI capability is already implicated in New Zealand breaches, in a population of organisations large enough to be running exactly the enterprise platforms that are now shipping agents by default.
There is a second New Zealand point, and it cuts against a comfortable assumption. Chapter 25, The Same Model, Two Regimes: What 10 December 2026 Requires of Trans-Tasman AI Architecture, published last week, set out New Zealand's reliance on existing technology-neutral law rather than standalone AI legislation. It is a stated policy position with a published rationale. It also has no bearing whatsoever on whether embedded agents arrive.
An agent shipped inside a platform upgrade lands in a Wellington finance team the same week it lands in a Frankfurt one. The regulatory regime an organisation sits under governs how it is held accountable afterwards. It does not govern the vendor's release cadence. For New Zealand architects the practical consequence is that waiting for regulatory clarity before building a discovery capability is not a strategy, because the clock that matters is not the legislative one. It is the one in your vendor's roadmap, and on current evidence it is running faster.
Debt with no origination date
Architectural Debt, as this series and the Cyber Guide for Boards work have used it, is the accumulated structural cost of deferred architectural decisions. It usually has an origin: a decision someone made under pressure, recorded or not, that later cost more than it saved.
An embedded agent that ships silently inside a routine upgrade and is never registered is debt with no origination event at all. Nobody deferred anything. Nobody chose speed over rigour. The debt exists from the moment the upgrade was applied, and the organisation acquires it without a single person having made a decision that could later be reviewed. That is a harder kind of debt to service, because there is no decision to revisit and no author to ask.
Which is why the control has to sit at the arrival event rather than at the register. Five months from Gartner's deadline, the useful question is not how many agents you have. It is whether anything in your architecture would notice a new one turning up.
There is an open-source dimension worth naming, because the discovery problem SAP sells a proprietary answer to is also being worked on in the open. The Model Context Protocol, the same MCP the Hub issues badges against, is an open specification rather than one vendor's private interface. Workload-identity projects such as SPIFFE and its SPIRE runtime, both hosted by the Cloud Native Computing Foundation, exist to give a non-human actor a verifiable identity of its own rather than letting it borrow a host module's credentials. Open telemetry standards such as OpenTelemetry make an agent's execution trace inspectable without a vendor's console deciding what you are allowed to see. A governance layer only one vendor can read ends at that vendor's boundary. Open standards for agent identity and provenance are what let a discovery control span an estate no single supplier provides.
The defence lineage here is direct. Zero trust did not begin as a commercial pattern; it hardened inside United States defence and intelligence networks after the intrusions of the late 2000s, on the premise that inherited trust and standing access were the main threat. The United States Department of Defense later turned that premise into doctrine in its Zero Trust Reference Architecture and its 2022 Zero Trust Strategy, with a department-wide target of fiscal year 2027. An agent that arrives inside a trusted vendor update, running under credentials no one scoped for it, is that same threat at the identity layer. It is the supply-chain-as-national-security concern the SolarWinds intrusion made concrete, moved one step closer to runtime. The question a defence architect asks of a change log is the one this chapter asks: what is now operating that no one decided to run?
Which of your vendor change logs in the last six months would have passed a review that was actually looking for agents, and who read it?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Gartner. "Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025." Press release, 26 August 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025. Figures and the Verma quotation corroborated by UC Today, "Gartner Predicts 40% of Enterprise Apps Will Feature AI Agents by 2026", 2 September 2025, https://www.uctoday.com/unified-communications/gartner-predicts-40-of-enterprise-apps-will-feature-ai-agents-by-2026/
[2] SAP News Center. "SAP Business AI: Release Highlights Q2 2026." July 2026. https://news.sap.com/2026/07/sap-business-ai-release-highlights-q2-2026/
[3] UX4Tech. "SAP's AI Agent Hub: The Governance Layer Every Enterprise Needs Before It Has 100 Agents." Published 4 May 2026, updated 13 July 2026. https://www.ux4tech.com/blog/sap-ai-agent-hub-enterprise-governance
[4] Cloud Security Alliance Lab. Research note on the Hugging Face autonomous-agent breach. 20 July 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-huggingface-autonomous-agent-breach-202607/
[5] TUANZ. 2026 Digital Priorities Report, published 29 April 2026, developed with One NZ. Launch coverage: Scoop, "TUANZ Launches 2026 Digital Priorities Report, Warning Of Growing Innovation Gap For New Zealand", https://www.scoop.co.nz/stories/SC2604/S00055/tuanz-launches-2026-digital-priorities-report-warning-of-growing-innovation-gap-for-new-zealand.htm; RNZ, "TUANZ seeks 'bold leadership' from government over AI worker training, national framework", https://www.rnz.co.nz/news/business/593697/tuanz-seeks-bold-leadership-from-government-over-ai-worker-training-national-framework