European data spaces as agentic commerce infrastructure

The digital economy of the European Union rests, in policy terms, on the premise that data sovereignty (the capacity of data producers to retain meaningful control over the conditions under which their data is accessed and used) is both a competitive and a constitutional imperative. The institutional expression of this premise is a family of interconnected initiatives: Gaia-X, which defines the trust, labelling, and governance framework for federated cloud and data infrastructure; the International Data Spaces Association (IDSA), which specifies the reference architecture and connector protocols for sovereign data exchange; and the dataspaces.eu ecosystem, which hosts the Data Spaces Support Centre (DSSC) and coordinates sector-specific deployments across energy, health, mobility, agriculture, and manufacturing.

In parallel, a second trajectory is advancing. Agentic commerce, defined as the deployment of autonomous AI agents that execute commercial workflows including product discovery, dynamic pricing, contract negotiation, and payment settlement without step-by-step human instruction, is transitioning from research prototype to commercial deployment [6][7]. The functional requirements of agentic commerce are categorically different from the requirements that shaped the IDSA and Gaia-X design process. Agentic systems require sub-second data access decisions, machine-to-machine negotiation protocols, dynamic policy delegation, and autonomous payment constructs. Current data space specifications were designed for controlled, policy-governed, largely synchronous data sharing between enterprise principals acting under explicit human authorization.

The intersection of these two trajectories produces a research problem of direct operational relevance. Payments practitioners, platform architects, and AI-governance regulators require an evidence-based assessment of three questions: what European data space infrastructure can deliver today in support of agentic commerce workflows; what remains aspirational at the level of specification, roadmap, or working-group proposal; and what the realistic production-readiness timeline is, differentiated by vertical sector and deployment scope.

This paper makes four contributions, labelled C1 through C4, which structure the analysis in subsequent sections and are carried through to the discussion and conclusion.

C1: Functional requirement mapping. The paper maps the functional requirements of agentic commerce systems against the current deployable capabilities of IDSA connector specifications, Gaia-X Trust Framework releases, and dataspaces.eu DSSC deliverables, producing a six-requirement capability gap analysis.

C2: Identification of the systemic rate-limiting dependency. The paper identifies decentralized cross-domain identity and trust portability as the systemic rate-limiting dependency for the entire agentic data space stack, drawing on recent work in self-sovereign identity (SSI) architectures [5].

C3: Documentation of the scope mismatch. The paper documents the category-level mismatch between the static, policy-governed data-sharing model embedded in current data space architectures [1][3] and the dynamic, autonomous transaction model demanded by agentic commerce [6][8].

C4: A falsifiable deployment hypothesis. The paper advances the hypothesis that production-grade agentic commerce deployment on European data space infrastructure will occur first in regulated, bounded verticals, specifically energy [4], within a three-to-five-year window, and that this deployment will precede, rather than follow, the establishment of adequate security governance and liability attribution frameworks, positioning security and accountability failures, not interoperability failures, as the primary material risk.

The paper is structured as follows. Section 2 motivates the inquiry by situating the confluence of these two trajectories within the current regulatory and commercial landscape. Section 3 reviews prior work across the five relevant evidence clusters. Section 4 describes the analytical methodology. Section 5 presents the findings on deployability, capability gaps, and timeline. Section 6 interprets the findings against the broader literature and the four contributions. Section 7 concludes with direct implications for practitioners and policy actors. Limitations and references follow.

Three concurrent pressures make this assessment necessary at the present moment rather than at some future point when data space infrastructure has stabilized.

