From Code Scarcity to Controlled Execution

Abstract

Software generation is becoming materially easier as coding agents and AI-assisted development tools improve. The precise productivity effect remains context-dependent and difficult to measure, but the direction of change is clear: more people can produce more code, delegation to AI systems is increasing, and organizations are experiencing greater pressure on coordination, testing, security review, deployment, and operating systems. Recent DORA research frames AI as an amplifier of the surrounding organizational system; recent empirical work on open-source development finds higher code contribution alongside increased coordination time; and current productivity experiments show both the rapid adoption of agentic tools and the difficulty of measuring work when developers change task selection and run multiple agents concurrently. [1–5]

This paper argues that the enterprise control point should move downstream. Rather than attempting to control every act of code generation, enterprises should make the path from source artifact to production execution explicit, automated, observable, and policy-governed. The proposed "Enterprise Software Fabric" accepts code, containers, manifests, and workflows from humans or AI tools; verifies and records provenance; evaluates requested capabilities; deploys only to controlled runtime environments; assigns workload identities; propagates user context; authorizes data access at governed product boundaries; and operates each application with telemetry, ownership, service levels, and retirement rules.

Private banking is used as the demanding reference case. A relationship manager may use an AI coding tool to create a portfolio stress-testing application, but neither the AI tool nor the resulting application should receive a broad production service account. Effective access should be the intersection of the application's approved capability, the current user's entitlement and relationship to the client, the data product's policy, the declared purpose, and the current context. This paper develops the architecture, risk model, operating model, and phased implementation roadmap for that approach.

1. Thesis and scope

The central thesis is deliberately narrower than the common claim that "AI will make software development free." Software is not becoming free, and evidence does not support a universal productivity multiplier. What is changing is the relative scarcity of activities across the software lifecycle. The ability to express business logic in working code is becoming more abundant. The ability to turn a growing stream of artifacts into trusted, properly authorized, maintainable production systems remains scarce.

That distinction matters because enterprise architecture follows bottlenecks. When servers were scarce and slow to provision, organizations optimized around hardware and capacity planning. Cloud computing standardized on-demand access to shared pools of configurable resources that could be provisioned and released with comparatively low management effort. [21] The cloud did not eliminate architecture, security, reliability, or cost management; it moved differentiation away from owning hardware and toward how organizations consumed and governed infrastructure. The comparable AI-era hypothesis is that code production becomes less differentiating while governed execution becomes more differentiating.

The paper therefore focuses on deploying the artifacts of AI-assisted software creation into controlled in-house environments. It is not a paper about training foundation models, hosting inference clusters, selecting model providers, or building a corporate chatbot. The generating tool may be Claude Code, Codex, Cursor, a future agent framework, a human development team, or a combination. The control architecture should not depend on authorship. The source artifact is outside the production trust boundary until it passes enterprise admission controls.

The proposed model is especially relevant to regulated enterprises with complex data estates, large numbers of internal workflows, and strong segregation requirements. Private banking is an illustrative case because client confidentiality, banker-client relationships, delegated coverage teams, jurisdictional constraints, and transactional capabilities create access-control problems that simple role-based models handle poorly.

2. What has actually changed: evidence and limits

2.1 The evidence supports a bottleneck shift more strongly than a universal speedup claim

The strongest credible argument is not that every developer is now several times faster. It is that AI-assisted and agentic tools are changing the volume, shape, and organization of software work. DORA's 2025 research describes AI primarily as an amplifier of existing organizational strengths and weaknesses, arguing that returns depend on the underlying organizational system rather than the tool alone. [1] DORA's platform-engineering guidance goes further: it describes coding gains being absorbed by downstream disorder in testing, security review, and deployment, and presents a high-quality internal platform as the standardization and governance layer that converts local speed into organizational performance. [2]

The empirical productivity literature is still evolving. METR's early-2025 randomized experiment found a slowdown for experienced open-source developers using then-current tools. Its February 2026 update says the later experiment is difficult to interpret because adoption became so widespread that some developers refused to participate if they might have to work without AI; developers also changed which tasks they submitted and increasingly ran multiple agents concurrently. METR believes early-2026 tools likely provide more speedup than early-2025 tools, but explicitly characterizes its own evidence about magnitude as weak. [3] This is a useful warning against basing architecture strategy on a single percentage productivity claim.

A revised 2026 study using GitHub Copilot usage data and public open-source project data reports a 5.9% increase in project-level code contributions, driven by increased participation and individual productivity, while coordination time increased by 8% because of more code discussions. [4] The important architectural signal is the coexistence of higher output and higher coordination cost. Even when the net effect is positive, the surrounding system must absorb more contributions, review more changes, reconcile more dependencies, and preserve shared standards.

