Position Paper: A Data Sovereignty Layer for AI Agents

Summary

This paper proposes extending the Solid Protocol with conventions for AI agent data storage. The Agent Data Pod specification defines container structures, RDF formats, and access control patterns that complement the AI Agent Protocol Community Group's work on agent identity, discovery, and communication. The goal is agent portability: users should be able to migrate between agent implementations without losing accumulated context.

1. Motivation

The AI Agent Protocol Community Group is developing standards for agent discovery, inter-agent communication, and identity models. These specifications address how agents find each other and exchange messages. This paper addresses a complementary concern: where agent data resides and who controls it.

Current AI agent deployments store user context—preferences, interaction history, learned behaviors—in vendor-specific formats within proprietary infrastructure. This creates several problems:

• Lock-in: Users cannot migrate to alternative agent implementations without losing accumulated context.
• Opacity: Users cannot audit what their agent has learned or request deletion of specific memories.
• Fragmentation: Multiple agents serving the same user cannot share context without custom integrations.
• Trust: Users must trust vendors with sensitive personal data indefinitely.

2. Relationship to CG Work Items

The Agent Data Pod specification aligns with and complements the Community Group's work items:

This specification does not propose alternatives to CG deliverables. Rather, it proposes a data layer that CG protocols can reference for persistent agent state.

3. Technical Overview

3.1 Pod Structure

An Agent Data Pod extends a standard Solid Pod with agent-specific containers for memory, state, audit logs, and public capability declarations.

3.2 Identity Linkage

The Pod profile can link to DID identifiers, enabling agents to be discoverable via both Solid WebID and decentralized identity mechanisms.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix agent: <https://awkronos.github.io/web/vocab#> .
@prefix schema: <https://schema.org/> .

<#me>
    a foaf:Agent, agent:AIAgent ;
    foaf:name "Personal Assistant" ;
    schema:identifier <did:wba:example.com:user:agent-001> ;
    agent:capabilities </public/agent/capabilities.ttl#caps> .

This pattern allows CG identity mechanisms (including the did:wba method under discussion) to reference Pod-stored agent data.

4. Use Cases

4.1 Agent Migration

Scenario: Alice has used AgentA for six months, accumulating preferences and interaction history. She wants to switch to AgentB.

Current state: Alice must start from scratch with AgentB; her context is locked in AgentA's proprietary storage.

With Agent Data Pods: Alice's context resides in her Pod. She revokes AgentA's access and grants access to AgentB, which immediately has her full context.

4.2 Multi-Agent Context Sharing

Scenario: Bob uses a calendar agent and a travel agent. When booking flights, the travel agent should know his calendar constraints.

With Agent Data Pods: Bob's calendar agent writes scheduling preferences to his Pod. The travel agent has read-only access to these preferences. No direct agent-to-agent communication required.

4.3 Audit and Deletion

Scenario: Carol wants to know what her agent has learned about her and delete a specific memory.

With Agent Data Pods: Carol can read her Pod's memory container directly. She can delete specific memory resources. The audit log shows when memories were created and by which agent.

5. Implementation Considerations

5.1 Solid Server Compatibility

The specification has been tested with:

• Community Solid Server (CSS) v7.x
• Inrupt Pod Spaces

5.2 Performance

For agents with large memory stores, implementations SHOULD use SPARQL endpoints or LDP containers with pagination rather than fetching entire memory collections.

5.3 Encryption

Private containers MUST be encrypted at rest. The specification recommends AES-256-GCM with HKDF key derivation.

6. Proposed Next Steps

1. Present this position paper at a CG meeting
2. Gather feedback on vocabulary and scope alignment
3. Revise specification based on CG input
4. Propose formal contribution to CG deliverables if appropriate
5. Coordinate with Solid CG on any protocol extensions required

7. References

[SOLID-PROTOCOL]

Solid Protocol, Version 0.11.0, May 2024. https://solidproject.org/TR/protocol

[DID-CORE]

Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, July 2022. https://www.w3.org/TR/did-core/

[PROV-O]

PROV-O: The PROV Ontology, W3C Recommendation, April 2013. https://www.w3.org/TR/prov-o/

[MCP]

Model Context Protocol. https://modelcontextprotocol.io/

[AGENT-DATA-POD]

Agent Data Pod Specification, Version 0.2.0. spec.html

8. Patent Policy

This document is provided under the W3C Community Contributor License Agreement (CLA).