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.
The team-level SDLC literature reaches the same conclusion as a CapEx/OpEx trade: unverified "vibe coding" is cheap to start and expensive to own — fix-the-fix loops, maintenance of inconsistent code, security remediation after the fact. Disciplined "agentic engineering" front-loads investment in specs, tests and evaluations to cut the marginal cost of every shipped feature [25]. The fabric is that upfront investment, made once at the enterprise boundary instead of once per team.
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.
The creation side has its own name for structure-around-the-model: the "harness" — rule files, tools, sandboxes, guardrails and observability wrapped around a coding agent; without it a model is not an agent at all. On public benchmarks, harness changes alone moved agents dozens of leaderboard places with no model change [25].
Harness and fabric are the same idea at two altitudes, and they compose: the team's harness governs how software is generated; the fabric governs whether and how the result may execute. The capability manifest is the handoff artifact between them. Crucially, the fabric must not assume a well-run harness upstream — artifacts from a disciplined agentic-engineering team and from an afternoon of vibe coding enter the same admission process.
When implementation is cheap, the binding constraint moves upstream: what gets generated is only as good as the expressed intent. Requirements stop being documents handed off between teams and become a conversation that produces spec and implementation simultaneously — the bottleneck is no longer hands typing boilerplate but minds defining boundaries [25].
Two consequences. Requirements must become executable artifacts — specs, acceptance tests and eval suites, versioned in the repo like code — because they direct the agent, verify its output, and outlive any generated implementation (they are what makes regeneration safe). And the fabric should treat requirements as admission inputs: the capability manifest is a machine-readable requirement — owner, purpose, data, actions, egress — that policy evaluates before anything runs, and rejection-with-feedback is requirements engineering performed by the platform. The scarce skills follow: specification, decomposition, evaluation, judgment. A fabric without people who can express verifiable intent just generates the wrong software faster.
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. Each tier answers one question — what is the worst this app could do? — and friction scales with the answer.
Most of the new abundance will be vibe-coded: built quickly, often by non-specialists, with no test suite worth the name [25]. The fabric must give it an easy, safe lane — heavyweight review recreates the bottleneck and drives shadow IT; blocking wastes the abundance. Easy: for L0–L1 (and much of L2) admission is fully automated — minutes, not meetings. Safety comes from the envelope, not the code: workload identity, default-deny egress, scoped short-lived tokens and producer-side data enforcement bound the blast radius of sloppy code just as well as of careful code. The tier follows the stakes of the topic, never authorship or line count — a lunch-menu tool and a payment tool never share a lane.
Safe over time: instead of reviewing every small app, the platform runs randomized, risk-weighted spot checks on deployed applications — code quality, manifest-vs-behavior drift, over-privilege, data handling. Sampling probability scales with tier, telemetry anomalies and producer track record. It's statistical quality control, like customs or tax audits: full coverage is unaffordable, but a credible chance of inspection changes behavior everywhere — and it measures the portfolio's true defect rate. Findings compound into new automated admission checks and template fixes; consequences are graduated (re-certification, scope reduction, faster expiry). Sampling never discounts L3/L4 — the mandatory envelope stays.
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.
Public, internal, confidential, secret. The differentiator between confidential and secret is single versus many: one client's data in an authorized relationship is confidential; a list of client-identifying data (CID) is secret. In the calculator, a separate client-scope toggle marks single-client confidential data — that combination is what drives L3.
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.