Adoption patterns also show increasing delegation. The Anthropic Economic Index report based on privacy-preserving analysis of one million Claude.ai conversations and one million API transcripts reported that directive task delegation increased from 27% to 39% over eight months, with enterprise API usage skewing toward more automated and specialized tasks. [5] This does not prove that autonomous software production is dominant, but it supports the expectation that enterprises will receive a growing volume of artifacts produced with less continuous human attention.

2.2 Generated code should be treated as a different supply pattern, not a different trust category

Recent research on code quality supports caution without supporting panic. A 2025 large-scale study comparing more than 500,000 human- and AI-generated Python and Java samples found different defect profiles and reported more high-risk security vulnerabilities in AI-generated code, while human-written code showed greater structural complexity and more maintainability issues. [6] A separate 2025 preprint studying AI-tagged code in widely used GitHub projects reports that AI output concentrates in glue code, tests, refactoring, documentation, and boilerplate; it also reports that some vulnerability classes are overrepresented and that shallow human review can allow defects to persist. [7] Another large study of explicitly AI-attributed GitHub files found that most analyzed files had no identifiable CWE-mapped vulnerability, again underscoring that "AI code is insecure" is too crude a conclusion. The practical lesson is that author identity is a poor trust signal.

Existing secure-development frameworks therefore remain relevant, but must be made cheaper and more automated. NIST's Secure Software Development Framework recommends integrating a core set of secure-development practices into each software lifecycle. [8] SLSA provides a mature vocabulary for producing artifacts, distributing provenance, and verifying artifacts and their build provenance. [9] The AI-era requirement is not to invent a parallel lifecycle for AI-authored code. It is to make secure intake and verification routine enough to handle a much larger flow of small applications and changes.

2.3 The creation side has organized itself: from vibe coding to agentic engineering

Since 2025 the creation side of the lifecycle has developed its own discipline. Google's May 2026 whitepaper on the AI-era SDLC describes a spectrum from casual "vibe coding" — prompt, accept the output, paste the error back — to "agentic engineering," in which AI acts as an implementation engine inside human-designed systems of specifications, tests, evaluations and guardrails. It also reports adoption figures that make the supply-side shift concrete: 85% of professional developers regularly use AI coding agents, 51% use them daily, and an estimated 41% of all new code is AI-generated as of early 2026. [25]

Two of its findings bear directly on this paper's thesis. First, agent output quality is dominated by the structure around the model, not the model itself — the "harness" of rule files, tools, sandboxes, guardrails and observability; on public benchmarks, changing only the harness moved a coding agent from outside the top 30 to the top 5 with no model change. Second, its closing claim — "generation is solved; verification, judgment, and direction are the new craft" — is the team-level statement of this paper's enterprise-level argument: when implementation becomes abundant, the differentiating investment moves to the systems that specify, verify, authorize and operate what is generated. [25]

The same source is equally clear about the limits. An "80% problem" persists: agents rapidly produce most of a feature, while the remaining edge cases, integration points and subtle correctness requirements still demand human judgment — and the failure modes have shifted from syntax errors to plausible-looking conceptual mistakes that pass shallow review. Unverified vibe-coded output accumulates maintenance and security debt. Fully generated software is therefore becoming production-usable exactly to the extent that a governed structure surrounds it — which is the fabric's job at enterprise scale, applied to every artifact regardless of how disciplined its producer was.

3. The economic shift: from implementation scarcity to controlled execution

Software economics can be viewed as a flow-and-stock problem. AI coding tools increase the flow of new source code, services, scripts, connectors, dashboards, workflow tools, and experiments. Each accepted artifact adds to the stock of software that must be owned, patched, observed, authorized, cost-managed, and eventually retired. The unit cost of initial implementation can fall while the total portfolio cost rises because the organization simply owns much more software.

This creates a software version of a rebound effect. When a capability becomes cheaper, demand often expands. A business unit that previously could justify five internal applications may now request fifty. Many of those applications may be small and valuable. But each production application still creates some combination of dependencies, credentials, data pathways, operational alerts, user support, vulnerability exposure, legal retention questions, and ownership obligations. This is an informed architectural inference rather than a measured universal law, but it is consistent with the observed increase in contribution volume and coordination demands. [2,4]

3.1 The new cost centers

• Assurance: testing, static and dynamic analysis, dependency review, provenance verification, policy checks, and human review proportionate to risk.
• Integration: stable contracts with operational systems and data products, schema evolution, semantic consistency, and dependency ownership.
• Authorization: workload identity, user-context propagation, relationship and attribute evaluation, token scoping, and auditability.
• Deployment: repeatable runtime targets, environment policy, secrets handling, network controls, admission rules, and rollback.
• Operation: telemetry, service-level objectives, incident response, cost controls, capacity, patching, and resilience.
• Lifecycle: named owners, periodic recertification, dependency upgrades, usage review, archival, and decommissioning.

3.2 The cloud analogy — useful, but incomplete

