AI Agents in Data Spaces: When Shared Data Works on Its Own

Until recently, generative AI in a company was largely synonymous with a chat: someone wrote a question and a language model responded based on the context it had been given. This conversational paradigm is still useful, but it is no longer the limit. AI agents take things one step further: they do not wait for a human to formulate every request. Instead, they pursue a goal autonomously, chaining decisions, consulting sources and executing actions without continuous supervision.

The next logical step is for these agents to stop working only with the documents someone has uploaded and start interacting directly with data spaces: federated catalogues where multiple organisations publish datasets under defined access conditions. An agent that needs air quality data, energy consumption data or socioeconomic indicators no longer has to wait for an analyst to prepare them; it can search for them, assess whether it meets the access requirements and request them itself.

For CTOs and innovation leaders, this raises a twofold question: what is technically possible today, and what governance controls are essential before allowing an autonomous agent to interact with third-party data? This article explores both sides, focusing on how a modern data space makes this model possible without giving up control.

What changes with AI agents compared with the traditional chatbot?

A chatbot responds. An AI agent acts. The difference may be subtle on the surface, but it is profound in practice: an agent can break a goal down into subtasks, invoke external tools, evaluate intermediate results and decide on its next step without requiring human intervention at every iteration.

When applied to data, this means an agent can:

• Detect that it needs a dataset it does not have to complete a task.
• Query a federated catalogue to find out who publishes it and under what conditions.
• Assess whether the declared purpose of use complies with the provider's policy.
• Request access, receive the data and process it within the same workflow.

This ability to chain discovery, negotiation and consumption is what turns AI agents into another type of data space consumer, on the same level as a traditional application or a human user, but operating at a much higher speed.

The role of the Model Context Protocol as a gateway

The Model Context Protocol (MCP) has emerged as a de facto standard for connecting language models or agents to external tools and data sources in a structured way. Instead of requiring every integration to be developed from scratch, MCP defines a common interface: the agent asks which "tools" and "resources" are available, and the MCP server responds by describing what can be accessed and how.

In the context of a data space, an MCP server acts as an intermediary between the agent and the data space connector. An MCP server for a data space platform, for example, can expose operations such as searching the federated catalogue, querying a dataset's metadata or initiating an access request, while always respecting the same rules that would apply to any other consumer in the data space.

This is important because it keeps two layers separate that should not be confused: the agent's reasoning layer — what it needs and why — and the data space's compliance layer — whether it is allowed to obtain that data and under what conditions. The agent decides what to request; the data space decides whether to grant it.

An applied example

Imagine an energy consultancy in Valladolid, Termia Analytics, developing an agent to optimise the sizing of photovoltaic installations. The agent receives the goal "estimate the expected production for a plot of land in Castilla y León" and, through MCP, queries the federated catalogue of the data space to locate historical irradiance data published by a public authority. It detects that the dataset requires a purpose of "research or energy planning" and that the agent requesting access must be identified through a connector certificate. It formulates the request, records it in the corresponding smart contract and, once access is approved, incorporates the data into its calculation. All of this happens without a human analyst intervening step by step, although the objective and the agent's boundaries have been defined in advance.

Automated discovery and negotiation of conditions

Automatic dataset discovery is not simply a keyword search. An AI agent working with a federated catalogue needs to interpret metadata: which usage policy applies, what format the data is in, how frequently it is updated and which organisation publishes it. This is where RAG (Retrieval-Augmented Generation) techniques come into play: the agent can index dataset descriptions in a vector database and reason about which one best matches its needs before initiating any access process.

"Negotiation" in this context rarely means real-time bargaining between agents. More commonly, the agent evaluates the conditions already published by the provider — access duration, number of permitted uses, restrictions on redistribution — and decides whether they are acceptable for its task. If they are not, it can look for an alternative source or escalate the decision to a human. This ability to decide "this does not work for me, I'll keep looking" is what distinguishes an agent from a simple API call.

End-to-end process automation

When data discovery, access requests and data consumption are chained together within a single agent, process automation is no longer limited to internal organisational tasks and begins to cross boundaries between companies. A local authority in Castilla y León could deploy an agent that periodically collects water consumption data published by the company managing the water cycle, cross-references it with weather forecasts from a public source and generates a water-stress risk report, without a technician having to go through each dataset every week.

This type of workflow is only sustainable if the data access process is governed by explicit and auditable rules, rather than informal agreements. Otherwise, a misconfigured agent could multiply unnecessary requests or access data beyond the agreed purpose without anyone detecting it in time.

The limits: governance and human oversight are essential

Giving an agent autonomy to consume third-party data does not mean eliminating control. Quite the opposite: the more autonomous the agent is, the more important it becomes for the data space to enforce safeguards that do not depend on the agent's own good behaviour.

In practice, this translates into several mechanisms:

• Verifiable identity: every agent should operate under an identity associated with a connector, never anonymously.
• Independent policy engine: access conditions should be evaluated by a policy engine within the data space, not by the agent itself, so it cannot grant itself permissions.
• Immutable agreement records: every access should be recorded in a smart contract, making it possible to reconstruct who accessed what, when and under which conditions.
• Purpose limitations: the agent must declare its intended purpose of use, which is then checked against the dataset's policy before access is granted.
• Human control points: for certain types of data or request volumes, the workflow should stop and require human validation before continuing.

These controls are not an obstacle to innovation. They are what makes innovation possible without taking on unnecessary legal or reputational risks. A company that deploys autonomous agents without these safeguards may end up violating usage agreements without even realising it, simply because the agent acted faster than anyone could supervise.

How to get started without losing control

The practical recommendation for applied AI teams is to start with limited-scope agents: a single use case, a restricted dataset catalogue and a well-defined set of policies before scaling up. The MCP server should expose only the operations that are strictly necessary, and every new capability added to the agent should be reviewed in terms of what new risk it introduces, not only what new efficiency it provides.

The combination of LLMs, RAG and MCP on top of a governed data space opens a real path for generative AI to move beyond being a passive assistant and become an actor capable of discovering and consuming data on its own. But this autonomy is only sustainable if the data space it operates on was designed from the outset to verify identities, enforce policies and keep a record of every decision.

Take the next step

If your organisation is already exploring AI agents and needs them to access external data with appropriate safeguards, a modern data space provides the connector, policy and MCP server infrastructure needed to do so in a governed way. Find a technology partner with experience in data spaces and assess together where to start.