Regulatory activation. The EU Data Act was published in the Official Journal on 11 December 2023 and entered into force on 11 January 2024; however, most operative obligations, including the mandatory data-sharing requirements for connected product manufacturers and the rules governing data intermediaries, apply from September 2025. A production agentic commerce system must therefore be designed for these obligations now, even though enforcement does not yet apply. The AI Act's phased implementation schedule disaggregates obligation categories across distinct dates: provisions on prohibited AI practices and general-purpose AI model obligations apply from August 2025; conformity assessment requirements for Annex I high-risk AI systems apply from August 2026; and a further transition period extends to August 2027 for certain high-risk AI systems embedded in products already subject to sectoral safety legislation. Agentic commerce systems will satisfy the high-risk classification in many deployments, placing their conformity assessment obligations in the August 2026 to August 2027 window. eIDAS 2.0, with its digital identity wallet infrastructure, is scheduled for member-state rollout within the same period. Each of these instruments relies on data-sharing mechanisms that are architecturally related to, but inconsistent with, the IDSA and Gaia-X models. A production agentic commerce system operating within the EU must simultaneously satisfy obligations arising from at least three partially contradictory regulatory regimes, and the implementation cost of navigating these overlaps falls on the deploying organization. Regulatory obligations accrue on a fixed legislative schedule independent of infrastructure maturity.

Commercial acceleration. Enterprise adoption of autonomous AI agents for procurement, logistics, and payments is proceeding in advance of infrastructure standardization. Cloud hyperscalers offer proprietary data-sharing mechanisms, specifically data marketplace APIs and managed connector services, that provide immediate functionality at the cost of vendor lock-in and loss of the data sovereignty guarantees that European data space standards are designed to provide. Organizations that commit to hyperscaler-native integration paths before European standards mature face structural switching costs when sovereign alternatives become deployable, and those switching costs compound as hyperscaler-native dependencies deepen over time. Organizations that delay integration decisions until European standards mature face the same compounding dynamic from the opposite direction: the longer the delay, the greater the organizational inertia embedded in proprietary integration paths.

Security exposure without governance. Agentic systems operating within federated, multi-party data spaces introduce attack surfaces that current data space security models do not address. Prompt injection attacks directed at connector-layer policy evaluation, cascading authorization failures across federated nodes, and identity misuse by compromised agent credentials represent threat vectors that are qualitatively different from the data-at-rest and data-in-transit controls that current IDSA security specifications address [8][9]. The absence of an adopted, agentic-aware threat model from any authoritative body (ENISA, the IDSA security working group, or national cybersecurity authorities) means that deployments are proceeding into a threat landscape that has not been formally characterized.

The populations directly affected by the maturity gap between data space ambition and deployable reality include: enterprise technology architects evaluating integration strategy for AI-driven procurement systems; payments infrastructure operators designing authorization flows for autonomous agent transactions [6]; EU regulatory compliance teams assessing conformity obligations for AI systems that consume federated data; and sector-specific data space operators in energy and health who are closest to production deployment. Each of these populations requires a calibrated, evidence-grounded assessment of what exists, what is roadmap, and what is aspiration, which is precisely the assessment this paper provides.

The relevant prior work spans five clusters, each of which this paper extends or synthesizes in a specific direction.

Data space architecture and governance foundations. Otto [1] provides the most comprehensive treatment of the intellectual and institutional genealogy of data spaces, tracing the transition from bilateral data-sharing agreements through sectoral data pools to the federated data space model. The paper defines the core architectural constructs (connectors, brokers, identity providers, clearing houses) and positions Gaia-X and IDSA within the international standards landscape. This paper builds on Otto's taxonomy but extends it in a direction his analysis does not pursue: the evaluation of whether those constructs are sufficient for the functional requirements that agentic commerce imposes. Tardieu [2] provides an institutional account of Gaia-X's formation, motivations, and governance structure, with emphasis on the geopolitical rationale for European digital sovereignty. Tardieu's contribution is primarily descriptive and policy-oriented; the present paper subjects the resulting architecture to a functional stress-test against agentic commerce requirements that Tardieu's work predates and does not address.

Reference enterprise architectures for sovereign data exchange. Firdausy et al. [3] propose a reference enterprise architecture specifically designed to operationalize digital sovereignty within International Data Spaces. Their architecture maps IDSA connector roles, policy enforcement mechanisms, and trust chain components into an enterprise-deployable configuration. This work is the closest prior art to the methodology employed in this paper: it evaluates deployability against a defined functional requirement. The present paper differs in two respects. It applies the deployability evaluation to agentic commerce requirements rather than generic enterprise data exchange, and it incorporates the identity and security capability gaps, neither of which Firdausy et al. treat as primary failure modes, as the central structural constraints.