The cloud analogy is useful because cloud computing made infrastructure provisioning more on-demand and standardized, while forcing organizations to become better at identity, configuration, cost management, reliability, and governance. NIST's definition emphasizes shared configurable resources that can be rapidly provisioned and released with minimal management effort. [21] AI-assisted software creation can produce a similar abstraction shift at a higher layer: business logic can be created faster, but the enterprise still needs standardized execution and governance.

The analogy is incomplete because software artifacts are semantically richer than compute instances. A generated application embeds business assumptions, data transformations, user experiences, and operational actions. The enterprise fabric must therefore govern not only where code runs, but what the runtime is allowed to know and do.

3.3 The CapEx/OpEx inversion

The SDLC literature now frames the same economics at team level as a capital-versus-operating trade. Ad-hoc, unverified generation ("vibe coding") has near-zero upfront cost but a compounding operating burden: token-hungry fix-the-fix loops, maintenance of structurally inconsistent code, and security remediation after the fact. Disciplined agentic engineering inverts the model: a deliberate upfront investment in specifications, test and evaluation suites, and structured context for the agents, in exchange for a dramatically lower marginal cost per shipped feature. [25] The enterprise conclusion is the one this chapter draws from the flow-and-stock view: the durable investment is not in generating more code but in the surrounding system — and because that investment is reusable across every generated application, it is a platform, not a per-application tax.

4. Strategic response: an Enterprise Software Fabric

The strategic response proposed here is an Enterprise Software Fabric: a productized internal capability that converts untrusted software artifacts into controlled, observable, least-privileged applications. It is deliberately artifact-first. The generating model is not assumed to be inside the bank. The code generator can change without changing the production control plane.

DORA defines platform engineering around automation, self-service, repeatability, internal developer platforms, and golden paths that make secure and compliant build, test, and deployment easier. Its 2026 guidance explicitly links platform quality to whether AI adoption becomes organizational performance or downstream disorder. [2] The Enterprise Software Fabric extends that platform-engineering idea into four additional directions required for sensitive enterprises: capability-based admission, dual-principal authorization, governed data-product connections, and lifecycle accountability.

The same layering now has a name on the creation side: the "harness" — the rule files, tools, sandboxes, guardrails and observability wrapped around a coding agent, without which a model is not an agent at all; measured 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 enterprise 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 and are verified the same way.

4.1 What the fabric is

• A controlled artifact intake path: build, test, scan, sign, record provenance, and bind ownership.
• A policy-driven admission layer that evaluates the requested capability combination and risk tier.
• A set of controlled in-house deployment targets with workload identity, resource limits, network policy, and managed secrets.
• An authorization plane that combines application capability with end-user entitlement, relationships, purpose, and context.
• A governed connection layer to domain-owned data products and operational capabilities.
• A mandatory operational envelope: logs, traces, metrics, service levels, cost attribution, vulnerability status, and lifecycle state.

4.2 What the fabric is not

• It is not primarily a foundation-model hosting platform.
• It is not a shared production database account for "citizen developers."
• It is not a workflow in which security reviews every small application manually.
• It is not a single Kubernetes cluster presented directly to business users.
• It is not an assumption that code written by employees is trusted while code written by AI is untrusted. The same admission model applies to both.

4.3 Requirements become the scarce input — and move into the development loop

When implementation is cheap, the binding constraint moves upstream: the quality of what gets generated is bounded by the quality of the expressed intent. The SDLC literature describes the collapse directly — requirements stop being documents handed off between teams and become a conversation between humans and AI that produces specification and initial implementation simultaneously; the bottleneck is no longer human hands typing boilerplate but human minds defining the boundaries. [25]

For the enterprise this has two consequences. First, requirements must become executable artifacts rather than prose: specifications, acceptance tests and evaluation suites that both direct the generating agent and verify its output — tests communicate what "correct" means for the deterministic parts, evaluations for the non-deterministic ones, and together they are the contract that turns generation into engineering. [25] These artifacts belong in the repository, versioned and reviewed like code, because they are the durable statement of what the system is supposed to do — they outlive any particular generated implementation, and they are what makes regeneration safe.

Second, the fabric should treat requirements as first-class admission inputs. The capability manifest is exactly that: a machine-readable requirement statement — owner, purpose, audience, data needs, action types, egress, export — that policy can evaluate before anything runs and that survives as the application's contract in production. Admission rejections with fast, actionable feedback close the loop: they are requirements engineering performed by the platform, telling the requester what a deployable version of their intent would look like. And because purpose is declared at intake and checked at every authorization decision (Plane D), the requirement travels with the application through its whole life rather than dying in a document.

Skills follow the same shift. The roles that matter in an agentic organization — specification, decomposition, evaluation, architectural judgment — are requirements skills. [25] An enterprise that invests in a fabric but not in its people's ability to express verifiable intent will simply generate the wrong software faster.

5. Reference architecture

