AI tools are making software abundant. This paper argues the scarce, differentiating capability is no longer writing code — it is letting more software exist safely: verified, narrowly permissioned, observable, and retired on time.
For CIOs, CISOs, architects and risk leaders in regulated enterprises. ~10 minutes, with deep-dives you can expand along the way.
Not every claim about AI coding deserves the same confidence. The paper is careful to separate what studies actually show from what remains an architectural bet. Tap each claim to see its evidence status — and what it means for how you build.
The honest answer: it has a different defect profile, not a uniformly worse one. A large 2025 study comparing 500,000+ human- and AI-generated samples found more high-risk security vulnerabilities in AI code — but more structural-complexity and maintainability problems in human code [6]. Studies of AI-attributed files on GitHub found most had no identifiable CWE-mapped vulnerability at all [7, 23].
The practical lesson: author identity is a poor trust signal. Verify every artifact based on the risk of what it wants to do — using the same secure-development frameworks that already exist (NIST SSDF, SLSA), made cheap and automatic [8, 9].
Drag the slider to make code generation cheaper — and watch where the organization's effort moves. Writing the code shrinks; assuring, authorizing and operating it grows. (Proportions are illustrative, as in the paper's Figure 1.)
Think of software as a flow-and-stock problem. AI increases the flow of new applications, scripts and connectors. But every accepted artifact adds to the stock of software that must be patched, authorized, observed, supported — and eventually deleted.
This is a rebound effect: when a capability gets cheaper, demand expands. A business unit that could justify five internal apps may now request fifty. Unit cost falls; portfolio cost rises, because the organization simply owns much more software.
The closest precedent is cloud computing: it made infrastructure on-demand, but forced enterprises to get better at identity, configuration, cost and governance [21]. AI does the same one layer up — with a twist: a generated app is semantically richer than a server. The enterprise must govern not only where code runs, but what the runtime is allowed to know and do.
Instead of trying to control every act of code generation, move the control point downstream: build one productized internal capability that converts untrusted artifacts — from any human or any AI tool — into controlled, observable, least-privileged applications. The code generator can change; the control plane doesn't.
Generated code may request capabilities. It must never grant itself capabilities. A manifest is a declaration of requested access; the platform and policy decide what is allowed.
An artifact travels through six separated planes on its way from source to production. Click a plane to see its job, its rules, and the open standards it can be built on. The technologies can vary; the separation of responsibilities cannot.
The paper's central formula: what an application can actually touch is the intersection of five independent constraints. The user doesn't inherit the app's powers; the app doesn't inherit the user's entitlements. Neither can escalate the other [10, 11, 13].
Access in wealth management is naturally relational: "RM manages client", "assistant is delegated by RM", "portfolio belongs to client". Relationship-based access control (ReBAC — the model behind Google's Zanzibar [13]) represents these links as authorization data, instead of re-implementing them inside every app. Attribute rules (ABAC [11]) then add context: jurisdiction, device posture, confidentiality flags, time-bounded delegation.
Delegation must stay visible. When the app calls downstream services, it exchanges the user's token for a narrower, target-specific one (OAuth 2.0 Token Exchange [12]) rather than hiding behind a broad service account. The audit trail keeps both: the person was the subject, the workload was the actor.
Application size is a poor risk proxy. A 300-line tool combining client data with internet egress is dangerous; a large read-only analytics app on aggregated data isn't. Compose a capability request and see which risk tier — and how much friction — it earns.
Apps should connect to governed data products, not raw databases. Direct database access externalizes governance into every consuming app — each must reimplement row filters, masking, client relationships and audit. AI makes that connector code easy to write, which just accelerates coupling. A mature data product instead publishes schema, semantics, owner, classification, authorization rules, masking behavior, rate and bulk limits, and retention — and enforces them at its own boundary for every consumer [15].
Protocols like MCP can be a useful adapter surface for AI clients, but they are not the enterprise authorization model: its own spec forbids token passthrough and requires audience-bound, per-target tokens — the security boundary stays at the governed gateway [16, 17].
A relationship manager asks an AI agent: "Show concentration, currency exposure and performance under three stress scenarios for my clients." Step through what happens — and notice what never happens.
The worst approach is designing a comprehensive platform while users keep shipping unmanaged scripts. Build incrementally — select a phase to see what it delivers.
Run the fabric as an internal product, not a ticket queue: golden paths for common patterns, fast feedback on rejections, and explicit, time-bounded exceptions. A rigid "golden cage" drives shadow IT; an invisible exception culture recreates unmanaged production [2, 22].
Counting AI licenses or generated lines of code is not useful. Measure delivery speed and control quality together [2].
The AI-era enterprise advantage will not come from generating the most code. It will come from safely turning abundant software artifacts into bounded, observable, least-privileged business capabilities — and retiring them when they no longer create value.
The productivity numbers will keep moving. The location of scarcity has already moved. Architecture investment should follow it: a strong production trust boundary, and a high-quality path across it.
The interactive chapters compress the paper's argument; this annex carries its requirement-level substance. Click through the capability manifest and the authorization decision record line by line, consult the full control matrix, and generate a requirement set for your own application idea.
Every line encodes a requirement on the platform, not a feature of the app. Click a line to see what it demands.
The record every sensitive access must leave behind — the live version is produced by the simulator in chapter 05. Click a line.
The D0–D4 scale behind the risk calculator's data axis in chapter 06.
Nine controls across five tiers. The highlighted column follows the capability request you composed in chapter 06 — or tap a tier to inspect it directly.
Compose a capability request (shared with chapter 06), name the application — and take away the applicable control checklist and a manifest skeleton to start from.
Research note. The paper deliberately separates empirical findings from architectural inference. The thesis does not require a universal speedup claim — only the modest observation that software production is becoming easier and more widely delegated, which raises the value of governed execution.