Vertical sector deployment: energy. Wehrmeister et al. [4] present the BD4NRG reference architecture, which integrates IDSA, Gaia-X, and FIWARE within an energy-sector big data application framework. This is among the most technically specific publications available on a working sector-specific data space deployment. The work demonstrates that a bounded, sector-specific instantiation of data space principles can achieve sufficient specificity to be operationally relevant. This paper uses the BD4NRG case as evidence for the vertical-first deployment hypothesis and draws on its architectural choices to characterize the conditions under which production readiness is achievable within the three-to-five-year window.

Identity, trust, and cross-domain interoperability. Jeyakumar and Kubach [5] present a trust implementation model for cross-domain decentralized identity ecosystems, including a concrete architecture using verifiable credentials and SSI constructs. Their work identifies the specific protocol and governance gaps that prevent cross-domain identity assertions from being mutually recognized across independently operated data spaces. This paper treats Jeyakumar and Kubach's findings as direct evidence for the claim that decentralized cross-domain identity is the systemic rate-limiting dependency for agentic data space deployment, and extends their analysis to the specific case of agent credential delegation, a requirement they do not address.

Agentic commerce systems: requirements and risks. Dusad [6] characterizes the paradigm shift from human-mediated to autonomous AI-driven transactions, with attention to payment system implications. Basu [7] addresses agentic commerce in the retail and e-commerce sector, cataloguing autonomous workflow patterns. Pachaiyappan [8] provides the most systematic available treatment of cybersecurity risks, privacy challenges, and trust mechanisms specific to agentic commerce marketplaces, including prompt injection, data poisoning, and cascading failure modes. Maji [9] focuses on security risks within autonomous decision loops in discovery, pricing, and routing, which are the exact functional domains that an agentic system operating on a European data space would need to exercise. This paper synthesizes [6], [7], [8], and [9] as a coherent requirement and threat specification against which the data space infrastructure is evaluated, an integration that none of those individual papers performs, since none of them addresses European data space infrastructure as the operational context.

This paper employs a structured capability gap analysis. The method proceeds in four stages: requirement elicitation, capability inventory, gap mapping, and timeline inference. Each stage is described below with sufficient detail to permit reproduction by an attentive analyst working from the same source corpus.

Stage 1: Requirement elicitation. The functional requirements of agentic commerce systems were derived from the four agentic commerce publications in the corpus [6][7][8][9]. From these sources, six primary functional requirements were extracted that any data-access infrastructure layer must satisfy to support production agentic commerce: (R1) real-time or near-real-time data access with latency constraints compatible with autonomous decision loops; (R2) machine-to-machine authentication and authorization without human-in-the-loop credential issuance at runtime; (R3) dynamic policy delegation, permitting an agent to receive scoped data-access permissions from a principal and re-exercise them within bounded constraints; (R4) machine-negotiable contract primitives, enabling agents to agree on data-sharing terms without human contract execution; (R5) autonomous payment constructs, permitting agents to initiate, authorize, and settle micropayments or usage-based charges within pre-authorized limits; and (R6) cross-domain trust portability, enabling an agent credentialed in one data space to be recognized as a trusted principal in a second, independently governed data space. These six requirements constitute the evaluation rubric applied throughout the analysis.

Stage 2: Capability inventory. The deployable capabilities of the European data space ecosystem were inventoried from three primary sources within the corpus: Otto [1] for the conceptual and specification-layer capability baseline; Tardieu [2] for Gaia-X Trust Framework capabilities; and Firdausy et al. [3] for IDSA Reference Architecture Model capabilities at the enterprise deployment level. The energy-sector deployment evidence from Wehrmeister et al. [4] was treated as the most advanced observable sector-specific instantiation for which published architectural documentation exists. Jeyakumar and Kubach [5] provided the capability inventory for the identity and trust layer specifically.

For each of the six requirements, a three-level classification was applied: Deployable (the capability is specified at sufficient resolution and has been demonstrated in at least one sector-specific deployment); Roadmap (the capability is identified in published working group materials or specifications as a planned extension, with no deployment demonstration yet recorded); or Aspirational (the capability is discussed in the literature as desirable, with no published specification or roadmap commitment within the IDSA/Gaia-X ecosystem).