The reference architecture is organized into six planes. The logical planes can be implemented with different technologies; the architecture depends on the separation of responsibilities, not a particular vendor stack.

5.1 Plane A — artifact intake and software supply chain

The first plane turns source material into a verifiable artifact. The minimum output is not merely a container image. It is an artifact bundle: executable package, dependency inventory, test results, vulnerability findings, build provenance, policy-relevant metadata, owner, purpose, and capability request. NIST SSDF provides secure-development practices, while SLSA 1.2 provides concepts for increasing software supply-chain guarantees and verifying provenance. [8,9]

• Build in controlled, ephemeral environments rather than on a developer workstation.
• Record source revision, build inputs, builder identity, dependency lock state, and artifact digest.
• Generate an SBOM where appropriate and scan dependencies and container layers.
• Require explicit owner, business purpose, data connection requests, external egress needs, and write capabilities.
• Sign the artifact and admit only verified artifacts into protected environments.

5.2 Plane B — admission and risk evaluation

The admission layer evaluates the artifact and its requested capability combination. Policy should be executable where possible. Open Policy Agent's Kubernetes admission examples show a general model in which deployment requests can be rejected for violating rules such as allowed registries, required labels, or resource limits. [18] An enterprise fabric can apply the same principle at a richer business level: client data plus internet egress, bulk export, or trading write access should trigger stronger controls than an internal read-only application using market data.

5.3 Plane C — controlled runtime

The runtime target should be boring, standardized, and difficult to escape. It may be Kubernetes, virtual machines, serverless runtimes, or another internal platform, but it should expose a consistent control contract: workload identity, managed secret retrieval, default-deny network policy, approved egress destinations, resource quotas, runtime hardening, patching policy, and observable deployment state.

Workload identity should not depend on an IP address or a long-lived shared secret. SPIFFE is one example of an open workload identity framework: it defines standards for securely identifying software systems in dynamic environments and issuing short-lived cryptographic identity documents to workloads. [14] The architectural requirement is more general: every runtime workload must have a first-class identity that can be authorized independently from the human user.

5.4 Plane D — identity, delegation, and authorization

The authorization plane evaluates both who is using the application and which application is acting. NIST Zero Trust shifts control away from implicit trust based on network location toward users, assets, and resources, with authentication and authorization performed before access to protected resources. [10] NIST ABAC defines authorization in terms of attributes of subjects, objects, operations, and environment conditions evaluated against policy and relationships. [11] These principles are well suited to private banking, where entitlement depends on client relationships, booking centers, legal entities, role delegation, product restrictions, and transaction context.

5.5 Plane E — governed data products and operational capabilities

Applications should normally connect to governed data products and business capabilities rather than raw operational databases. Data mesh literature frames data ownership around business domains, data as a product, self-service platform infrastructure, and federated computational governance. [15] For this paper, the security implication is as important as the organizational one: the producer boundary can enforce classification, row filtering, field masking, permitted purpose, aggregation rules, and rate limits consistently for every consuming application.

5.6 Plane F — operational envelope

Every application that reaches production should inherit a minimum operational envelope: structured logs, traces, metrics, correlation identifiers, dependency mapping, health checks, cost attribution, security status, incident ownership, and lifecycle state. OpenTelemetry is an open, vendor-agnostic framework for generating, collecting, and exporting telemetry including traces, metrics, and logs; it is one concrete standard that can reduce instrumentation fragmentation. [19]

For banks, operational resilience is not merely convenience. The Basel Committee's principles for operational resilience are intended to strengthen banks' ability to withstand operational disruption, including technology failures and cyber events. [20] A proliferation of small AI-assisted applications must not create a proliferation of invisible, ownerless operational dependencies.

6. Least privilege for humans and software

The most important authorization rule in the proposed architecture is that application permission and human permission are separate constraints. A user does not automatically gain every capability the application possesses, and an application does not inherit every data entitlement the user has.

The intersection model prevents a generated application from becoming a privilege escalator. A relationship manager may be entitled to view certain client portfolios, while the portfolio-scenario application may only be approved for positions, valuations, and market data. The application cannot reach tax identifiers merely because the user can see them in another system. Conversely, the application may be generally capable of reading portfolio positions, but a particular relationship manager can only retrieve positions for clients within the manager's authorized relationship graph.

6.1 Relationship-based access for client coverage

Private-banking access is naturally relational. Typical facts include "RM manages client," "assistant is delegated by RM," "investment specialist supports relationship team," "client is booked in legal entity," and "portfolio belongs to client." A relationship-based authorization model can represent these links. Google's Zanzibar paper is a foundational example of a globally consistent authorization system used across major Google services. [13] The relevant lesson is not to copy Google's implementation, but to represent relationships as authorization data rather than embedding them separately in each application.

