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.

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.

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.

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.

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

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, regulated, or client-specific restricted.
• 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

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.

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.

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.

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.