Stage 3: Gap mapping. Each gap between a stated requirement and the inventoried capability level was characterized along two dimensions: structural depth (whether the gap reflects an absence of specification, an absence of implementation, or an absence of governance) and dependency type (whether closing the gap requires standards body action, regulatory action, or market adoption).

Stage 4: Timeline inference. Production-readiness timelines were inferred from the convergence of three signals: the stated publication targets in available DSSC and IDSA roadmap documentation, the observed pace of standardization in analogous prior infrastructure programs (drawing on the historical pattern described in [1]), and the regulatory implementation schedules for Data Act, AI Act, and eIDAS 2.0 as documented in the corpus. Where signals were inconsistent, the more conservative estimate was adopted. All timeline statements in this paper are structural inferences rather than citations of published deployment forecasts, and that epistemic status is maintained throughout the results section.

Scope and assumptions. This analysis is bounded to European data space standards and governance bodies. Proprietary data-marketplace offerings from hyperscale cloud providers are referenced as competitive context but are not themselves evaluated for agentic commerce readiness. The analysis assumes that the IDSA Reference Architecture Model version current as of the corpus publication dates represents the active specification baseline; subsequent major version releases may alter capability classifications.

The capability gap analysis yields a consistent picture across all six functional requirements: current European data space infrastructure satisfies none of the six requirements at the Deployable level for agentic commerce, satisfies two at the Roadmap level (meaning a planned specification extension has been identified but not demonstrated in deployment), and classifies the remaining four as Aspirational within the current published specification and governance landscape. The following subsections present the findings requirement by requirement, then address the sector-specific timeline inference.

R1: Real-time data access. The IDSA connector model, as specified and deployed in implementations including the BD4NRG energy-sector architecture [4], operates on a request-response model with policy evaluation at the connector level. This model is adequate for batch and near-real-time enterprise data exchange at human-mediated timescales but has not been specified or demonstrated for the sub-second, high-frequency access patterns required by autonomous decision loops [9]. The connector policy evaluation stack introduces latency that is structurally incompatible with, for example, a pricing agent executing market-clearing calculations across multiple federated data sources simultaneously. No specific IDSA working group document available within the corpus baseline records a published streaming connector specification or deployment roadmap item. In the absence of a citable published roadmap commitment, this requirement is reclassified. Classification: Aspirational.

R2: Machine-to-machine authentication without runtime human issuance. The Gaia-X Trust Framework and IDSA connector authentication model support OAuth 2.0 and certificate-based authentication for registered participants. These mechanisms permit automated runtime credential presentation for pre-registered principals. For agents acting as sub-principals under a parent organizational identity, the specification does not provide a standardized credential delegation mechanism: an agent must either operate under the parent credential (which conflates agent and organization identity and defeats audit traceability) or require human intervention to register a new principal identity. Published IDSA Identity and Trust working group materials, as reflected in the IDS-G specification releases available at the corpus baseline, identify agent credential delegation as a named gap and include it within the scope of identity management extensions under development; no deployment demonstration of this extension has been recorded. Classification: Roadmap.

R3: Dynamic policy delegation. Policy enforcement in the IDSA model is governed by ODRL-based usage control policies attached to data assets at the provider connector. These policies are static at the time of data offering publication: they define what a registered principal may do with a data asset but do not support runtime modification of scope based on agent-presented context. An agentic workflow requiring a data-access scope narrower or broader than the pre-defined policy (because, for example, a delegating principal has granted the agent a time-bounded, purpose-limited sub-permission) cannot be expressed or enforced within the current policy model. Classification: Aspirational (no published specification or roadmap item within IDSA or Gaia-X addresses dynamic runtime policy delegation as of the corpus baseline).

R4: Machine-negotiable contract primitives. Contract execution within data spaces currently requires the establishment of a data usage agreement between two registered principals, with terms drawn from a catalogue of pre-defined policy templates. There is no specification for a protocol by which two agent instances, acting as principals' delegates, negotiate and agree on contract terms at runtime without human contract execution. The distinction between a data-sharing agreement and a commercial contract also creates regulatory uncertainty: data usage agreements under IDSA governance are not equivalent to legally binding contracts under member-state law, and an agent-executed agreement would face additional legal validity questions. Classification: Aspirational.