ABAC then complements the relationship graph with contextual rules: jurisdiction, device posture, employment status, client confidentiality flags, product constraints, time-sensitive delegation, and requested action. [11] In practice, a policy decision may combine ReBAC for "who is related to the client?" with ABAC for "is this operation allowed now under these conditions?"

6.2 Delegation should remain visible through service chains

When an application calls downstream services, it should not erase the originating user context or reuse a broad application credential. OAuth 2.0 Token Exchange defines a mechanism for exchanging a token for another token, including delegation and impersonation semantics. It explicitly describes a resource server exchanging a received access token for a new downstream token that can be more narrowly scoped for the target service. [12]

For sensitive workflows, delegation is generally preferable to invisible impersonation because the audit trail should retain both subject and actor. An authorization record should be able to say: the relationship manager was the subject, portfolio-scenario-app/v17 was the actor, the requested purpose was client review, and the data product released only the permitted fields for the specified client.

7. Risk-based data connections

The risk unit should be the capability combination, not merely the application label. A small application can be dangerous if it combines regulated data with broad export and unrestricted internet egress. A large internal analytics application can be lower risk if it operates on aggregated, non-client-specific data and has no write path.

7.1 Data sensitivity tiers

Four classification levels suffice — public, internal, confidential, secret — provided the top of the scale is defined by the right question. The differentiator between confidential and secret is not how sensitive a single record feels; it is single versus many. One client's data — identity, holdings, suitability — accessed in user context through an authorized relationship is confidential. A list of client-identifying data (CID) — client lists, bulk holdings, cross-client exports — is secret, because its exposure is a mass event that no individual relationship can justify. Every "bulk" control in this architecture is, at bottom, the machinery that stops confidential accesses from silently aggregating into a secret.

7.2 Capability risk dimensions

A practical risk score can be derived from dimensions rather than a single application class. The dimensions need not be multiplied mathematically, but they should be evaluated systematically:

• Data sensitivity: public, internal, confidential, or secret — where confidential covers a single client's data in user context and secret covers lists of client-identifying data.
• Breadth: one user, one client, one team, one legal entity, or enterprise-wide.
• Action reversibility: read, calculate, propose, write, transact, or irreversibly commit.
• External connectivity: none, allowlisted services, approved SaaS, or unrestricted internet egress.
• Exportability: screen-only, bounded report, structured export, bulk export, or continuous replication.
• Financial or client impact: informational, advisory support, client communication, order proposal, or transaction execution.
• Human oversight: none, sampled review, pre-action confirmation, four-eyes approval, or formal segregation of duties.

7.3 Risk ladder for application deployment

Two scales are in play and should not be confused: the C-levels (C1–C4) of §7.1 classify data; the L-levels below classify the application's whole capability request — data sensitivity combined with action, connectivity and exportability. Each level answers one intuitive question — "what is the worst this application could do?" — and the friction to deploy scales with the answer:

• L0 — Experiment: nothing real to lose. Synthetic or public data, no production access, fully isolated. A hackathon prototype. Ships in minutes, self-service, and expires automatically.
• L1 — Governed internal app: everyday internal tools. Read-only access to lower-sensitivity internal data. A team dashboard on operational metrics. Approval is automated; the price of entry is an owner, workload identity and telemetry.
• L2 — Confidential app: real business data. Confidential business data with narrow scopes. A budgeting tool on internal financials. Still largely automated, but with evidence requirements and periodic recertification.
• L3 — Client-specific regulated app: the relationship graph decides. Single-client reads and bounded client workflows with anti-bulk controls — the confidential tier's client-scoped flavor, where relationship authorization is mandatory. The relationship manager's portfolio-review app of §9. Governed: full audit chain and enhanced change control — days, not minutes.
• L4 — Transactional capability: it can move money. Payments, orders, trades, mandates, master-data changes. Deliberately difficult by design: transaction caps, separation of duties, human or four-eyes approval.

The productivity objective is to make L0 and L1 extremely fast, L2 largely automated, L3 governed but usable, and L4 deliberately difficult. A 300-line internal tool should not require the same governance path as a core-banking replacement. But small size must never become an argument for a shared production database password.

7.4 The vibe-coding lane: automated admission plus randomized controls

The fabric fails its purpose if it only serves disciplined engineering teams. Most of the new abundance will be vibe-coded: produced quickly, often by non-specialists, without a curated harness or a test suite worth the name. [25] Forcing all of it through heavyweight review recreates the bottleneck and drives shadow IT; blocking it wastes the abundance. The fabric therefore needs an explicit lane that is easy by default and safe by construction — and the tier the lane lands in follows the stakes of the topic, never the authorship or the line count. A lunch-menu tool and a payment tool must never share a control envelope, however similar their code looks.

