ESS Version 3.0: Making consumer data ready for AI assistants
Amazon launched an AI shopping assistant back in 2024 and estimates its personal shopping recommendations drove an extra $12 billion in purchases last year.
By contrast, according to Adobe, 50% of marketing and CX executives say they’re still in the evaluation stage when it comes to delivering personalized AI experiences to their consumers.
What's holding everyone else up from doing what Amazon has seemingly achieved?
The answer lies with the 76% of the data practitioners who told Adobe that their company’s fragmented data silos make it difficult or impossible to personalize consumer experiences at the speed needed to make AI work efficiently. What’s needed is a way to connect the correct data about a consumer, with their consent, to an AI. And better yet, do it in a way that keeps that data safe from potential misuse by a third party, and the consumer safe from the downstream consequences of that party knowing things about them that they shouldn't.
It’s tricky. It would take a technology that the the consumer helps curate, a protection layer to stop private data being exposed to prying eyes, and an ability to operate all this at machine speeds
That’s what Inrupt’s Enterprise Solid Server does. It focuses on solving this clear disconnect between the increasing expectations of consumers for better experiences and the expressed corporate reality of data silos.
Version 3.0 of the Enterprise Solid Server keeps the core that makes our approach to consumer data unique and powerful — per-user data stores, embrace of interoperable data standards, and granular consent and governance controls — while bringing AI-level capability for consumers and corporations.
ESS 3.0 is purpose-built to give AI agents secure, trusted, consented access to real consumer data at global scale. Four capabilities in this release work together to make consumer data AI-ready — faster to connect, more reliably identified, and easier to deploy.
What’s new in ESS 3.0 (and why)
ESS 3.0 introduces four major capabilities: a Model Context Protocol (MCP) server, native Identity Provider support, stable identifiers, and per-service environment isolation. Together they reduce integration complexity, align ESS with the infrastructure patterns of enterprise AI, and provide the reliable, portable identity layer that AI agents require to operate safely at scale.
1) MCP Server - A Standards-Based Bridge Between AI Agents and Consumer Data
- What it is: A new ESS microservice that enables MCP-compatible AI agents to interact with per-consumer Data Vaults through a standardized protocol — reading, writing, and requesting data access.
- The AI-readiness connection: Most enterprise AI frameworks (including leading LLMs) already support MCP. Without native MCP support in your data layer, connecting AI to real consumer data requires custom integration work. ESS 3.0 removes that barrier entirely.
- How it stays safe: The existing ESS consent model is fully preserved. Third-party AI agents must request an Access Grant from the consumer before accessing their Data Vault data. Users can revoke access at any time. Every interaction is recorded in the audit trail.
- The enterprise deployment model: The MCP Server is designed for enterprise-controlled deployment — the AI agent is embedded in the company's own application stack (not an off-the-shelf MCP client), ensuring the enterprise governs which agents interact with consumer data.
- For developers: Standard MCP client libraries replace custom Solid Protocol integration. Dramatically lowers the cost and complexity of building Data Vault-driven AI experiences.
2) Native Identity Provider Support - Connecting AI agents to the identity systems you already trust
- What it is: A new Token Exchange Service that maps identifiers from external IdPs (Okta, Azure AD, Ping, and others) to ESS internal identifiers, eliminating the requirement to layer WebID infrastructure on top of existing enterprise identity solutions.
- The AI-readiness connection: A consumer-facing AI agent needs a verified, trusted identity path before it can request an Access Grant from a user's Data Vault. With native IdP support, that path is established the moment ESS is deployed — no parallel identity infrastructure, no user re-enrollment.
- Operational highlights: Multiple IdPs supported simultaneously; new IdPs can be added or modified post-deployment without redeployment; full audit trail on all token exchange events; replay attack protection built in; short-lived access tokens (5-minute max TTL) align with regulated-industry security requirements.
- For developers: Integrate ESS against the identity systems you already use. Less overhead, faster time to deployment.
3) Stable Identifiers - An identity layer so AI can build consumer context over time
- What it is: ESS 3.0 introduces stable identifiers — permanent, globally unique identifiers for resources, Data Vaults, agents, and clients — that remain constant even when their underlying URLs change due to infrastructure migrations, domain changes, or system reorganization. Identity (what something is) is now explicitly separated from address (where to find it).
- The AI-readiness connection: An AI agent holding a reference to a consumer's Data Vault or data resource needs that reference to survive infrastructure events. With URL-only addressing, a domain migration or resource reorganization silently breaks every Access Grant, every application reference, every AI context built on that data. Stable identifiers make those references durable.
- Key capabilities: Automatic assignment at creation; Access Grants now contain stable identifiers in addition to current addresses; bidirectional mapping between stable identifiers and resolvable addresses; tombstoning of deleted identifiers to prevent reuse; zero-downtime migration from legacy WebID-based identifiers.
- Additive, not a breaking change: URL-based addressing continues to work. Applications can adopt stable identifiers where stability is required, or continue using URLs for simpler use cases.
4) Environment Isolation - A Leaner Foundation for Pilot-to-Production AI
- What it is: Each ESS service now operates within its own named PostgreSQL schema rather than the shared public schema, removes a long-standing architectural constraint, and makes ESS easier to deploy and operate.
- The AI-readiness connection: Deploying AI experiences at scale means first deploying and iterating on ESS quickly. Requiring a separate database per service added provisioning overhead and made non-production deployments unnecessarily complex. Schema isolation simplifies all of that.
- For developers: Easier to stand up local, staging, and production environments. Fewer databases to provision, configure, and maintain in non-production environments.
ESS 3.0 is ready when you are
Every company is racing to deliver personalized AI experiences to consumers. The ones that win won't necessarily be those with the most ingenious models — they'll be the ones whose approach to data is smart.
Using ESS 3.0 is smart. The MCP server gives AI agents a standards-based path to consumer data without custom integration work. Native Identity Provider support removes the identity barrier so deployment starts from day one. Stable Identifiers make consumer data references durable enough to build long-running AI experiences. And environment isolation means moving from pilot to production faster and more cost-effectively.
Each of these capabilities is useful on its own. Together, they make ESS 3.0 the data infrastructure platform for organizations that are finished with floundering and ready to build.
Get in touch to request a demo or start your 60-day free evaluation of ESS 3.0.