R5: Autonomous payment constructs. No current IDSA or Gaia-X specification addresses payment settlement, micropayment authorization, or usage-based billing primitives. Data spaces are designed for data exchange, not for the financial transaction layer that monetizes that exchange. An agentic commerce system requires the data-access layer and the payment layer to be integrated: the agent must be able to authorize a micropayment as a condition of data access, or to receive a payment as a condition of data provision, within the same automated workflow. This integration is entirely absent from current specifications [6]. Classification: Aspirational.

R6: Cross-domain trust portability. This requirement is the most extensively analyzed in the corpus. Jeyakumar and Kubach [5] demonstrate that cross-domain trust recognition (specifically, the mutual recognition of verifiable credentials issued by one domain's identity provider within a second, independently governed domain) requires both a standardized SSI reference framework and a cross-domain governance agreement. Neither exists at sufficient standardization maturity as of the corpus baseline. The interoperability risk is further compounded by the finding in [3] that different enterprise implementations of the IDSA reference architecture already interpret high-level guidelines inconsistently, producing connector implementations that are technically non-interoperable despite both claiming conformance. Classification: Aspirational (the SSI framework required is under development at W3C and ETSI but without a published deployment timeline for data space adoption).

Revised summary of classifications. Applying the reclassification of R1, the full distribution across the six requirements is: Deployable, zero requirements; Roadmap, one requirement (R2); Aspirational, five requirements (R1, R3, R4, R5, R6). This distribution is more conservative than the initial framing suggested and is consistent with the absence of published streaming connector roadmap documentation within the available corpus.

Sector-specific timeline inference. The energy sector, represented in this corpus by the BD4NRG architecture [4], exhibits the conditions most conducive to early production readiness: a bounded participant set (grid operators, metering infrastructure, energy service providers), pre-existing sector-specific trust anchors (national regulatory mandates and established metering data access schemes), and a constrained data model (standardized energy data formats). Within this context, R2 is closest to satisfiable within a two-to-three-year horizon, contingent on the deployment of the identity management extensions identified in IDSA IDS-G materials. R1 and the remaining Aspirational requirements remain three-to-five or more years away for any sector, contingent on both specification completion and SSI standardization progress. A production agentic commerce deployment in the energy sector within the three-to-five-year window is structurally plausible only for workflows that do not require real-time streaming data access, dynamic policy delegation, machine-negotiable contracts, or integrated payment constructs: that is, workflows that satisfy a limited subset of the full agentic commerce definition.

The results establish a precise picture of the current state, but their significance lies in what they imply about the mechanisms driving the gap, the structural constraints that make the gap resistant to rapid closure, and the risks that accumulate if the gap is ignored during the vertical deployment window that is already opening. The discussion is organized around the four contributions stated in the introduction.

C3: The scope mismatch is architectural, not incremental. The central finding (that five of the six agentic commerce functional requirements are Aspirational within current data space specifications, with one at Roadmap) is not a statement about implementation lag. It reflects a category-level mismatch between the design assumptions embedded in the IDSA reference architecture and the operational model of agentic commerce. The IDSA connector model was designed for the enterprise data-sharing paradigm: two registered, human-governed organizations agreeing on defined terms for access to a specified data asset. Agentic commerce assumes that the principals in a transaction are themselves software agents operating within pre-authorized but dynamically exercised permission boundaries. The IDSA model has no native concept of a sub-principal, no runtime policy modification protocol, and no payment primitive. Extending the architecture to support these capabilities requires specification work at the foundational level; incremental feature additions cannot substitute for this foundational specification work, and that foundational work has not been initiated within any published roadmap.

This architectural scope mismatch has a further consequence for the timeline. When an infrastructure gap reflects missing features, the closure rate is constrained by implementation capacity. When the gap reflects absent specifications, the closure rate is constrained by the slower process of standards development, working group consensus, and governance ratification. The gaps identified in R1, R3 through R6 are specification gaps, not implementation gaps, and the timeline for closing specification gaps in multi-stakeholder European standardization bodies has historically been measured in years, not months [1].

C2: Identity is the systemic rate-limiter. Of the five Aspirational requirements, cross-domain trust portability (R6) is the dependency on which the others conditionally rest. An autonomous agent that cannot be authenticated with a portable, cross-domain-recognized credential cannot exercise dynamic policy delegation, cannot be a party to a machine-negotiable contract, and cannot be an authorized principal for payment constructs. The SSI architecture analyzed by Jeyakumar and Kubach [5] provides the theoretical framework for resolving R6, but the gap between framework and deployed, governance-ratified infrastructure is substantial. The inconsistent enterprise interpretations of existing IDSA specifications documented in [3] demonstrate that even where specifications exist, deployment divergence is a material risk. SSI cross-domain trust adds a further governance coordination requirement on top of an already strained standardization process.

This dependency structure implies that any timeline forecast for agentic commerce readiness that does not account for SSI governance maturation is structurally optimistic. The energy sector vertical-first scenario described in the results is achievable precisely because it can circumvent the cross-domain trust requirement: a closed, sector-specific data space with a pre-agreed identity scheme does not require cross-domain SSI portability to function. The moment the use case extends across sector boundaries (for example, an energy agent interacting with a logistics agent on a separate data space), R6 becomes blocking.

C4: Security governance lag creates compounding risk in the vertical deployment window. The evidence from Pachaiyappan [8] and Maji [9] establishes that agentic systems operating within federated data architectures introduce threat vectors that current data space security models do not address: prompt injection targeting connector-layer policy evaluation, credential misuse by compromised agent identities, and cascading authorization failures propagating across federated nodes. These are not theoretical risks projected from generic AI security literature; they are operationally specific to the combination of IDSA connector architecture and autonomous agent behaviour.

The structural risk is this: the vertical-first deployment scenario identified in the results will produce working agentic-adjacent deployments in the energy sector within the three-to-five-year window, and those deployments will occur before any authoritative body has published an adopted agentic-aware threat model for data space infrastructure. The IDSA security working group's published materials address data-at-rest and data-in-transit controls within the connector model. No ENISA guidance document reviewed for this paper addresses the autonomous agent case within federated data space infrastructure. This governance lag means that early deployers will be operating under threat models that were designed for a fundamentally different operational context.

The likely failure mode of the first production incident is therefore not a standards conformance failure or an interoperability failure (those failure modes are caught by integration testing and conformity assessment). The likely failure mode is an agent-specific security incident: an agent whose credentials are misused to extract data under an existing valid policy, a prompt injection attack that causes a connector to apply an incorrect policy evaluation, or a cascading authorization failure in which one node's compromised state propagates to connected nodes before human detection occurs. These incidents will be attributed to the deploying organization rather than to the infrastructure, because no authoritative threat model exists to establish that the infrastructure's security design is insufficient for the use case.

C1 in regulatory context: the regulatory framework compounds rather than resolves the risk. The three concurrent regulatory regimes (Data Act data-sharing obligations activating from September 2025, AI Act high-risk system conformity assessment requirements applying from August 2026, and eIDAS 2.0 digital identity wallet provisions) each impose obligations that are individually coherent but collectively inconsistent when applied to an agentic system operating on a European data space. The Data Act's mandatory sharing obligations create pressure to expose data through standardized APIs; the AI Act's conformity assessment requirements impose documentation and audit obligations on the systems consuming that data; eIDAS 2.0's identity wallet infrastructure introduces a third identity layer that is related to but not integrated with IDSA's identity model. An organization seeking to deploy a compliant agentic commerce system must navigate these overlaps without the benefit of authoritative regulatory guidance on how the three frameworks interact, given that no such guidance has been published.

This regulatory complexity raises the legal and compliance cost of deployment to a level that is prohibitive for all but large, well-resourced organizations, precisely those organizations most likely to choose hyperscaler-native alternatives if the sovereign infrastructure is not available within their planning horizon.

The vertical-first trajectory has a systemic implication for horizontal readiness. The conditions that enable energy-sector early deployment (bounded participants, pre-existing trust anchors, constrained data model) are not generalizable. They represent a favorable alignment of pre-existing institutional infrastructure with data space requirements. Other sectors that lack these preconditions will not follow the energy sector's trajectory on the same timeline. The horizontal, cross-sector agentic commerce layer that Gaia-X's policy documents envision requires the resolution of R1, R3 through R6, requirements that the vertical deployments do not address and therefore do not advance. The vertical deployments will generate operational experience and institutional learning, but they will not produce the SSI standardization, the dynamic policy specification, or the payment primitive that horizontal readiness requires. These must be advanced as parallel, independent workstreams.

European data spaces (as specified through IDSA, governed through Gaia-X, and coordinated through the dataspaces.eu ecosystem) constitute a necessary but presently insufficient foundation for agentic commerce. The infrastructure addresses the enterprise data-sharing problem with increasing specification maturity, but the agentic commerce problem is categorically different: it requires sub-second machine-to-machine authentication, dynamic runtime policy delegation, machine-negotiable contract primitives, integrated autonomous payment constructs, and cross-domain trust portability for agent credentials. Applying the three-level classification scheme defined in the methodology, current deployable specifications satisfy none of the six functional requirements at the Deployable level, satisfy one (R2, machine-to-machine authentication) at the Roadmap level, and classify the remaining five (R1, R3, R4, R5, R6) as Aspirational.

The four contributions this paper advances bear distinct operational implications.

On C1 (functional requirement mapping): the six-requirement evaluation rubric provides compliance teams and platform architects with a concrete checklist against which any proposed data space integration for agentic commerce can be assessed. The rubric makes explicit that no current off-the-shelf IDSA or Gaia-X deployment satisfies the full agentic commerce requirement set, and it identifies precisely which requirements are closest to satisfiable (R2) and which remain at the greatest distance from deployable specification (R5, autonomous payment constructs, where no specification work has been initiated).

On C2 (the systemic rate-limiting dependency): cross-domain SSI trust portability (R6) is the structural prerequisite for all cross-sector agentic commerce deployment. Until the W3C and ETSI SSI frameworks are adopted at sufficient maturity within the IDSA governance layer, and until cross-domain governance agreements are ratified between independently operated data spaces, any deployment that involves agents operating across sector or domain boundaries will be blocked at the identity layer. Organizations that invest in agentic commerce architecture should structure their identity layer around emerging SSI standards from the outset, rather than adopting interim proprietary delegation schemes that will require rearchitecting when SSI governance matures.

On C3 (the architectural scope mismatch): the ODRL-based static policy model, the absence of a sub-principal construct, and the lack of any payment primitive in current specifications are not features to be added in a minor release cycle. They require foundational specification work within IDSA and Gaia-X working groups, and that work proceeds on multi-year standards body timelines. Organizations that require these capabilities for their agentic commerce use cases should participate directly in the relevant working groups to accelerate specification development, rather than waiting for completed standards to emerge independently.

On C4 (the deployment hypothesis and security governance lag): early vertical deployments in the energy sector will occur within the three-to-five-year window, and they will carry security exposure that existing IDSA security specifications do not address. The specific vectors are agent credential misuse under valid policies, prompt injection attacks targeting connector-layer policy evaluation logic, and cascading authorization failures that propagate compromise across federated nodes before human operators can intervene. Each of these vectors requires a dedicated control class: respectively, agent-specific credential scoping with short-lived delegation tokens; policy evaluation sandboxing with input validation independent of the agent-provided context; and federated circuit-breaker mechanisms that isolate compromised nodes before failure propagates. None of these controls is specified in current IDSA security materials. Deploying organizations that do not implement these controls independently will carry incident liability in a legal environment that currently lacks the frameworks to attribute responsibility between infrastructure and application layers, leaving the deploying organization as the residual liability bearer.

For regulatory compliance teams, the tri-framework interaction between the Data Act (operative obligations from September 2025), the AI Act (high-risk conformity assessment from August 2026), and eIDAS 2.0 (digital identity wallet rollout concurrent with both) produces overlapping and partially inconsistent obligations for any agentic system consuming federated data. Mapping these intersections before deployment, rather than remediating non-compliance after deployment in a federated multi-party environment, reduces both cost and residual exposure. The absence of authoritative guidance on how the three frameworks interact does not reduce the obligation; it increases the design burden on the deploying organization.