Easy by default. For the low tiers — L0, L1, and much of L2 — admission is fully automated: manifest completeness, provenance, dependency and container scans, policy evaluation of the capability combination. Minutes, not meetings. The safety does not come from the code's internal quality; it comes from the envelope the code executes in. Workload identity, default-deny egress, short-lived scoped tokens, and producer-side data-product enforcement bound the blast radius of sloppy code just as effectively as of careful code. That is the point of moving the control downstream: the fabric makes vibe-coded software deployable precisely because it never has to trust it.

Safe over time — by sampling, not by universal review. The fabric explicitly rejects manual review of every small application (§4.2); what replaces it is randomized, risk-weighted controls. A sampling process continuously draws deployed applications for spot-check audits: code quality, manifest-versus-actual-behavior drift, over-privilege, data handling, ownership freshness. The sampling probability is not uniform — it scales with risk tier, with anomaly signals from the operational envelope (unusual egress attempts, growing scopes, error patterns), and with the producer's track record. This is statistical quality control, the same logic as customs inspection or tax audit: full coverage is unaffordable, but a credible chance of being inspected changes behavior everywhere — and, unlike assumed defect rates, sampling measures the portfolio's true quality.

Findings compound. A recurring audit finding becomes a new automated admission check or a golden-path template fix, so the sampled few improve the unsampled many. Consequences are graduated — re-certification, scope reduction, accelerated expiry — not one-size enforcement. And the boundary stays honest: sampling is how the low-friction lane earns its trust; it never substitutes for the mandatory controls of L3 and L4, which keep their full envelope regardless.

8. Complex data products as security contracts

AI coding tools become far more useful when they can compose stable enterprise capabilities instead of discovering undocumented schemas and reconstructing business semantics from source tables. This is why data-product maturity and AI-assisted development are complementary investments.

Data mesh principles emphasize domain-oriented ownership, data as a product, self-service infrastructure, and federated computational governance. [15] The paper's extension is to treat the data product not only as a high-quality dataset, but as a secure consumption contract. A mature product should publish schema, semantics, freshness and service levels, owner, classification, lineage, supported purposes, authorization rules, masking behavior, aggregation restrictions, retention rules, and interface contract.

8.1 Avoid raw database connectivity as the default integration pattern

Direct database access externalizes governance into every consuming application. The consumer must understand table semantics, row filters, client relationships, masking rules, schema changes, and audit expectations. AI may make the connector code easy to write, but that simply accelerates coupling and duplicates policy. Governed products invert the model: the producer owns semantics and enforces policy at a stable boundary; the application receives only the capability it needs.

8.2 Where MCP fits — and where it does not

The Model Context Protocol can be useful as a standard interface through which AI clients discover and invoke tools or resources, but it should not be mistaken for the enterprise authorization model. The MCP authorization specification defines transport-level authorization for HTTP transports and uses OAuth-based mechanisms. It requires resource indicators, audience validation, and separate authorization treatment for downstream APIs; it explicitly forbids token passthrough. [16] The associated security guidance explains that token passthrough creates accountability, audit-trail, trust-boundary, and exfiltration risks. [17]

In the Enterprise Software Fabric, MCP can be an adapter surface or developer-facing protocol, while the actual enterprise security boundary remains a governed gateway or data-product interface. An MCP server that calls a client-data API should acquire a separate target-specific token rather than forwarding a user token blindly. The user, workload, target resource, and purpose should remain visible to the authorization system.

9. Private banking reference scenario

Consider a relationship manager who asks an AI coding agent to build a portfolio stress application: "Show current concentration, currency exposure, and performance under three historical stress scenarios for my clients." The agent can generate a user interface, backend service, tests, container configuration, and capability manifest. The tool may run outside the production environment. It never receives production client data or production database credentials.

9.1 Build and admission path

• The agent produces source code and a manifest declaring required products and actions.
• The source is committed to an enterprise-controlled repository. Ownership and purpose are mandatory metadata.
• A controlled build creates an immutable artifact, records provenance, produces dependency inventory, runs tests and scans, and signs the result. [8,9]
• Admission policy evaluates runtime configuration and the capability combination: market data read, portfolio positions read in user context, client-profile fields domicile/risk profile/investment horizon, no trading write, no internet egress.
• The approved artifact is deployed to a controlled runtime, receives a workload identity, and inherits telemetry and support metadata. [14,19]

9.2 Runtime request path

• The relationship manager authenticates to the application.
• The application requests portfolio positions for a specific client and states the approved purpose.
• The policy system evaluates the workload identity, user identity, relationship graph, user attributes, client attributes, requested operation, purpose, and environmental conditions. [10,11,13]
• If allowed, the application receives or obtains a narrowly scoped, short-lived token for the portfolio data product; downstream delegation remains visible. [12]
• The data product independently enforces client and field-level policy, rate limits, and anti-bulk behavior, then returns only permitted records.
• The authorization decision and data access are correlated with application telemetry and audit records.

9.3 The crucial negative guarantees

