Version: 0.1.0 (Draft) Status: RFC — Request for Comments Author: AgentLedger Project Date: February 2026
In a multi-agent ecosystem, when an orchestrator sends data to an agent for processing, the sender needs to know: what will happen to my data?
Traditional security frameworks (ISO 27001, GDPR) focus on who can access data. The Agent Data Handling Policy (ADHP) addresses a different question specific to the agentic world: what does the agent do with the data during and after processing?
This specification defines a standardized way for AI agents to declare their data handling practices, enabling orchestrators to make informed routing decisions based on the sensitivity of the data being processed.
When Agent A sends a financial document to Agent B for analysis:
- Will Agent B use that document to train or improve its model?
- Will Agent B store the document after returning the analysis?
- Will Agent B log the contents of the document?
- Will Agent B forward the document to a sub-agent (Agent C)?
- Will Agent B's response contain the original sensitive data?
- Will Agent B share the data with third parties?
- Where physically is Agent B processing the data?
Today, there is no standard way for agents to declare this information, and no standard way for orchestrators to filter agents based on these criteria.
ADHP defines five levels of data handling, from most permissive to most restrictive.
| Level | Label | Training | Persistence | Logging | Delegation | Output | Third-Party Sharing |
|---|---|---|---|---|---|---|---|
| 0 | open | Yes | Unlimited | Full | Unrestricted | May contain source data | Allowed |
| 1 | standard | No | Session-based | Metadata only | Same level required | May contain derived data | With consent |
| 2 | sensitive | No | Request only | Metadata only | Same level+, must be declared | Sanitized — no source data | Anonymized only |
| 3 | strict | No | Request only | No content logging | Same level+ only | Sanitized + reviewed | Not allowed |
| 4 | zero-trace | No | None (streaming only) | None | No delegation | Sanitized, no data leaves agent | Not allowed |
The agent makes no guarantees about data handling. Data may be used for any purpose including model training, indefinite storage, and redistribution. This is the default assumption when an agent does not declare a policy.
Use case: Public data processing, open-source analysis, non-sensitive content generation.
The agent will not use the data for model training. Data is retained for the duration of the session and then deleted. Only metadata (timestamps, request IDs, token counts) is logged — not the content itself. The agent may delegate to sub-agents, but only those that also operate at Standard level or above.
Use case: General business operations, non-regulated internal data, standard API calls.
Same protections as Standard, with additional constraints: data is retained only for the duration of a single request (not the full session). If the agent delegates to sub-agents, this must be explicitly declared in the agent's manifest. The agent's output is sanitized — it will not contain verbatim source data.
Use case: Personal data processing, financial analysis, HR data, customer records.
The agent provides strong confidentiality guarantees. No content logging of any kind. Data is retained only during request processing. Delegation is only permitted to agents at the same level or higher. Output is sanitized and reviewed (automated or manual) to prevent data leakage. No third-party sharing of any kind.
Use case: Legal documents, trade secrets, medical records, classified business strategies.
The highest level of confidentiality. The agent processes data in memory only — no disk writes at any point. No logging whatsoever. No delegation to any other agent. Output is sanitized and constrained so that no source data leaves the agent boundary. This level is designed for data that must leave absolutely no trace.
Use case: National security, pre-announcement M&A data, whistleblower submissions, highly sensitive IP.
Beyond the overall level, each agent declares specific properties in its manifest:
| Property | Type | Description |
|---|---|---|
level |
enum | One of: open, standard, sensitive, strict, zero-trace |
training_opt_out |
boolean | Whether the agent commits to NOT using data for model training |
max_retention |
enum | How long data is kept: none, request, session, 24h, 30d, unlimited |
content_logging |
boolean | Whether the content of requests/responses appears in logs |
delegation_policy |
enum | Sub-agent policy: none, same_or_higher, unrestricted |
output_sanitization |
boolean | Whether outputs are scrubbed of source data |
jurisdiction |
list[string] | Where data is processed (ISO 3166-1 country codes) |
certification |
string (nullable) | Future: ID of a verification/audit certificate |
| Property | Type | Description |
|---|---|---|
third_party_sharing.enabled |
boolean | Whether data is shared with any third party |
third_party_sharing.purpose |
list[enum] | Why data is shared: analytics, advertising, improvement, subprocessing, resale |
third_party_sharing.sanitized |
boolean | Whether shared data is anonymized/stripped of PII |
third_party_sharing.parties_disclosed |
boolean | Whether the list of third parties is publicly available |
third_party_sharing.opt_out_available |
boolean | Whether the data sender can opt out of sharing |
{
"agent_name": "FinanceAnalyzer Pro",
"data_handling": {
"level": "strict",
"training_opt_out": true,
"max_retention": "request",
"content_logging": false,
"delegation_policy": "same_or_higher",
"output_sanitization": true,
"jurisdiction": ["DE", "FR"],
"certification": null,
"third_party_sharing": {
"enabled": false,
"purpose": [],
"sanitized": true,
"parties_disclosed": true,
"opt_out_available": true
}
}
}Critical principle: When Agent A delegates work to Agent B, the data handling level must be maintained or strengthened — never weakened.
| Agent A Level | Agent B Minimum Level |
|---|---|
| open | open (any) |
| standard | standard |
| sensitive | sensitive |
| strict | strict |
| zero-trace | No delegation allowed |
The registry MUST enforce this rule: when an orchestrator queries for agents to handle sensitive data, it must only return agents whose full delegation chain maintains the required level.
This is a key value proposition of the registry — it acts as a trust broker that verifies the entire chain of data handling.
| Level | Sharing Allowed | Conditions |
|---|---|---|
| open | Yes | No restrictions |
| standard | Yes | Only with sender's consent |
| sensitive | Limited | Only anonymized/sanitized data |
| strict | No | Third-party sharing prohibited |
| zero-trace | No | Third-party sharing prohibited, no data leaves agent |
Agents declare their own data handling level. The registry stores this declaration. Orchestrators filter based on declared levels. Trust is based on the agent operator's reputation.
Agent operators can request verification. This involves:
- KYC (Know Your Customer) for the operating organization
- Technical audit of the agent's data handling practices
- Periodic re-verification
- A "Verified" badge displayed in the registry
This is a monetization path — organizations pay for verification, which increases their visibility and trust score in the registry.
Trusted "Auditor" agents periodically test registered agents by:
- Sending test data with tracking markers
- Verifying the data is handled according to the declared policy
- Checking that delegation chains maintain confidentiality levels
- Reporting violations automatically
Technical enforcement through:
- Encrypted data envelopes that enforce retention policies
- Cryptographic proofs of deletion
- Secure enclaves for zero-trace processing
- Blockchain-based audit trails for verification history
POST /agents
{
"name": "FinanceAnalyzer Pro",
"description": "Advanced financial document analysis",
"capabilities": ["financial-analysis", "document-parsing"],
"endpoint": "https://api.finanalyzer.example.com",
"protocol": "REST",
"data_handling": {
"level": "strict",
"training_opt_out": true,
"max_retention": "request",
...
}
}
GET /agents?min_data_handling_level=sensitive&jurisdiction=EU&third_party_sharing=false
Returns only agents that meet or exceed the requested confidentiality requirements.
- If an agent does not declare a
data_handlingpolicy, the registry defaults tolevel: "open"— assume the worst case if not declared. - This incentivizes agents to explicitly declare their policy, as undeclared agents will be filtered out of any confidentiality-sensitive queries.
| Standard | Focus | ADHP Complement |
|---|---|---|
| ISO 27001 | Who can access data within an organization | What happens to data after an agent processes it |
| GDPR | Legal framework for personal data in the EU | Technical declaration of compliance-relevant practices |
| SOC 2 | Organizational security controls | Agent-level data handling transparency |
| OAuth/OIDC | Who is authorized to call the agent | Authorization is separate — handled by external auth systems |
| MCP | Protocol for agent-tool communication | ADHP adds data handling metadata to the agent discovery layer |
ADHP is designed to complement, not replace, these standards. An agent operating at "strict" level within the EU would still need to comply with GDPR independently — ADHP simply makes the agent's practices transparent and machine-queryable.
This specification is in draft. We welcome feedback on:
- Are the five levels sufficient? Too many? Too few?
- Are there data handling concerns we've missed?
- How should verification work in practice?
- How does this interact with emerging AI regulation?
Please open a Discussion or submit an RFC in the docs/ folder.