The 'prompt' URI Scheme for AI Agent Sessions and Prompts
draft-boone-prompt-uri-scheme-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Keith W Boone | ||
| Last updated | 2026-07-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Organization
GitHub Repository GitHub Username: keithboone |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-boone-prompt-uri-scheme-01
agentproto K. Boone
Internet-Draft Audacious Inquiry
Intended status: Informational 21 July 2026
Expires: 22 January 2027
The 'prompt' URI Scheme for AI Agent Sessions and Prompts
draft-boone-prompt-uri-scheme-01
Abstract
This document defines the prompt Uniform Resource Identifier (URI)
scheme for identifying prompts within AI agent sessions. A prompt
URI encodes the agent identity, session identifier, and a timestamp
sufficient to locate the originating prompt within an agent session
log. The scheme is intended for use in provenance records, audit
trails, and cross-agent references where a human-readable, stable
locator for a prompt interaction is required.
This document also addresses the conditions under which multiple URIs
MAY resolve to the same prompt and the conditions under which a
single URI MAY be ambiguous with respect to the prompt it identifies.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Boone Expires 22 January 2027 [Page 1]
Internet-Draft prompt URI Scheme July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scheme Name . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Complete ABNF . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Authority Component (Optional) . . . . . . . . . . . . . 7
3.4. Path Component . . . . . . . . . . . . . . . . . . . . . 8
3.5. Query and Fragment Components . . . . . . . . . . . . . . 9
4. URI Components and Semantics . . . . . . . . . . . . . . . . 9
4.1. Remote vs. Local Resolution . . . . . . . . . . . . . . . 9
4.2. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Username . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Agent Name . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Session Identifier . . . . . . . . . . . . . . . . . . . 11
4.6. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Session Aliases . . . . . . . . . . . . . . . . . . . . . 11
4.8. Canonical Prompt URI . . . . . . . . . . . . . . . . . . 13
5. Normalization and Comparison . . . . . . . . . . . . . . . . 14
6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Resolution Algorithm . . . . . . . . . . . . . . . . . . 15
6.2. Alias Resolution . . . . . . . . . . . . . . . . . . . . 16
6.3. Unresolvable URIs . . . . . . . . . . . . . . . . . . . . 17
7. Ambiguity: Multiple URIs for One Prompt . . . . . . . . . . . 18
8. Ambiguity: One URI for Multiple Prompts . . . . . . . . . . . 18
8.1. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Disclosure Requirement . . . . . . . . . . . . . . . . . 19
9. MCP Resolution API . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A: Automatic Prompt-URL Trailer via Git Hook . . . . . . 23
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Installation . . . . . . . . . . . . . . . . . . . . . . . . . 24
Resulting Commit Message . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
Boone Expires 22 January 2027 [Page 2]
Internet-Draft prompt URI Scheme July 2026
1. Introduction
AI agent systems produce interactions -- prompts from users, tool
calls by agents, responses, and observations -- that generate
artifacts (files, analyses, transformed documents) whose provenance
is difficult to trace after the fact. Existing identifier schemes
are insufficient for this use case:
* A session identifier alone does not distinguish which prompt
within a session produced a given artifact.
* A wall-clock timestamp alone does not identify the agent or
session.
* An agent-internal correlation identifier (such as a promptId or
interactionId) is not exposed to callers of agent tools at call
time.
The prompt URI scheme addresses this gap by providing a stable,
human-readable identifier that encodes the three pieces of
information consistently available to any tool executing within an
agent session: the agent identity, the session identifier, and the
approximate call time.
The resulting URI is suitable for embedding in file provenance
metadata, log cross-references, and audit records. It is NOT a
globally unique identifier in the strict sense; see Section 7 and
Section 8 for a full treatment of ambiguity.
The scheme has been implemented and deployed as an open-source Model
Context Protocol (MCP) server [PROMPT-URL-MCP] that resolves,
generates, and searches prompt URIs against local agent session logs.
This implementation validates the design under real-world agent
workloads involving both Claude Code and GitHub Copilot sessions.
Several proposals currently under active consideration in IETF AI-
focused forums address broader questions of AI agent accountability,
transparency, auditability, and interoperability. The prompt URI
scheme is intended as a composable, low-level building block for
those frameworks: any mechanism that tracks, attests to, or makes
claims about AI-generated artifacts needs a stable, lightweight way
to reference the specific agent interaction that produced them. This
document defines that reference.
Boone Expires 22 January 2027 [Page 3]
Internet-Draft prompt URI Scheme July 2026
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used throughout this document:
Agent:
A software system that processes user prompts, invokes tools, and
produces responses. Examples include Claude Code, GitHub Copilot,
and similar AI-assisted development tools.
Session:
A bounded interaction context shared between a user and an agent,
identified by a session identifier assigned at session initiation.
Prompt:
A single user message that initiates one or more agent actions
within a session.
Session log:
A persistent record maintained by the agent of all interactions
within a session, including prompts, tool calls, and responses,
together with timestamps and internal correlation identifiers.
Tool call:
An invocation of an external capability (such as a file write
operation) by the agent in response to a prompt. The Model
Context Protocol [MCP] is one standardized mechanism by which
agents invoke such capabilities.
Provenance record:
Metadata attached to an artifact describing its origin, including
the agent, session, and prompt responsible for its creation.
Prompt URI:
A URI conforming to this specification that identifies a prompt
within a specific agent session.
Session alias:
A human-readable string registered by the user or agent as an
alternative identifier for a session, usable in place of the
session identifier in a prompt URI. An alias is scoped to a
single agent and MUST be unique within that agent's alias
registry.
Boone Expires 22 January 2027 [Page 4]
Internet-Draft prompt URI Scheme July 2026
Alias registry:
A local store, maintained by an implementation, that maps
registered session aliases to their corresponding session
identifiers.
3. URI Syntax
3.1. Scheme Name
The scheme name is prompt. It SHALL be written in lowercase in all
generated URIs. Implementations processing incoming URIs SHOULD
treat the scheme name as case-insensitive per [RFC3986]
Section 6.2.2.1.
3.2. Complete ABNF
The following grammar, expressed in Augmented Backus-Naur Form
[RFC5234], defines the syntax of a prompt URI. Terms not defined
here are imported from [RFC3986] (unreserved, pct-encoded, host, sub-
delims) and [RFC3339] (date-time).
prompt-URI = "prompt:" hier-part
agent-name "/" session-ref "/" prompt-ref
hier-part = "//" authority "/" ; remote: authority-based
/ "/" ; local-only resolution
authority = [ userinfo "@" ] host [ ":" port ]
; host: hostname or IP-literal (RFC 3986 s3.2.3)
; userinfo: optional username
; port: optional; default port is 7560
userinfo = 1*( unreserved / pct-encoded / sub-delims )
; Username identifying the user at the remote host;
; the "user:password" form of RFC 3986 s3.2.1 is
; NOT RECOMMENDED -- use username only
host = <host as defined in RFC 3986 Section 3.2.3>
; DNS hostname, IPv4 address, or IP-literal
port = *DIGIT
; decimal; absent port defaults to 7560
agent-name = 1*agent-char
agent-char = unreserved / pct-encoded / "+" / "."
session-ref = session-id / session-alias
; parsers cannot distinguish the two forms;
Boone Expires 22 January 2027 [Page 5]
Internet-Draft prompt URI Scheme July 2026
; the distinction is semantic (Sections 4.4, 4.6)
session-id = 1*( unreserved / pct-encoded )
; Typically a UUID per RFC 9562
session-alias = 1*( unreserved / pct-encoded )
; Special characters including SP (U+0020) MUST be
; percent-encoded per [RFC3986] -- see Section 4.6
prompt-ref = date-time / prompt-id
; RFC 3339 timestamp or a prompt identifier;
; date-time always begins with a 4-digit year, so
; the "~" prefix of prompt-id is unambiguous
; See Sections 4.5 and 4.7
date-time = <date-time as defined in RFC 3339, Section 5.6>
; Colons within date-time are valid in URI path
; segments per RFC 3986 Section 3.3
; Example: 2026-07-07T16:45:23.856Z
prompt-id = "~" 1*( unreserved / pct-encoded )
; Agent-internal prompt correlation identifier;
; "~" (U+007E, unreserved, RFC 3986) distinguishes
; prompt-id from date-time in all syntactic contexts
; Example: ~abc123, ~promptId%3Axyz
The following prompt URIs illustrate the syntactic forms. The first
two use local-only resolution (single slash, no authority); the
remaining three use remote resolution via a named host:
; NOTE: Lines ending with '\' are folded per [RFC8792].
; No whitespace is implied at the fold point.
; Local-only forms (prompt:/ -- single slash, no authority)
prompt:/claude-code/\
5674b542-0b94-4d12-bc05-d271a4131354/2026-07-07T16:45:23.856Z
prompt:/claude-code/5674b542-0b94-4d12-bc05-d271a4131354/~abc123
; Remote forms (prompt:// -- authority present)
prompt://mcp.example.com/claude-code/\
5674b542-0b94-4d12-bc05-d271a4131354/~abc123
prompt://kboone@mcp.example.com/claude-code/\
5674b542-0b94-4d12-bc05-d271a4131354/~abc123
prompt://mcp.example.com/claude-code/\
md-csv-mcp%20design/2026-07-07T16:45:23.856Z
Breaking the local prompt-id form into components:
Boone Expires 22 January 2027 [Page 6]
Internet-Draft prompt URI Scheme July 2026
prompt-URI = "prompt:"
"/" ; hier-part: local-only (single slash)
"claude-code" ; agent-name
"/"
"5674b542-0b94-4d12-bc05-d271a4131354" ; session-id
"/"
"~abc123" ; prompt-ref: prompt-id form
Breaking the remote form with username into components:
prompt-URI = "prompt:"
"//" ; hier-part: remote resolution
"kboone" ; userinfo (username)
"@"
"mcp.example.com" ; host (agent client machine)
"/"
"claude-code" ; agent-name
"/"
"5674b542-0b94-4d12-bc05-d271a4131354" ; session-id
"/"
"~abc123" ; prompt-ref: prompt-id form
Breaking the remote alias form into components:
prompt-URI = "prompt:"
"//" ; hier-part: remote resolution
"mcp.example.com" ; host (no username)
"/"
"claude-code" ; agent-name
"/"
"md-csv-mcp%20design" ; session-alias (%20 = space)
"/"
"2026-07-07T16:45:23.856Z" ; prompt-ref: timestamp
3.3. Authority Component (Optional)
The authority component is OPTIONAL. Its presence is signaled by the
double-slash // prefix following the scheme (prompt://), in
accordance with [RFC3986] Section 3. When the authority is absent,
the URI uses a single slash (prompt:/) and is resolvable only through
a local MCP server instance.
When present, the authority takes the form:
[ username "@" ] host [ ":" port ]
Boone Expires 22 January 2027 [Page 7]
Internet-Draft prompt URI Scheme July 2026
The host subcomponent identifies the network host where the agent
client application resides and operates on behalf of the user. The
agent may reside in the cloud (such as Claude Code or GitHub
Copilot), but this is the user machine where the agent's client
application stores logs and session data that enable prompt
resolution. The host MAY also provide an HTTP endpoint where an MCP
server is accessible, enabling remote resolution of the URI over the
network. It follows the host syntax of [RFC3986] Section 3.2.3 (DNS
name, IPv4 address, or IP-literal).
The port subcomponent is OPTIONAL. When present, it is separated
from the host by a colon (:), as defined in [RFC3986] Section 3.2.3.
When absent, the port defaults to 7560, which is the registered
default port for the prompt-scheme MCP server reference
implementation.
The username subcomponent is OPTIONAL. When present, it is separated
from the host by an @ (U+0040) character, following the same
convention as HTTP and other URI schemes ([RFC3986] Section 3.2.1).
It identifies the user account or identity principal under which the
agent session log is stored at the remote host, and MAY be used by
the remote MCP server to scope its session log search.
The agent-name is NOT part of the authority; it is always the first
segment of the path (Section 3.4).
3.4. Path Component
The path component SHALL consist of exactly three segments separated
by slashes:
1. The agent name (Section 4.4) -- identifies the software agent
that generated the URI.
2. A session reference -- either a session identifier (Section 4.5)
or a registered session alias (Section 4.7).
3. A prompt reference -- either an RFC 3339 timestamp (Section 4.6)
or a prompt identifier (Section 4.8).
The path MUST begin with a slash. All three segments MUST NOT be
empty.
Boone Expires 22 January 2027 [Page 8]
Internet-Draft prompt URI Scheme July 2026
3.5. Query and Fragment Components
This specification does not define semantics for query (?) or
fragment (#) components. Implementations MAY append a fragment to a
prompt URI as an implementation-specific disambiguation hint (see
Section 8), but SHALL NOT rely on fragment processing in
interoperable contexts. The query component SHOULD NOT be used; its
presence does not affect identity or comparison.
4. URI Components and Semantics
4.1. Remote vs. Local Resolution
A prompt URI selects its resolution mode by the presence or absence
of the authority (//host) prefix:
* *Remote (prompt://[user@]host/...)* -- The double-slash signals
that an authority is present. The URI is intended to be resolved
by contacting the prompt-scheme MCP server running at host over
the network. This form is appropriate for sharing prompt
references across machines, teams, or systems where the
originating session log is accessible through a web-facing MCP
endpoint.
* *Local-only (prompt:/...)* -- The single slash signals that no
authority is present. The URI is resolvable only by a local MCP
server instance that has access to the originating agent's session
logs on the same machine. This form is appropriate for provenance
records that will only ever be resolved on the machine that
generated them.
Implementations that generate prompt URIs SHOULD choose the local
form by default and SHOULD allow the user or configuration to specify
a remote host when a web-accessible MCP server is available.
Implementations SHOULD NOT silently upgrade a local URI to a remote
one; the resolution mode is part of the URI's identity.
4.2. Host
The host subcomponent identifies the network host where the agent
client application resides and operates on behalf of the user. The
agent may reside in the cloud (such as Claude Code or GitHub
Copilot), but this is the user machine where the agent's client
application stores logs and session data that enable prompt
resolution. It follows the host production of [RFC3986]
Section 3.2.3. The host MAY also provide an HTTP endpoint where a
prompt-scheme MCP server is accessible, enabling remote resolution of
the URI over the network. A single MCP server MAY host resolution
Boone Expires 22 January 2027 [Page 9]
Internet-Draft prompt URI Scheme July 2026
for multiple AI agents.
Host names SHOULD be stable DNS names. IP addresses SHOULD be
avoided in long-lived provenance records because they are subject to
renumbering.
The optional port number, when present, identifies the TCP port on
which the prompt-scheme MCP server listens at that host. When
absent, the port defaults to 7560, the default port of the reference
implementation. When an explicit port number equal to 7560 is
present, it is equivalent to the form with no port for comparison
purposes (Section 5).
4.3. Username
The username is the OPTIONAL userinfo subcomponent of the authority.
When present, it identifies the user account or identity principal
whose agent session logs are stored at the remote host. The remote
MCP server MAY use it to scope its session log search to that user's
log partition.
The username is meaningful only when the authority is present (remote
form). It SHOULD be omitted in local-only URIs, and SHOULD be
omitted in remote URIs when the MCP server does not partition logs by
user.
Two prompt URIs that differ only in the presence or absence of a
username, or in the value of the username, are NOT equivalent
(Section 5) unless the resolver determines that both usernames map to
the same identity principal.
4.4. Agent Name
The agent name is the first segment of the path. It identifies the
software agent that generated the URI. It is NOT a globally
registered identifier; implementations SHOULD use a stable,
recognizable short name (e.g., claude-code, github-copilot, cursor).
Agents operated by different organizations SHOULD use distinct names
to avoid collision.
The agent name MAY include a dot-separated hierarchy for namespacing
(e.g., anthropic.claude-code), but this structure carries no defined
semantics in this specification.
The agent name SHALL remain constant across all sessions and versions
of a given agent implementation. Including a version number in the
agent name is NOT RECOMMENDED, as it would render URIs from different
versions incomparable even when they refer to the same logical agent.
Boone Expires 22 January 2027 [Page 10]
Internet-Draft prompt URI Scheme July 2026
4.5. Session Identifier
The session identifier SHALL be an opaque string assigned by the
agent at session initiation. Implementations SHOULD use a UUID
[RFC9562] for the session identifier to minimize collision
probability across agents and deployments. UUID version 7 [RFC9562]
is RECOMMENDED over version 4 because its monotonically increasing
structure supports chronological ordering of sessions.
The session identifier SHALL be consistent throughout a session and
SHALL NOT change during a session's lifetime.
4.6. Timestamp
The timestamp SHALL be formatted as an RFC 3339 [RFC3339] date-time
value and SHALL use UTC (the Z suffix). The timestamp records the
wall-clock time at which the tool call generating the URI was
executed.
Implementations SHOULD include sub-second precision (milliseconds) in
the timestamp to reduce the probability of within-session collisions
(see Section 8). A timestamp with second-level precision is
REQUIRED; millisecond precision is RECOMMENDED; microsecond precision
MAY be used.
The timestamp is NOT the time at which the originating prompt was
submitted. It is the time at which the tool call was executed. For
a given prompt, multiple tool calls MAY be executed, potentially
spanning multiple seconds. Each tool call produces a URI with its
own timestamp; all such URIs are considered to refer to the same
prompt for resolution purposes (see Section 6).
When the agent maintains an internal prompt correlation identifier,
the canonical form of the URI SHOULD use that identifier in place of
the timestamp (see Section 4.8).
4.7. Session Aliases
A session alias is a human-readable string that a user or
implementation MAY register as an alternative to the session
identifier in a prompt URI. Aliases improve legibility:
prompt:/claude-code/md-csv-mcp-design/... is more immediately
meaningful than prompt:/claude-code/5674b542-.../....
Boone Expires 22 January 2027 [Page 11]
Internet-Draft prompt URI Scheme July 2026
*Registration:* Aliases SHALL be registered in a local alias registry
that maps each alias to the session identifier it represents. An
alias is scoped to a single agent name and MUST map to exactly one
session within that agent's registry. A session MAY have more than
one alias registered to it.
Attempting to register an alias that is already registered to a
different session SHALL be rejected with a conflict error.
Attempting to register an alias that is already registered to the
same session is idempotent and SHALL succeed without modifying the
registry.
*Case insensitivity:* Alias lookup SHALL be case-insensitive. The
alias MD-CSV-MCP-Design, md-csv-mcp-design, and Md-Csv-Mcp-Design
MUST all resolve to the same session. Implementations SHOULD store
aliases in normalized lowercase and normalize incoming aliases to
lowercase before lookup.
*Canonical URI form:* In a prompt URI, an alias SHALL appear in its
canonical URI form, which is the percent-encoded representation of
the alias string with all characters encoded per [RFC3986] as
required.
*Handling of spaces and special characters:* Spaces (U+0020) and any
other characters not permitted in a URI path segment by [RFC3986]
MUST be percent-encoded in the canonical URI form of an alias. The
alias md-csv-mcp design is canonically encoded as md-csv-mcp%20design
in a prompt URI. Hyphens and spaces remain distinct: the alias md-
csv-mcp design and the alias md-csv-mcp-design are different aliases
and resolve to different sessions (if both are registered).
Implementations that accept prompt URIs as input MAY repair aliases
containing unencoded special characters by applying percent-encoding
before lookup, in the same manner that web browsers correct malformed
URIs.
Implementations MUST preserve the original human-readable alias
string (as supplied at registration time, before percent-encoding) in
the alias registry. This allows the original label to be displayed
in user interfaces without loss of information.
*Alias persistence:* Alias registries are implementation-defined and
may not persist indefinitely. Agents are not required to maintain
alias registries across restarts, updates, or deployments. Users and
systems requiring long-term, portable provenance references SHOULD
use the session-identifier form of the prompt URI rather than the
alias form, since session identifiers are generated by the agent and
stored in its session log independently of any alias registry.
Boone Expires 22 January 2027 [Page 12]
Internet-Draft prompt URI Scheme July 2026
Prompt URIs using an alias remain valid provenance references as long
as the alias registry is intact, but are subject to becoming
unresolvable (Section 6.3) if the registry is lost or unavailable.
*Alias-to-session-id URIs:* When a session has both a registered
alias and a session identifier, both forms of prompt URI are valid
and refer to the same session. Implementations MAY use the alias
form in newly generated provenance records when an alias is
registered, as it improves human readability.
4.8. Canonical Prompt URI
A prompt URI is _canonical_ if its prompt-ref component is the most
specific and stable identifier available for the prompt it
represents. The canonical form determines which URI SHOULD be stored
in provenance records.
*Prompt identifier form (preferred):* When the agent maintains an
internal correlation identifier for each prompt (for example,
promptId in Claude Code session logs [CLAUDE-SESSIONS] or
interactionId in Copilot session logs [COPILOT-SESSIONS]), the
canonical URI SHOULD use the prompt-id form (Section 3.2) with a
leading ~ character:
prompt:/claude-code/5674b542-0b94-4d12-bc05-d271a4131354/~abc123
A canonical prompt-id URI uniquely identifies the prompt regardless
of when tool calls execute within the prompt's processing. Because
all tool calls from the same prompt share the same prompt identifier,
two prompt-id URIs with the same session-ref and prompt-id components
can be detected as equivalent by string comparison, without
consulting the session log.
*Timestamp form (fallback):* When no prompt identifier is available,
the canonical URI SHOULD use the timestamp at which the originating
prompt was submitted by the user -- not the timestamp of any
particular tool call within the prompt's processing. An
implementation that records prompt-submission timestamps MAY use that
timestamp in the canonical URI even if individual tool calls use
their own tool-call timestamps (Section 4.6).
Tool-call timestamp URIs (those generated at the time a tool call
executes) are valid provenance references but are not canonical:
multiple such URIs from the same prompt are not equivalent by
comparison (Section 5), even though they resolve to the same prompt
(Section 6).
Boone Expires 22 January 2027 [Page 13]
Internet-Draft prompt URI Scheme July 2026
*Normalizing to canonical form:* Implementations SHOULD normalize all
prompt URI references for a given prompt to the canonical URI before
writing provenance records. Normalizing to the prompt-id form, when
available, enables deduplication of provenance entries across the
tool calls of a single prompt without requiring session log access.
5. Normalization and Comparison
Two prompt URIs SHOULD be considered equivalent if and only if all of
the following hold after applying the normalization rules in
[RFC3986] Section 6:
1. Their scheme components are identical (case-insensitively).
2. Their resolution mode is identical: either both have an authority
(remote) or both lack one (local-only).
3. When both have an authority: their host subcomponents are
identical (case-insensitively per [RFC3986] Section 6.2.2.1);
their port subcomponents are equivalent (treating an absent port
as equal to port 7560); and their username (userinfo)
subcomponents are equivalent -- both absent, both present and
identical after percent-decoding (case-sensitive), or both
present and determined by the resolver to map to the same
identity principal.
4. Their agent-name components are identical (case-insensitively).
5. Their session-ref components identify the same session,
determined as follows:
* If both are session identifiers: they are identical after
percent-decoding (case-sensitive).
* If both are session aliases: they are identical after percent-
decoding and case-folding to lowercase.
* If one is a session identifier and the other a session alias:
they are equivalent if and only if the alias resolves to the
same session identifier per the alias registry (Section 6.2).
6. Their prompt-ref components identify the same prompt reference,
as determined by the following rules:
* If both are timestamps (date-time): they represent the same
instant in time, after normalizing to UTC and applying the
date-time comparison rules of [RFC3339].
Boone Expires 22 January 2027 [Page 14]
Internet-Draft prompt URI Scheme July 2026
* If both are prompt identifiers (prompt-id): they are identical
after percent-decoding (case-sensitive, following percent-
decoding).
* If one is a timestamp and the other is a prompt identifier:
they are NOT equivalent; resolution (Section 6) is required to
determine whether they refer to the same prompt.
Timestamps that differ by any amount of time, however small, are NOT
equivalent and SHALL NOT be treated as identifying the same prompt
URI. Equivalence and resolution are distinct concepts: two non-
equivalent URIs MAY nonetheless resolve to the same prompt
(Section 7), and a single URI MAY be ambiguous (Section 8). Two URIs
that differ only in their prompt-ref form (one using a timestamp, one
using a prompt identifier) are likewise non-equivalent by this
definition, even if they identify the same underlying prompt.
6. Resolution
6.1. Resolution Algorithm
Resolution is the process of mapping a prompt URI to one or more
candidate prompts in an agent's session log. Resolution is OPTIONAL;
a prompt URI is valid and useful as a provenance reference even when
the referenced session log is unavailable.
A conformant resolver SHALL apply the following steps:
1. Parse the prompt URI and determine the resolution mode
(Section 4.1):
* *Remote* (prompt://...): extract host, username (if present),
agent-name, session-ref, and prompt-ref. Contact the MCP
server at host to perform steps 2-7 on the remote server. If
username is present, pass it to the remote server so that it
MAY scope its session log search.
* *Local-only* (prompt:/...): extract agent-name, session-ref,
and prompt-ref. Perform steps 2-7 using the local session log
store.
If session-ref is an alias, resolve it per Section 6.2 to obtain
the session identifier before proceeding.
Boone Expires 22 January 2027 [Page 15]
Internet-Draft prompt URI Scheme July 2026
2. Locate the session log associated with the session identifier for
the agent identified by agent-name. If resolving remotely and a
username is present, the resolver MAY restrict its search to
session logs owned by or accessible under that identity
principal. If no matching log is accessible, the URI is
unresolvable (Section 6.3).
3. If prompt-ref is a prompt-id (begins with ~): strip the ~ prefix,
percent-decode the remainder, and locate all session log entries
whose prompt correlation identifier matches. If exactly one
entry is found, the URI resolves to that prompt. Proceed to step
5.
If prompt-ref is a date-time: identify the most recent human-
authored prompt entry in the session log whose recorded timestamp
is on or before the URI timestamp. Because a single prompt may
drive multiple agent actions -- file writes, commits, and pushes
-- before the URI timestamp is captured, the elapsed time between
the prompt and the URI timestamp may be substantial.
4. From the candidate entries, identify those that are prompt-type
entries (user messages that initiated a turn), as opposed to tool
call or response entries.
5. If exactly one prompt-type candidate is found, the URI resolves
to that prompt.
6. If multiple prompt-type candidates are found, the URI is
ambiguous (Section 8). The resolver SHOULD report all candidates
and SHOULD NOT silently select one.
7. If the session log records an agent-internal correlation
identifier (e.g., promptId in Claude Code session logs
[CLAUDE-SESSIONS], interactionId in Copilot session logs
[COPILOT-SESSIONS]), implementations MAY use that identifier to
narrow candidate selection to a single result.
6.2. Alias Resolution
When the session-ref component of a prompt URI does not parse as a
UUID and is not otherwise recognizable as a session identifier, the
resolver SHALL treat it as a session alias and apply the following
steps before proceeding with Section 6.1:
1. Normalize the alias: percent-decode, then fold to lowercase.
2. Look up the normalized alias in the alias registry for the agent
identified by agent-name.
Boone Expires 22 January 2027 [Page 16]
Internet-Draft prompt URI Scheme July 2026
3. If a matching entry is found, substitute the corresponding
session identifier into the resolution process and continue with
Section 6.1 step 2.
4. If no matching entry is found, the URI is unresolvable
(Section 6.3). Implementations SHOULD report "alias not
registered" as a distinct unresolvable condition, separate from
"session log not found."
6.3. Unresolvable URIs
A prompt URI is unresolvable if any of the following conditions hold:
* The URI is in remote form (prompt://) and the host subcomponent
does not match the hostname of the machine on which the resolver
is running (case-insensitive comparison). A resolver MUST NOT
attempt to forward the request to another machine; it SHALL return
an error indicating the host mismatch.
* The URI is in remote form and contains a username subcomponent
that does not match the OS-level username of the user under whose
account the resolver is operating (case-insensitive comparison).
The resolver SHALL return an error indicating the user mismatch.
* The session-ref is a session alias that is not registered in the
alias registry.
* The session log for the resolved session identifier is not
accessible to the resolver.
* The session log has been deleted, expired, or is otherwise
unavailable.
* The agent-name is not recognized by the resolver.
* No session log entries fall within the resolution window.
An unresolvable URI is NOT invalid. The URI remains a valid
provenance identifier and SHALL be preserved in provenance records
even when the referenced session is no longer accessible. Resolvers
SHOULD distinguish between "unresolvable" and "invalid" when
reporting resolution status, and SHOULD report host-mismatch and
user-mismatch conditions as distinct errors to aid debugging.
When resolution succeeds, the resolver SHALL return the canonical URI
in the same form as the URI that was presented for resolution: if the
input was a local-only URI (prompt:/...), the returned canonical_uri
SHALL be in local form; if the input was a remote URI (prompt://...),
Boone Expires 22 January 2027 [Page 17]
Internet-Draft prompt URI Scheme July 2026
the returned canonical_uri SHALL be in remote form, preserving the
host, username (if present), and port (if non-default) from the input
URI.
7. Ambiguity: Multiple URIs for One Prompt
A single prompt MAY be the source of multiple tool calls, each of
which produces a prompt URI with a distinct timestamp. This is the
common case in agent workflows, where a single user message triggers
a sequence of file reads, web fetches, and file writes, each
implemented as a separate tool call.
All prompt URIs generated within the same session from the same
originating prompt refer to that same prompt, even though their
prompt-ref components differ. Implementations SHOULD treat these
URIs as semantically equivalent for provenance purposes, even though
they are not syntactically equivalent (Section 5) and will not
compare as equal.
When the agent provides a prompt correlation identifier,
implementations SHOULD normalize all such URIs to the canonical
prompt-id form (Section 4.8) before writing provenance records. This
eliminates the proliferation of distinct URIs for the same prompt and
enables deduplication by string comparison, without session log
access.
Additionally, the same prompt may be identifiable by URIs with
different timestamp precision:
prompt:/claude-code/5674b542.../2026-07-07T16:45:23Z
prompt:/claude-code/5674b542.../2026-07-07T16:45:23.856Z
Both of the above URIs identify the same instant in time at different
precision levels. Per Section 5, these URIs are NOT equivalent. Per
Section 6, they SHOULD resolve to the same candidate when the
resolution window is applied. Implementations that store provenance
records SHOULD use a consistent timestamp precision to minimize the
proliferation of distinct URIs for the same prompt.
8. Ambiguity: One URI for Multiple Prompts
A single prompt URI MAY be ambiguous when multiple distinct prompts
occur within the resolution window of its timestamp. This arises in
the following conditions:
*Within-session collision:* Two or more distinct user prompts within
the same session are submitted and processed within the same second
(or within the resolution window of a sub-second timestamp). This is
Boone Expires 22 January 2027 [Page 18]
Internet-Draft prompt URI Scheme July 2026
uncommon in interactive agent sessions, where user prompts are
typically separated by seconds to minutes, but MAY occur in automated
pipelines where prompts are submitted programmatically without human
pacing.
*Cross-session collision:* Two sessions with different session
identifiers are not a source of ambiguity for a given URI, since the
session identifier is a URI component. However, if a resolver has
access to session logs from multiple agents with the same agent-name,
and two such logs share a session-id value (which SHOULD NOT occur
when UUIDs are used), a cross-log collision is possible.
8.1. Mitigation
Implementations SHOULD use millisecond-precision timestamps (rather
than second-precision) to reduce the probability of within-session
collisions. With millisecond precision, a collision requires two
distinct prompts to arrive within the same millisecond, which is
negligible in interactive use.
Implementations MAY append a fragment identifier to a prompt URI to
encode an agent-internal correlation identifier when that identifier
is known at call time:
prompt:/claude-code/5674b542.../2026-07-07T16:45:23.856Z#id=abc123
Fragment identifiers used for this purpose are implementation-
specific and are OPTIONAL and not required for interoperability.
Resolvers that do not recognize a fragment identifier SHOULD ignore
it and apply the standard resolution algorithm.
8.2. Disclosure Requirement
Implementations that generate prompt URIs SHOULD document the
timestamp precision they use and the conditions under which within-
session collisions are possible, so that consumers of provenance
records can assess the reliability of URI-based prompt identification
in their deployment context.
9. MCP Resolution API
This document does not yet formally define the Model Context Protocol
[MCP] API that a conformant prompt-scheme resolver SHALL implement.
That definition is deferred to a future revision or companion
document.
Boone Expires 22 January 2027 [Page 19]
Internet-Draft prompt URI Scheme July 2026
However, the reference implementation [PROMPT-URL-MCP] demonstrates a
working API, and it is RECOMMENDED that implementations follow it for
interoperability. The reference implementation exposes the following
MCP tools over an HTTP/1.1 StreamableHTTP transport (JSON-RPC 2.0,
POST /mcp, default port 7560):
resolve_prompt
Resolves a prompt URI to the originating user message. Accepts a
single parameter uri (string). Returns the resolved user message
text, agent identifier, session identifier, timestamp, and
canonical URI. Validates host and username in remote URIs against
the local machine's hostname and current OS user, respectively.
generate_prompt_url
Generates a prompt URI for a given agent, session identifier, and
optional prompt reference. Accepts agent, session_id, prompt_ref
(optional), host (optional), username (optional), and port
(optional). When host is absent, generates a local-only URI
(prompt:/...); when present, generates a remote URI
(prompt://[user@]host[:port]/...).
find_prompt
Searches session logs for prompts within a time range. Accepts
since, until, agent, and limit parameters. Returns a list of
matching prompts sorted oldest first, each including its
prompt_url, user_message, and timestamp. A commit parameter MAY
be supplied in lieu of explicit time bounds; when present, the
time range is derived from the commit timestamp and its
predecessor using git log.
list_sessions
Lists known agent sessions for the current user, optionally
filtered by agent identifier.
register_alias
Registers a human-readable alias for a session identifier,
enabling the alias form of the prompt URI (Section 4.7).
Implementations that provide remote resolution (prompt:// form) over
the network SHOULD require authentication before serving session log
content. The reference implementation currently binds to 127.0.0.1
only (loopback) and does not expose session content to other machines
without explicit network reconfiguration. Deployers that choose to
expose the service on a non-loopback interface MUST implement
appropriate access controls.
Boone Expires 22 January 2027 [Page 20]
Internet-Draft prompt URI Scheme July 2026
10. Security Considerations
*Confidentiality:* A prompt URI encodes the agent identity, session
identifier, and approximate timestamp of a tool call. In its remote
form, it additionally encodes the hostname of the user's machine and
optionally the username of the account under which the agent
operates. Any or all of this information MAY be sensitive: session
identifiers may be treated as access credentials; hostnames and
usernames identify specific individuals and machines; and the
existence of a particular agent interaction may itself be
confidential in some deployments. Implementors SHOULD treat prompt
URIs -- particularly remote-form URIs containing hostname or username
-- with the same access controls applied to session logs, and SHOULD
NOT embed remote-form URIs in artifacts that will be shared beyond
the trust boundary of the originating user and machine.
*Spoofability:* Prompt URIs are not cryptographically signed. Any
party with knowledge of a valid agent name, session identifier, and
approximate timestamp can construct a syntactically valid URI.
Resolvers SHALL NOT treat a prompt URI as proof of authenticity; they
SHOULD verify that the referenced session log actually contains a
prompt at the indicated time.
*Log availability:* Resolution depends on the availability of session
logs, which are typically stored on the client machine. Logs may be
deleted, corrupted, or unavailable to the resolver. Provenance
systems SHALL NOT treat an unresolvable URI as evidence of tampering;
unresolvability is an expected operational condition.
*Session identifier reuse:* If an agent implementation reuses session
identifiers across sessions (which SHOULD NOT occur when UUIDs are
used), URIs from different sessions would become ambiguous.
Implementations SHALL use session identifiers with negligible
collision probability.
11. IANA Considerations
This document requests registration of the prompt URI scheme in the
IANA Uniform Resource Identifier (URI) Schemes registry, established
by [RFC7595].
Scheme name: prompt
Status: Provisional
Applications/protocols that use this scheme: AI agent provenance
metadata, session log indexers, agent tool frameworks.
Boone Expires 22 January 2027 [Page 21]
Internet-Draft prompt URI Scheme July 2026
Contact: Keith W. Boone
Change controller: Keith W. Boone
References: This document.
Pending IANA registration, implementations SHALL treat the prompt
scheme as an unregistered provisional scheme per [RFC7595]
Section 3.3.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
12.2. Informative References
Boone Expires 22 January 2027 [Page 22]
Internet-Draft prompt URI Scheme July 2026
[MCP] Anthropic, "Model Context Protocol Specification",
Available at: https://modelcontextprotocol.io/, 2024.
[CLAUDE-SESSIONS]
Anthropic, "Claude Code Session Log Format", Internal
format; session logs stored at ~/.claude/
projects/{project}/{session-id}.jsonl. Prompt correlation
field: promptId., 2026.
[COPILOT-SESSIONS]
GitHub, "Copilot Session State Format", Internal format;
session events stored at ~/.copilot/session-
state/{session-id}/events.jsonl. Timestamp format: ISO
8601 UTC with milliseconds. Prompt correlation field:
interactionId., 2026.
[PROMPT-URL-MCP]
Boone, K., "prompt-url-mcp: MCP Server for prompt: URI
Resolution and Generation", Available at:
https://github.com/AudaciousInquiry/prompt-url and
https://www.npmjs.com/package/@audaciousinquiry/prompt-
url-mcp, 2026.
Appendix A: Automatic Prompt-URL Trailer via Git Hook
This appendix describes a prepare-commit-msg git hook, provided
alongside the reference implementation [PROMPT-URL-MCP], that
automatically appends a Prompt-URL: trailer to any git commit that
was AI-assisted by GitHub Copilot.
Operation
Git invokes prepare-commit-msg after the initial commit message is
prepared but before the editor is opened. The hook:
1. Examines the draft commit message for a Co-authored-by: Copilot
trailer injected automatically by VS Code / GitHub Copilot.
2. If the trailer is present and no Prompt-URL: trailer already
exists, queries the local prompt-url-mcp daemon (via its
find_prompt tool, Section 9) for the most recent Copilot prompt
submitted within the past 30 minutes.
3. If a result is returned, appends a Prompt-URL: trailer containing
the local-form prompt URI (prompt:/github-copilot/...) to the
commit message.
Boone Expires 22 January 2027 [Page 23]
Internet-Draft prompt URI Scheme July 2026
4. If the daemon is not running or returns no results, exits
silently without modifying the commit message. The hook MUST NOT
block a commit under any error condition.
Installation
The hook is a Node.js script that requires Node.js in PATH and the
prompt-url-mcp daemon to be running. It is located at hooks/prepare-
commit-msg in the reference implementation repository.
*Per-repository installation:*
cp hooks/prepare-commit-msg .git/hooks/prepare-commit-msg
chmod +x .git/hooks/prepare-commit-msg
*Global installation* (applies to all repositories for the current
user). The recommended global hooks directory is ~/.git-hooks/:
git config --global core.hooksPath ~/.git-hooks
mkdir -p ~/.git-hooks
cp hooks/prepare-commit-msg ~/.git-hooks/prepare-commit-msg
chmod +x ~/.git-hooks/prepare-commit-msg
On Windows the chmod command may be run in Git Bash or WSL. Git for
Windows treats copied scripts as executable by default.
Resulting Commit Message
A commit message with Copilot co-authorship, after the hook appends
the trailer, takes the following form:
feat: add user registration validation
Implement unique-email check at registration time. Returns 409
if the email address is already in use.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Prompt-URL: prompt:/github-copilot/95602ecf-.../~8e16a698-...
Author's Address
Keith W. Boone
Audacious Inquiry
Email: kboone@ainq.com
Boone Expires 22 January 2027 [Page 24]