• The AI coding tool never needs a production credential.
• The generated source code never contains the list of clients the relationship manager may access.
• The application does not receive a service account that can read every client portfolio.
• Client filtering is not entrusted only to application code; it is enforced at authorization and data-product boundaries.
• Trading write access is a distinct capability, not an accidental extension of portfolio read access.

9.4 Transactional capabilities require a different control envelope

A scenario-analysis application may be permitted to propose an order but not place it. A separate transactional capability can require short-lived action-specific authorization, transaction value limits, product suitability checks, pre-trade controls, segregation of duties, and explicit human confirmation or four-eyes approval according to policy. Read access and write access should never be bundled merely for developer convenience.

The architectural principle is "proposal versus authority" at two layers. AI-generated code proposes requested capabilities to the deployment fabric. Decision-support applications propose business actions to the transactional control system. In both cases, authority belongs to policy-governed systems and accountable humans, not to the code generator.

10. Operating model and governance

The Enterprise Software Fabric should be run as an internal product, not as a ticket queue. DORA's platform-engineering guidance emphasizes product management, user journeys, self-service golden paths, clear feedback, and an incremental minimum viable platform. [2] The objective is enabling constraint: make the safe path easier than bypassing it.

10.1 Responsibilities

10.2 Golden path and exception path

The golden path should cover common application patterns: internal web app, scheduled job, event consumer, API service, analytical dashboard, and workflow tool. A software template can scaffold repository structure, pipeline configuration, manifests, telemetry, and ownership metadata; Backstage Software Templates are one example of this pattern. [22] The implementation technology is secondary. The important feature is that common controls are inherited rather than reimplemented. The golden path also carries the vibe-coding lane of §7.4: automated admission for the low tiers, randomized risk-weighted spot checks afterwards, and audit findings flowing back into the templates — so the path gets safer as it gets busier.

Exceptions are necessary for unusual workloads, but they should be explicit, time-bounded, owned, and measurable. A rigid "golden cage" will drive shadow IT; an invisible exception culture will recreate unmanaged production. The platform should provide fast feedback on why a request was rejected and what changes would make it acceptable.

The developer roles the golden path serves are shifting as well: from "conductor" — hands-on, real-time direction of an AI assistant — toward "orchestrator" — asynchronous delegation to background agents, with review of results. [25] The platform should assume both modes and surface policy feedback in both: inline for the conductor, attached to the agent's pull request for the orchestrator. The SDLC literature's warning applies to the fabric itself: AI amplifies the engineering culture it lands in — a strong platform converts that amplification into organizational performance, a weak one into disorder. [2,25]

10.3 Lifecycle ownership is a security control

Every deployed application should have a named business owner, technical owner, cost center, support tier, dependency inventory, last-use signal, and review date. Low-risk applications can expire automatically unless renewed. Orphaned applications should lose sensitive connectivity before they become invisible legacy systems. This is one of the places where the economics of abundant code must be confronted directly: the enterprise needs a deletion pathway as polished as its creation pathway.

11. Implementation roadmap

The architecture should be built incrementally. The worst approach is to design a comprehensive enterprise platform for two years while users continue creating unmanaged scripts and integrations. The roadmap below starts with the trust boundary, then adds identity and data governance sophistication.

Phase 1 — establish the production trust boundary (0–90 days)

• Create one controlled deployment target for a narrow class of internal applications.
• Require enterprise repository, controlled build, immutable artifact, owner, purpose, and basic security checks.
• Prohibit embedded production credentials and direct unmanaged secrets.
• Issue workload identity; apply default-deny egress with allowlisting.
• Provide standard telemetry, health checks, dashboards, and cost attribution.
• Use synthetic or low-sensitivity data for the first self-service path.

Phase 2 — capability manifests and risk tiers (3–6 months)

• Introduce a declarative capability manifest for data products, business actions, egress, export, and audience.
• Implement risk-tier calculation and policy-as-code admission checks.
• Create a catalog of approved data products and operational APIs.
• Automate L0–L1 approval; establish clear evidence requirements for L2–L4.
• Introduce application expiry, ownership recertification, and policy exception tracking.

Phase 3 — dual-principal authorization (6–12 months)

• Propagate authenticated user context to the authorization plane.
• Model key client and coverage relationships in a consistent authorization graph.
• Combine relationship checks with ABAC context and purpose rules.
• Introduce delegated, target-specific downstream credentials using token exchange patterns where appropriate. [12]
• Require data products to enforce producer-side client and field-level policy.

Phase 4 — scale application creation safely (12+ months)

• Expand golden paths to more workload types and business-user-assisted creation.
• Allow multiple approved coding agents and development environments above the same artifact trust boundary.
• Expose policy feedback directly in developer and agent workflows without giving generators authority to bypass policy.
• Add continuous portfolio optimization: identify duplicate applications, unused apps, excessive scopes, stale exceptions, and expensive integrations.
• Extend the model to bounded transactional capabilities with strong separation of duties.

12. Metrics that reveal whether the model works

A successful fabric should be measured on both delivery speed and control quality. Counting AI licenses or lines of generated code is not useful. DORA recommends balanced software-delivery and platform metrics, including lead time, deployment frequency, recovery time, change failure percentage, and rework. [2] The fabric also needs access- and lifecycle-specific measures.

13. Design principles

• 1. Trust the verified artifact, not the author. Human-written and AI-assisted code enter the same admission process. Authorship may affect review evidence, but it does not create production authority.
• 2. Code requests capabilities; policy grants capabilities. Source code and manifests are requests. Runtime access is granted externally by platform and authorization controls.
• 3. Make narrow access easy and broad access hard. The platform should optimize for least-privileged connections, not force teams to seek broad service accounts because fine-grained access is too slow.
• 4. Preserve both user and workload identity. Sensitive data access should be attributable to the person and the software actor. Neither identity should disappear behind the other.
• 5. Separate read, propose, write, and transact. These actions have different reversibility and risk. They require different capabilities and controls.
• 6. Enforce policy at producer boundaries. Client filtering, field masking, and anti-bulk controls should not depend solely on each consuming application implementing policy correctly.
• 7. Prefer short-lived, audience-bound, delegated credentials. Standing broad credentials create silent blast radius. Downstream access should be narrow, target-specific, and auditable. [12,16,17]
• 8. Apply friction according to risk combination. Application size is not a risk proxy. Sensitive data, breadth, egress, export, and transactional authority drive control intensity.
• 9. Build paved roads, not policy documents. The safest path should be self-service, automated, and observable; controls that exist only in documentation will not scale with abundant artifact production.
• 10. Make deletion a first-class platform feature. Every production artifact creates future obligations. Expiry, recertification, and decommissioning are part of software economics and security.

14. Conclusion

The most important enterprise consequence of Claude, Codex, Cursor, and similar tools may not be a particular productivity percentage. It may be a change in the location of scarcity. When many more people can produce useful software artifacts, the institution's differentiating capability becomes the ability to let more software exist safely.

That requires a shift in architecture investment. The enterprise should not concentrate only on controlling which AI coding tool employees use. It should establish a strong production trust boundary and a high-quality path across it: controlled builds, provenance, risk-based admission, controlled runtime targets, workload identity, user-context authorization, delegated credentials, governed data products, observable operations, and lifecycle ownership. DORA's system-level framing, recent empirical evidence on higher contribution and coordination demands, established zero-trust and authorization principles, software supply-chain standards, and data-product thinking all point in this direction. [1–4,8–15]

For private banking, the architecture is especially clear. A relationship manager should be able to create or sponsor a small, valuable application quickly. The resulting application should never need a credential that can read the bank's entire client base. Effective access should be calculated at runtime from the intersection of application capability, user entitlement and relationship, data-product policy, purpose, and context. The data provider should enforce its own policy, and every decision should remain attributable to both user and workload.

Appendix A. Example capability manifest

The following illustrative manifest shows the type of declarative input the platform can evaluate. It is intentionally technology-neutral; the syntax is only an example. (An annotated, clickable version lives in the interactive edition's Annex.)

application:
  name: portfolio-scenario-app
  owner: wealth-advisory-zurich
  purpose: client-portfolio-review
  audience: relationship-managers

runtime:
  internet_egress: false
  workload_identity: required
  support_tier: business-hours
  expiry_review_days: 180

data_connections:
  - product: market-data.prices
    action: read

  - product: wealth.portfolio-positions
    action: read
    user_context_required: true
    relationship_required: manages_or_delegated
    bulk_export: false

  - product: crm.client-profile
    action: read
    fields:
      - domicile
      - risk_profile
      - investment_horizon

operational_capabilities:
  trading.read: false
  trading.propose: false
  trading.write: false

observability:
  traces: required
  metrics: required
  audit_correlation: required

Appendix B. Example authorization decision record

timestamp: 2026-07-05T10:14:22Z
decision: allow
subject_user: employee-9382
actor_workload: spiffe://bank.internal/app/portfolio-scenario/v17
purpose: client-portfolio-review
target_resource: wealth.portfolio-positions
operation: read
client_scope: client-4711
relationship_path: employee-9382 -> primary_rm -> client-4711
policy_bundle: PB-PORTFOLIO-READ-v12
issued_scope: positions.read client:4711
token_audience: https://portfolio-data.bank.internal
expires_in: 300s
correlation_id: 19d8a6d2-...

Appendix C. Risk-tier control matrix

References

Research note. This paper deliberately separates empirical findings from architectural inference. Productivity estimates for AI-assisted development are still unstable and context-dependent. The architecture thesis does not require a universal speedup claim; it depends on the more modest observation that software artifact production is becoming easier and more widely delegated, increasing the value of scalable validation, governed deployment, identity, data-product boundaries, and lifecycle control.