Policy Provision and Governance Inheritance from an Organisational Identity Substrate
draft-morrison-org-alter-policy-provision-06
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 | Blake Morrison | ||
| Last updated | 2026-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-morrison-org-alter-policy-provision-06
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational 21 October 2026
Expires: 24 April 2027
Policy Provision and Governance Inheritance from an Organisational
Identity Substrate
draft-morrison-org-alter-policy-provision-06
Abstract
This memo specifies how an artificial-intelligence agent runtime,
bound at instantiation to a principal identity handle, resolves at
session initialisation a target organisational identity substrate
from a manifest source bound to the runtime's working context and
retrieves from that substrate a typed policy stack comprising a
handbook artefact, a standard-operating-procedure registry pointer,
an enforcement-gate specification, and an audit-signal ingestion
endpoint. The policy stack is then applied as runtime constraints on
subsequent tool invocations, with audit signals emitted back to the
same substrate. Policy provision occurs in the same act of session
initialisation as principal identification, rather than as a separate
ceremony against a side-channel governance plane. A principal
concurrently bound to multiple organisational substrates operates the
runtime under a deterministic composition of the several policy
stacks. A cross-organisational residual conflict suspends the
conflicting action, and is resolved through the peer-protocol
Identity Accord ceremony only where the principal discloses each
binding to the other, never through a meta-federation authority. The
memo is Informational. The wire surface relies on the DNS-based
discovery of draft-morrison-mcp-dns-discovery and the handle
namespace of draft-morrison-identity-pronouns; no new transport is
introduced.
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/.
Morrison Expires 24 April 2027 [Page 1]
Internet-Draft Org-Alter Policy Provision October 2026
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 24 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operative Surfaces . . . . . . . . . . . . . . . . . . . 5
3.2. Flow Stages . . . . . . . . . . . . . . . . . . . . . . . 6
4. Discovery and Resolution . . . . . . . . . . . . . . . . . . 7
5. Enforcement Gate Grammar . . . . . . . . . . . . . . . . . . 8
6. Audit Signal Flow . . . . . . . . . . . . . . . . . . . . . . 10
7. Live Policy Updates . . . . . . . . . . . . . . . . . . . . . 11
8. Multi-Organisational Composition . . . . . . . . . . . . . . 12
9. Compliance-State Inheritance . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11.1. Manifest-Source Spoofing . . . . . . . . . . . . . . . . 14
11.2. Substrate Compromise . . . . . . . . . . . . . . . . . . 15
11.3. Trust-Tier Escalation . . . . . . . . . . . . . . . . . 16
11.4. Multi-Organisational Conflict Exploitation . . . . . . . 16
11.5. Live-Update Replay . . . . . . . . . . . . . . . . . . . 16
11.6. Pseudonymous Discovery Substrates . . . . . . . . . . . 17
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
12.1. Significance-Predicate Scope . . . . . . . . . . . . . . 17
12.2. Argument Redaction . . . . . . . . . . . . . . . . . . . 17
12.3. Identity-Binding Leakage . . . . . . . . . . . . . . . . 18
13. Relation to Companion Memos . . . . . . . . . . . . . . . . . 18
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
15. Document History . . . . . . . . . . . . . . . . . . . . . . 19
16. Normative References . . . . . . . . . . . . . . . . . . . . 23
17. Informative References . . . . . . . . . . . . . . . . . . . 24
Morrison Expires 24 April 2027 [Page 2]
Internet-Draft Org-Alter Policy Provision October 2026
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
Artificial-intelligence agent runtimes operated by a human principal
require, at the moment they begin acting on the principal's behalf, a
corpus of policy artefacts that constrain their behaviour: permitted
and refused actions, vocabulary and tone rules, escalation
procedures, audit destinations, and the standard operating procedures
the principal's organisation has adopted. In current practice these
artefacts are supplied to the agent runtime by a governance plane
architecturally separate from the principal's identity
infrastructure. The agent runtime authenticates to one substrate (an
identity provider) and receives policy from another (a governance
platform, an orchestration framework's configuration plane, a per-
tool policy console). The two substrates are joined by out-of-band
integration work specific to each deployment.
This memo specifies a different arrangement and the wire surface that
supports it. An organisational identity substrate, addressable by
the same identity handle that authenticates the principal as a member
of the organisation, exposes typed surfaces over the Model Context
Protocol [MCP] that carry the policy artefacts the agent runtime
requires. The agent runtime resolves the substrate at session
initialisation, fetches the typed surfaces, applies them as runtime
constraints, and emits audit signals to the same substrate.
The arrangement composes with the discovery mechanism of [MCPDNS],
the handle namespace of [IDPRONOUNS], the attribution grammar of
[IDCOMMITS], the cross-session coordination posture of [SUBSTRATE],
and the cross-organisational ceremony of [IDACCORD]. No new
transport, no new handle category, and no new attribution slot is
introduced. This memo specifies the typed surface set, the session-
initialisation flow that retrieves them, the runtime application of
the retrieved enforcement-gate specification, the audit-signal flow
back to the substrate, the live-update propagation, the multi-
organisational composition rule, and the compliance-state inheritance
posture.
2. Conventions and Definitions
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.
Morrison Expires 24 April 2027 [Page 3]
Internet-Draft Org-Alter Policy Provision October 2026
The following terms are defined for the purposes of this document.
Terms defined by the companion memos referenced here keep their
meaning and are repeated here only where this document uses them. A
handle named in this document corresponds to the alter: URI formed
from it as defined in [ALTER-URI]; for example, ~alice is addressed
as alter:~alice.
Agent runtime An artificial-intelligence agent runtime bound at
instantiation to a principal identity handle.
Principal The human on whose behalf an agent runtime acts, named by
the handle to which the runtime is bound at instantiation.
Policy epoch The monotonic identifier a substrate emits to mark a
state of its policy artefacts. Update notifications carry it
(Section 11.5), and the compliance snapshot is inherited at a
single epoch (Section 9).
~handle A principal identity handle as defined by [MCPDNS],
classified into the trust tiers of [IDCOMMITS] and referenced
under the conventions of [IDPRONOUNS]. A Sovereign-tier handle is
human-controlled (e.g. ~alice); an Instrument-tier handle is
agent-runtime-vendor-controlled and conventionally prefixed ~cc-
(e.g. ~cc-example-model). A handle's trust tier is a property of
the handle, not a property of any session it appears in.
Organisational identity substrate A network-addressable system that
authoritatively recognises a set of ~handles as members of an
organisation, maintains the organisation's policy artefacts, and
exposes typed surfaces by which authenticated agent runtimes of
recognised members may retrieve those artefacts and submit audit
signals back. The substrate is itself addressable by a handle,
conventionally domain-qualified (e.g. ~example.com, addressed as
alter:~example.com).
Policy artefact A datum retrieved from the organisational identity
substrate that constrains an agent runtime's subsequent behaviour.
The required policy artefacts specified by this memo are the
handbook, the standard-operating-procedure registry, the
enforcement-gate specification, and the audit-signal ingestion
endpoint.
Enforcement gate A single rule within the enforcement-gate
specification comprising a trigger predicate evaluated against
tool name and arguments, an action selected from a defined action
set, an applicability scope, and an explanation string.
Enforcement gates are policy retrieved from the substrate; they
are not hardcoded behaviour of the agent runtime.
Morrison Expires 24 April 2027 [Page 4]
Internet-Draft Org-Alter Policy Provision October 2026
Audit signal An append-only record submitted by the agent runtime to
the organisational identity substrate's ingestion endpoint
following a runtime event that meets a substrate-specified
significance predicate.
Session-bind The discrete act, at agent runtime instantiation, of
authenticating the bound principal handle to the resolved
organisational identity substrate and retrieving the policy
artefacts that will govern the session.
Manifest source A configuration surface bound to the agent runtime's
working context (DNS TXT record under the _alter. scheme of
[MCPDNS], project-resident anchor file, environment variable, or
handle- scoped fallback) that names the target organisational
identity substrate for the session. Section 4 gives the normative
evaluation order, which is this one, and states why it runs from
least to most writable by a party who controls only the working
directory tree.
Accord The peer-protocol cross-organisational ceremony defined by
[IDACCORD]. Referenced here as the terminator of unresolvable
multi-organisational policy-composition residuals.
3. Architecture
The arrangement specified by this memo comprises four operative
surfaces and three flow stages.
3.1. Operative Surfaces
The organisational identity substrate SHALL expose at minimum the
following four typed surfaces over the Model Context Protocol [MCP]
to authenticated agent runtimes of recognised members. Each surface
is addressable as a tool invocation against the substrate.
org_alter_handbook Returns the organisational handbook artefact.
The handbook comprises the body of prose policy that an
organisation customarily supplies to a contractor at the
commencement of an engagement: voice and tone rules, vocabulary
constraints, positioning rules, decision-routing rules, and any
further prose policy the organisation considers operative. The
surface SHALL support both whole-handbook retrieval and section-
scoped retrieval by section identifier.
org_alter_sop_registry Returns the registry of standard operating
procedures maintained by the organisational identity substrate.
Each registry entry carries a stable identifier, a title, a status
(live, draft, deprecated), a body, and an invocation verb under
Morrison Expires 24 April 2027 [Page 5]
Internet-Draft Org-Alter Policy Provision October 2026
which the agent runtime may execute the procedure. The surface
SHALL support both registry listing and individual-procedure
retrieval.
org_alter_enforcement_gates Returns the specification of enforcement
gates the agent runtime is to apply to subsequent tool
invocations. The grammar of an enforcement gate is defined in
Section 5.
org_alter_ingest Accepts audit signals submitted by the agent
runtime per Section 6. The surface is append-only; admitted
signals are written to the organisational identity substrate's
append-only event log and are not retractable or amendable.
Additional surfaces (a roster surface, a decisions surface, a
compliance surface) MAY be exposed by the organisational identity
substrate; agent runtimes consulting such surfaces operate beyond the
required minimum specified here.
3.2. Flow Stages
The session-bind flow comprises three stages, executed in order:
1. Resolve. The agent runtime determines the target organisational
identity substrate by consulting the manifest source, as
specified in Section 4.
2. Retrieve. The agent runtime authenticates to the resolved
substrate using the bound principal handle's session credential
and retrieves the four required policy artefacts via the surfaces
of Section 3.1.
3. Apply. The agent runtime translates the retrieved enforcement-
gate specification into runtime hooks, registers the audit-signal
endpoint as the destination for subsequent significant-event
emissions, and surfaces the handbook and SOP registry to the
bound principal as in-context advisory material.
The three stages constitute session-bind. All three SHALL complete
before the agent runtime acts on the principal's first prompt of the
session. If any stage fails, session-bind SHALL fail; partial
inheritance of policy is not permitted (Section 9).
Morrison Expires 24 April 2027 [Page 6]
Internet-Draft Org-Alter Policy Provision October 2026
4. Discovery and Resolution
The agent runtime SHALL resolve the target organisational identity
substrate from a manifest source bound to the runtime's working
context. Manifest sources are evaluated in the priority order below,
from the source least writable by a party who controls only the
working directory tree to the source most writable by such a party.
The first source that yields a handle is operative; later sources are
not consulted.
1. DNS TXT record under the _alter. scheme of [MCPDNS]. The agent
runtime resolves the working directory's source- control remote
(where present) to a domain name and queries _alter.<domain> per
[MCPDNS]. The TXT record's org_alter field, when present, names
the target substrate. Writing this source requires control of
the domain's DNS zone in the sense of [RFC9499]. A party who
controls only the working directory tree does not by that fact
possess it.
2. Project-resident anchor. A file at an implementation- defined
path within the working directory tree (a recommended path is
.alter/org-alter.toml or an [org-alter] block within
pyproject.toml, package.json, or Cargo.toml) names the target
substrate by handle. This source carries no cryptographic
binding to the substrate it names; it is consulted only when
source (1) does not resolve.
3. Environment variable. An implementation-defined environment
variable (a recommended name is ALTER_ORG_HANDLE) carries the
target substrate handle.
4. Handle-scoped fallback. If sources (1) through (3) do not
resolve, the runtime falls back to the principal's own handle-
scoped substrate. That substrate exposes the same typed surfaces
as an organisational identity substrate but is scoped to the
principal alone and does not participate in multi-organisational
composition (Section 8).
The resolved handle is translated to a substrate endpoint via the
DNS-based resolution mechanism of [MCPDNS]. The agent runtime opens
a Model Context Protocol session against the endpoint, authenticating
with the bound principal handle's session credential obtained from
the implementation-defined session manifest.
Morrison Expires 24 April 2027 [Page 7]
Internet-Draft Org-Alter Policy Provision October 2026
A substrate that does not recognise the authenticating handle as a
member SHALL refuse the session; an unrecognised handle MUST NOT
receive policy artefacts. The substrate MAY further refuse on trust-
tier grounds: an Instrument-tier handle SHALL be admitted only when
the substrate's policy explicitly admits Instrument-tier sessions
from the corresponding Sovereign-tier handle's delegation.
5. Enforcement Gate Grammar
The org_alter_enforcement_gates surface (Section 3.1) returns an
enforcement-gate specification. An enforcement-gate specification is
a list of enforcement gates. Each enforcement gate is an object with
the following fields.
id (string, REQUIRED) A stable identifier for the gate, unique
within the specification. Identifiers are used as the addressing
target for audit signals (Section 6) and for policy-update
propagation (Section 7).
trigger (object, REQUIRED) The trigger predicate evaluated against
each prospective tool invocation. The object's keys are predicate
operators; the values are operator-specific patterns. Minimum
operator set:
* tool_name_match (string): regular expression matched against
the tool name.
* path_glob (string): glob pattern matched against any argument
resolvable as a filesystem path.
* command_substring (string): substring matched against any
argument carrying a command string.
* arg_arity (object): minimum and maximum bounds on argument list
length.
A trigger object matches when every operator present in the object
matches. Additional operators MAY be defined by the substrate and
SHOULD be ignored by agent runtimes that do not understand them.
action (enum, REQUIRED) One of:
* block: the tool invocation is refused. The runtime returns the
gate's explanation string to the agent reasoning loop as a
synthetic error and emits a policy.violation audit signal.
Morrison Expires 24 April 2027 [Page 8]
Internet-Draft Org-Alter Policy Provision October 2026
* prompt-for-confirmation: the tool invocation is paused and a
confirmation prompt is rendered to the Sovereign-tier
principal. The invocation proceeds only on principal
confirmation. A gate.confirmation-requested audit signal is
emitted on prompt; a gate.confirmation-granted or
gate.confirmation-denied signal is emitted on outcome.
* allow-with-audit: the tool invocation proceeds, and a
gate.allowed-with-audit audit signal is emitted.
scope (object, OPTIONAL) An applicability scope restricting the
gate's effect. Recognised keys:
* trust_tiers (array of strings): the trust tiers (Sovereign,
Instrument, Bot) to which the gate applies. Omission indicates
all tiers.
* working_context_glob (string): a glob matched against the agent
runtime's working directory path. Omission indicates all
contexts.
explanation (string, REQUIRED) A human-readable explanation of the
gate, returned to the agent runtime on action execution. The
explanation SHOULD be sufficient for the reasoning loop to surface
to the principal without further substrate round-trip.
audit_emit_on (array of strings, OPTIONAL) A list of event types for
which audit signals are emitted on this gate's evaluation, beyond
the action-implicit signals enumerated above. Substrate-
significance predicates (Section 6) may select event types not
directly tied to a gate; this field carries the per-gate
overrides.
When two or more gates trigger on a single prospective tool
invocation (after applicability-scope filtering), the gate whose
action is most restrictive prevails. Order of restrictiveness, from
most to least, is block, prompt-for-confirmation, allow-with-audit.
The agent runtime SHALL NOT maintain enforcement gates outside the
specification retrieved from the substrate. Gates are policy,
sourced from the substrate; an agent runtime that hardcodes a gate
operates outside the surface of this memo.
Morrison Expires 24 April 2027 [Page 9]
Internet-Draft Org-Alter Policy Provision October 2026
6. Audit Signal Flow
The agent runtime emits audit signals to the substrate's
org_alter_ingest surface for runtime events that meet a substrate-
specified significance predicate. The significance predicate is
itself policy retrieved from the substrate; the substrate determines
which events are significant, not the runtime.
An audit signal is an object with the following minimum fields:
type (string, REQUIRED) The event type. The minimum-set of event
types a conformant runtime SHALL emit when triggered comprises:
* session.start at session bind, carrying the bound principal
handle, trust tier, resolved substrate handle, and manifest
source used for resolution.
* session.end at session termination, carrying the bound handle
and a structured summary of session activity.
* tool.invoke per tool invocation that meets the substrate-
specified significance predicate, carrying the tool name, a
redacted argument summary, the gate evaluation outcome, and the
result classification.
* policy.violation when a block gate action fires, carrying the
gate identifier and the offending invocation.
* policy.update on receipt of a live-substrate policy update
(Section 7), acknowledging the new policy epoch.
* gate.confirmation-requested, gate.confirmation-granted,
gate.confirmation-denied on prompt-for-confirmation flow.
* gate.allowed-with-audit on the corresponding action.
payload (object, REQUIRED) Event-type-specific structured data. The
substrate's significance predicate MAY constrain payload shape per
event type.
attribution (object, REQUIRED) Carries the Sovereign-tier handle and
any in-scope Instrument-tier handle. The grammar follows the
trailer slots defined by [IDCOMMITS]; the audit-signal attribution
field is the protocol-layer companion to the commit-trailer block.
timestamp (string, REQUIRED) Timestamp in the format of [RFC3339] at
which the runtime emitted the signal.
Morrison Expires 24 April 2027 [Page 10]
Internet-Draft Org-Alter Policy Provision October 2026
gate_id (string, OPTIONAL) When the signal arises from a gate
evaluation, the identifier of the gate.
The substrate's audit-signal endpoint is append-only. Admitted
signals SHALL NOT be retracted or amended by the emitting runtime or
by the substrate operator. This section requires policy and audit to
be co-located at the same substrate; an audit channel addressable
separately from the policy that governed the audited events does not
satisfy this specification.
7. Live Policy Updates
The agent runtime maintains, for the duration of the session, a
subscription channel against the resolved organisational identity
substrate over which the substrate emits policy-update notifications.
The subscription channel SHOULD be implemented as a server-sent
events stream [SSE] or equivalent unidirectional-from-substrate
transport that the existing Model Context Protocol session can carry
without additional authentication round-trip.
On receipt of a policy-update notification, the runtime SHALL:
1. Re-fetch the affected policy artefact via the corresponding typed
surface of Section 3.1.
2. Recompute the runtime hooks of Section 5 from the updated
enforcement-gate specification.
3. Atomically replace its in-memory policy state. No tool
invocation issued after the atomic replacement observes a partial
composition of the pre-update and post-update gate sets.
4. Emit a policy.update audit signal acknowledging the new policy
epoch.
A runtime SHALL NOT require process restart to apply a policy update.
An update notification that the runtime cannot apply (because the
substrate returned a malformed artefact, or because the runtime's
hook surface cannot represent the updated gate set) SHALL cause the
runtime to emit a policy.update-failed audit signal and either retain
the prior policy state and surface the condition to the principal, or
terminate the session at the substrate's configured failure-mode.
Morrison Expires 24 April 2027 [Page 11]
Internet-Draft Org-Alter Policy Provision October 2026
8. Multi-Organisational Composition
A principal MAY be concurrently recognised by multiple organisational
identity substrates. When more than one substrate recognises the
principal for a session (for example, when the manifest-source
resolution of Section 4 names a primary substrate and the session
credential carries auxiliary memberships), the agent runtime composes
the retrieved policy stacks under the following rules.
org_alter_handbook composition Handbooks compose by union. Where
two handbooks declare conflicting sections, the substrate declared
earlier in the manifest's precedence order prevails. In the
absence of explicit precedence, the substrate resolved from the
working- context anchor (Section 4(1) or 4(2)) prevails.
org_alter_sop_registry composition Standard-operating-procedure
registries compose by union. Procedures are identified by the
tuple (substrate-handle, procedure-identifier) to permit
identically-named procedures across substrates without collision.
org_alter_enforcement_gates composition Enforcement gates compose by
union under a strictest-applicable rule: where two gates from
distinct substrates trigger on a single prospective tool
invocation, the gate whose action is most restrictive prevails
(order as in Section 5).
org_alter_ingest segregation An audit signal arising from a gate
whose evaluation drew on policy from multiple substrates SHALL be
emitted only to the audit-signal endpoint of the substrate whose
own policy contributed the gate, and SHALL carry only that
substrate's share of the evaluation. A runtime MUST NOT emit an
audit signal to a substrate whose policy did not participate in
the evaluation. A runtime MUST NOT include in an emitted signal a
field, count, identifier, gate reference or timing correlation
from which the receiving substrate could infer that the principal
is bound to another substrate. Where a gate cannot be evaluated
without disclosing that a peer contribution exists, the runtime
SHALL suppress the invocation and record a local diagnostic
visible to the principal only. The prohibition this rule enforces
is stated in the Privacy Considerations under Identity-Binding
Leakage.
Cross-organisational residual conflicts that the composition rules
above cannot resolve (for example, two substrates' handbooks
declaring mutually-inconsistent positioning rules where neither is
clearly subordinate under the manifest precedence) SHALL cause the
agent runtime to suspend the conflicting action and to record a local
diagnostic visible to the principal only. The runtime MUST NOT emit
Morrison Expires 24 April 2027 [Page 12]
Internet-Draft Org-Alter Policy Provision October 2026
a residual-conflict signal to any substrate and MUST NOT name one
substrate to another, because either act discloses the principal's
other binding. Where the principal elects to have the conflict
resolved between the substrates, the principal discloses each binding
to the other as a deliberate act, and the peer-protocol Identity
Accord ceremony [IDACCORD] then proceeds between the participating
substrates on that disclosure. Resolution does not proceed via a
meta-federation authority, and the composition rules of this section
define none.
9. Compliance-State Inheritance
At session-bind, the agent runtime inherits the organisational
identity substrate's then-current compliance state as a single
coherent snapshot. The snapshot comprises at minimum:
* The audit-signal endpoint URI and its current write credential.
* The enforcement-gate specification at its current epoch.
* The standard-operating-procedure registry pointer at its current
revision.
* A hash of the handbook artefact at its current revision.
* The set of compliance commitments the substrate has accepted and
currently asserts (for example, a refusal of a specified category
of automated invocation, or a specified regulatory posture).
Inheritance SHALL be atomic. Either all snapshot elements are
inherited at a single substrate epoch, or session-bind fails. A
session that proceeds with a partial snapshot is non-conformant. The
runtime SHALL surface session-bind failure to the principal with the
substrate-returned diagnostic; it SHALL NOT silently degrade to a
fallback policy stack.
Subsequent live updates (Section 7) modify the snapshot at the
runtime in place but do not retroactively alter the snapshot epoch
recorded at session-bind. The audit trail of a session is the
sequence of policy epochs the runtime observed across its lifetime,
anchored by the session-bind snapshot.
10. IANA Considerations
This memo requests no IANA action.
Morrison Expires 24 April 2027 [Page 13]
Internet-Draft Org-Alter Policy Provision October 2026
The four required typed surfaces named in Section 3.1
(org_alter_handbook, org_alter_sop_registry,
org_alter_enforcement_gates, org_alter_ingest) are illustrative of
the reference substrate operated by Alter Meridian Pty Ltd.
Conforming substrates MAY name their surfaces by any convention
consistent with their addressing primitive. This memo specifies the
typed-surface enumeration over an organisational identity substrate,
not the surface names themselves.
Where a substrate elects to advertise its handle in the [MCPDNS]
discovery record, the org_alter field is added under the field-
extension mechanism of [MCPDNS]; this memo requests no separate
registry allocation. No new DNS RR types, transport identifiers,
port numbers, URI schemes, or media types are introduced. The reuse
of the _alter.<domain> DNS label (Section 4(1)) is per [MCPDNS] and
requires no further allocation here.
The project-resident anchor path of Section 4(2), the environment-
variable name of Section 4(3), and the session-manifest layout
referenced in Section 4 are implementation-defined and are not
registered.
11. Security Considerations
The arrangement specified by this memo concentrates policy,
attribution, and audit on a single substrate addressable by the
principal's identity credential. The arrangement depends on that
concentration, and the concentration is the main source of the
following security considerations.
11.1. Manifest-Source Spoofing
The subsections below reason about a substrate that has already been
correctly resolved. This subsection addresses the step that precedes
all of them. A party able to influence the working directory tree
that an agent runtime resolves against (a compromised or malicious
repository, a poisoned pull request checked out for review, a
dependency that ships an [org-alter] block) may attempt to cause the
manifest-source resolution of Section 4 to name a substrate that
party controls. Such a party need not compromise a substrate; it is
enough that content it controls is consulted as the resolution input.
Mitigations:
* Section 4 orders the DNS TXT source ahead of the project- resident
anchor because writing the former requires control of a DNS zone,
and writing the latter requires only write access to the working
directory tree. A conformant implementation SHALL NOT consult the
project-resident anchor when the DNS source resolves. Resolution
Morrison Expires 24 April 2027 [Page 14]
Internet-Draft Org-Alter Policy Provision October 2026
then does not depend on working-directory content. The org_alter
field lies outside the Ed25519 signing input of the [MCPDNS]
envelope; its integrity rests on the DNSSEC validation that
[MCPDNS] requires for that record.
* The project-resident anchor carries no cryptographic binding to
the substrate it names. A runtime that resolves the session's
governing substrate via the project-resident anchor SHOULD surface
that fact to the principal. Governance derived from working-
directory content is otherwise indistinguishable from governance
derived from a cryptographically-bound source.
* Section 8's handbook-composition tie-break defers, in the absence
of explicit precedence, to the substrate resolved from the
working-context anchor. Because Section 4 places the DNS source
ahead of the project-resident anchor, this tie-break resolves to
the DNS-bound substrate whenever DNS resolves, and to the project-
resident anchor only when DNS does not.
11.2. Substrate Compromise
A compromised organisational identity substrate may serve falsified
policy artefacts to authenticated members, induce the runtime to emit
audit signals to an attacker-controlled endpoint, or suppress update
notifications to keep runtimes operating under stale gates.
Mitigations:
* The substrate's policy artefacts SHOULD be served over a channel
authenticated by the cryptographic identity envelope of [MCPDNS]
(the _alter.<domain> Ed25519 binding) so that a consuming runtime
can verify the artefact bears the substrate's declared signing
key.
* Audit-signal endpoints SHOULD be pinned at session-bind time to
the endpoint URI recorded in the compliance snapshot (Section 9);
mid-session redirection of the endpoint SHALL require a
policy.update notification carrying the new endpoint under the
same signing key.
* Runtimes SHOULD treat suppressed update notifications as an
observable substrate signal under the substrate-observation
posture of [SUBSTRATE]; prolonged absence of update events on a
substrate that asserts an active policy lifecycle is itself
diagnostic.
Morrison Expires 24 April 2027 [Page 15]
Internet-Draft Org-Alter Policy Provision October 2026
11.3. Trust-Tier Escalation
An Instrument-tier handle that successfully presents a Sovereign-
tier session credential (through credential theft, compromised
session manifest, or substrate misissuance) would receive the more
permissive Sovereign-tier gate set. Mitigations:
* The substrate SHALL bind trust tier to the handle itself, not to
the session, and SHALL refuse Instrument-tier handles presenting
Sovereign-tier credentials at the recognition step.
* Audit signals SHALL carry attribution per Section 6; an
Instrument-tier session writing to the audit log under a
Sovereign-tier attribution is detectable by post-hoc audit and by
the cross-tier checks defined in [IDCOMMITS].
* Sovereign-tier confirmation prompts (Section 5's prompt-for-
confirmation action) SHOULD be rendered through an out-of- band
channel addressable only by the human principal. An Instrument-
tier session in possession of the Sovereign-tier session
credential then cannot satisfy a confirmation on the principal's
behalf.
11.4. Multi-Organisational Conflict Exploitation
A principal recognised by multiple substrates may be the vector for
an exploit in which one substrate's gate is suppressed by a falsified
or absent gate from a second substrate. Mitigations:
* The strictest-applicable rule of Section 8 SHALL be evaluated over
the gates actually retrieved from each substrate. A substrate
that fails to return its enforcement-gate specification at
session-bind SHALL cause session-bind to fail for that substrate
(no implicit empty-gate-set composition).
* The principal's manifest precedence declarations SHOULD be
authenticated against the key bound to the principal's handle
under [MCPDNS] so that a forged precedence claim cannot install a
less-restrictive substrate as the primary.
11.5. Live-Update Replay
An attacker positioned to observe the subscription channel may
attempt to replay an aged policy.update notification to roll a
runtime back to an earlier policy epoch. Mitigations:
* Update notifications SHALL carry a monotonic substrate-emitted
epoch identifier.
Morrison Expires 24 April 2027 [Page 16]
Internet-Draft Org-Alter Policy Provision October 2026
* Runtimes SHALL reject notifications carrying an epoch less than or
equal to the runtime's currently-applied epoch.
* The substrate's append-only audit log retains the ordered history
of issued epoch identifiers and is consultable for post-hoc replay
detection.
11.6. Pseudonymous Discovery Substrates
The handle-scoped fallback of Section 4(4) operates the typed
surfaces against a principal-scoped substrate that does not assert
organisational membership. An agent runtime in this configuration
inherits the principal's own policy stack but does not benefit from
multi-organisational composition. Implementations SHOULD surface to
the principal that the session is operating in the fallback
configuration so that the absence of an organisational substrate is
not silently consumed.
12. Privacy Considerations
The audit-signal flow of Section 6 records the agent runtime's tool-
invocation activity on the substrate. The substrate operator has
visibility into the principal's session activity at the granularity
of the substrate-specified significance predicate.
12.1. Significance-Predicate Scope
The substrate determines which events are significant and therefore
audited. A significance predicate covering every tool invocation
yields a complete activity log; a narrower predicate audits only
events the substrate considers operative. Substrate operators SHOULD
publish their significance predicates as part of the handbook
artefact so that authenticated members understand the scope of audit
they consent to as a function of membership.
12.2. Argument Redaction
Tool-invocation arguments SHOULD be redacted before inclusion in the
tool.invoke audit signal payload. Minimum redaction practice is
removal of secret material (credentials, signing keys), personally-
identifying information about third parties referenced in the
invocation, and any field the principal has marked sensitive in a
per-session redaction profile. Substrate operators SHOULD specify
their argument-redaction expectations in the handbook artefact.
Morrison Expires 24 April 2027 [Page 17]
Internet-Draft Org-Alter Policy Provision October 2026
12.3. Identity-Binding Leakage
A principal may be concurrently bound to more than one organisational
substrate. The fact of that concurrency is itself identifying: a
substrate that learns a peer substrate participated in an evaluation
learns that the principal is bound to that peer, and no party other
than the principal can consent to the disclosure. [SUBSTRATE] names
this failure Identity-Binding Leakage and treats it as an anti-
pattern.
Accordingly, a substrate MUST NOT be told, and MUST NOT be able to
infer, that the principal holds a binding to any other substrate.
The prohibition covers the existence of the other binding, its count,
its name, its handle, its domain, and any gate, signal field, error,
latency or ordering artefact from which any of those could be
derived. It is not satisfied by pseudonymising the peer substrate,
because a stable pseudonym still discloses that a peer exists, and it
is not satisfied by notice, because notice does not make the
disclosure consented to by the principals it identifies.
Revisions -00, -01 and -02 of this memo specified in this position a
Cross-Substrate Audit Fan-Out, under which audit signals arising from
a multi-substrate evaluation were broadcast to every contributing
substrate. That mechanism is withdrawn. It performed the disclosure
this section prohibits, and it cannot be made conformant by notice or
by declaration in a handbook artefact. Implementations of an earlier
revision SHOULD disable the fan-out and emit under the segregation
rule of Section 8.
13. Relation to Companion Memos
This memo composes with five companion Internet-Drafts.
[MCPDNS] supplies the DNS-based discovery surface from which the
manifest-source resolution of Section 4(1) draws and the
cryptographic identity envelope referenced in Section 11. This memo
introduces no new DNS records or labels beyond those specified by
[MCPDNS].
[IDPRONOUNS] supplies the conventions for referencing a handle, over
the handle of [MCPDNS] and the trust tiers of [IDCOMMITS] used
throughout this memo. This memo introduces no new handle category.
[IDCOMMITS] supplies the attribution grammar that the audit- signal
attribution field of Section 6 mirrors at the protocol layer. An
audit signal and an Acted-By: / Drafted-With: commit trailer block
carry the same attribution shape, one at runtime, one at version-
control commit time.
Morrison Expires 24 April 2027 [Page 18]
Internet-Draft Org-Alter Policy Provision October 2026
[SUBSTRATE] supplies the substrate-observation posture under which
the runtime treats absence of expected update notifications as a
substrate signal (Section 11). Substrate observation also supplies
the cross-session coordination floor against which multiple
concurrent runtimes of the same principal deconflict without
exchanging coordination messages.
[IDACCORD] supplies the peer-protocol ceremony by which Section 8's
cross-organisational residuals are resolved, where the principal has
disclosed each binding to the other.
14. Implementation Status
A partial reference implementation of the agent-runtime side of this
specification is operated by the present author against a production
substrate. Of the four typed surfaces of Section 3.1, the SOP
registry and the audit ingest are reachable as tool invocations; the
handbook and the enforcement-gate specification are not yet exposed
as typed surfaces.
The provisioning path (the session-bind flow of Section 3.2) is
implemented as a service that no agent-runtime session yet invokes.
The supply of policy artefacts described in earlier revisions of this
section is therefore intent rather than experience. The instrument-
tier and recognised-member admission of Section 4 is specified but
not enforced by the reference deployment. The audit-signal flow of
Section 6 is not exercised by the reference deployment.
As [RFC7942] describes, this section documents implementation
experience and is to be removed before publication as an RFC. No
claim of interoperability is made; the reference deployment is a
single substrate operated by the specification's author.
15. Document History
draft-morrison-org-alter-policy-provision-06 (October 2026):
* Rewrites the prose against the drafting rules and pins each
citation of another Internet-Draft to its latest posted revision.
No change to any surface, flow, rule or requirement.
* Editorial pass before upload: adds Agent runtime, Principal and
Policy epoch to the definitions, corrects the first name of the
[IDACCORD] co-author in that reference, and removes a sentence
announcing the privacy subsections. No requirement changes.
draft-morrison-org-alter-policy-provision-05 (October 2026):
Morrison Expires 24 April 2027 [Page 19]
Internet-Draft Org-Alter Policy Provision October 2026
* Replaces the hand-typed BCP 14 key-words paragraph with the
standard boilerplate.
* Corrects the reference for server-sent events in Section 7.
[RFC8441] specifies WebSocket bootstrapping over HTTP/2, not
server-sent events; the reference is now the WHATWG HTML Standard
[SSE].
* Adds [RFC3339] as a normative reference for the audit-signal
timestamp field of Section 6.
* Corrects the [IDACCORD] reference to that draft's full title and
both of its authors.
* Attributes the ~handle to [MCPDNS] and the trust tiers to
[IDCOMMITS] in Section 2 and Section 13, as [IDPRONOUNS] itself
does. Section 11.4 authenticates manifest precedence against the
key bound to the principal's handle under [MCPDNS], as
[IDPRONOUNS] defines no such key.
* Corrects Section 11.1. Because the org_alter field is not within
the Ed25519 signing input of the [MCPDNS] envelope, the subsection
no longer describes DNS resolution as Ed25519-bound; it states
that the field's integrity rests on DNSSEC.
* Corrects Section 8, where the manifest-source resolution of
Section 4 was described as returning more than one substrate
handle. Section 4 yields one; further substrates arise from
memberships the session credential carries.
* Corrects the Abstract to the residual-conflict route of Section 8
as revised in -03: the action is suspended, and the [IDACCORD]
ceremony proceeds only on the principal's disclosure.
* Corrects Section 10, which attributed the session-manifest layout
to Section 4(2) and Section 4(3); those name the project-resident
anchor and the environment variable. Removes the statement about
what a future revision might request.
* Corrects the section references in Section 14: the provisioning
path is the session-bind flow of Section 3.2, member and
instrument-tier admission is in Section 4, and Section 6 has no
substrate-to-substrate audit leg. Aligns the RFC 7942 sentence
with RFC 7942.
Morrison Expires 24 April 2027 [Page 20]
Internet-Draft Org-Alter Policy Provision October 2026
* Removes statements of the memo's own contribution from Section 1
and Section 10 and from the -01 entry below, a statement that a
meta-federation authority is structurally precluded from
Section 8, and the essential-property wording from Section 6.
* Replaces "Morrison-family" with "companion" in Section 2 and
Section 13.
* Removes the name of a draft that was never posted from the -01
entry below, and removes the Acknowledgements section.
* Rewrites sentences in Sections 1, 2, 11 and 14 in plainer terms
and removes bold labels from the lists in Sections 3.2 and 4.
* States in Section 2 that a handle corresponds to an alter: URI,
and adds an informative reference to [ALTER-URI].
* No change to the typed surface set, the session-bind flow, the
enforcement-gate grammar, the audit-signal fields, the live-update
mechanism, the composition rules, the compliance-state inheritance
posture, or the IANA position.
draft-morrison-org-alter-policy-provision-04 (September 2026):
* Corrects the Implementation Status. Earlier revisions described
the supply of policy artefacts, its instrument-tier and
recognised-member scoping, and the Section 6 audit leg as
operating; each is specified but not exercised by the reference
deployment. Two of the four Section 3.1 surfaces are recorded as
reachable and two as not.
draft-morrison-org-alter-policy-provision-03 (August 2026):
* Withdraws the Cross-Substrate Audit Fan-Out. The org_alter_ingest
fan-out rule that applied under multi- organisational composition
is replaced by a segregation rule under which an audit signal
reaches only the substrate whose own policy contributed the gate,
with a normative prohibition on any field from which a receiving
substrate could infer a peer binding.
* Replaces the Cross-Substrate Audit Fan-Out subsection of the
Privacy Considerations with Identity-Binding Leakage. The new
subsection states the prohibition directly and records the
withdrawal. [SUBSTRATE] already names that failure as an anti-
pattern, and the two positions in this memo were inconsistent with
it.
Morrison Expires 24 April 2027 [Page 21]
Internet-Draft Org-Alter Policy Provision October 2026
* Revises the cross-organisational residual-conflict route. The
runtime no longer emits an accord.residual signal to the
participating substrates; it suspends the action and records a
local diagnostic, and the [IDACCORD] ceremony proceeds only on the
principal's own disclosure of each binding to the other.
* No change to the typed surface set, the session-bind flow, the
enforcement-gate grammar, the audit-signal shape, the live- update
mechanism, the compliance-state inheritance posture, or the IANA
position.
draft-morrison-org-alter-policy-provision-01 (May 2026):
* Retitles the memo from "Org-Alter-Mediated Policy Provision and
Governance Inheritance for Agent Runtimes Bound to a Principal
Identity" to "Policy Provision and Governance Inheritance from an
Organisational Identity Substrate". The retitled framing
generalises the substrate above the operator-specific org_alter_*
surface naming and clarifies that what the memo specifies is the
typed-surface enumeration over the substrate, not the surface-name
convention. The abbreviated title and the body terminology are
retained.
* Softens the IANA Considerations section. The previous revision
requested establishment of a Model Context Protocol Tool Surface
Names registry with the four org_alter_* names as initial entries.
The revised section requests no IANA action; the surface names are
explicitly illustrative of the reference substrate, and conforming
substrates MAY name surfaces by any convention consistent with
their addressing primitive. A future revision or companion
specification proposing such a registry remains possible.
* Adopts the organisational-identity-substrate framing, in which the
substrate is the core primitive.
* No substantive change to the typed surface set, the session-bind
flow, the enforcement-gate grammar, the audit- signal flow, the
live-update mechanism, the multi-organisational composition rules,
or the compliance-state inheritance posture.
draft-morrison-org-alter-policy-provision-00 (May 2026):
* Initial submission.
* Specifies the four required typed surfaces of the organisational
identity substrate (org_alter_handbook, org_alter_sop_registry,
org_alter_enforcement_gates, org_alter_ingest).
Morrison Expires 24 April 2027 [Page 22]
Internet-Draft Org-Alter Policy Provision October 2026
* Defines the session-bind flow (Resolve, Retrieve, Apply).
* Specifies the enforcement-gate grammar and the strictest-
applicable composition rule.
* Specifies the audit-signal flow and the append-only ingestion
endpoint.
* Specifies the live-policy-update subscription and atomic-
replacement requirement.
* Specifies multi-organisational composition and the cross-
organisational residual route to [IDACCORD].
* Specifies compliance-state inheritance and the atomic-snapshot
requirement.
16. 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>.
[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>.
[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>.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", Work in Progress, Internet-Draft,
draft-morrison-mcp-dns-discovery-09, 2026,
<https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
discovery/>.
[IDPRONOUNS]
Morrison, B., "Identity Pronouns: A Reference-Axis
Extension to ~handle Identity Systems", Work in Progress,
Internet-Draft, draft-morrison-identity-pronouns-05, 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
pronouns/>.
[IDCOMMITS]
Morrison, B., "Identity-Attributed Git Commits via Tier-
Structured Trailers", Work in Progress, Internet-Draft,
Morrison Expires 24 April 2027 [Page 23]
Internet-Draft Org-Alter Policy Provision October 2026
draft-morrison-identity-attributed-commits-04, 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
attributed-commits/>.
[SUBSTRATE]
Morrison, B., "Substrate-Observation as an Alternative to
Envelope Coordination for Concurrent Sessions", Work in
Progress, Internet-Draft, draft-morrison-substrate-
observation-04, 2026, <https://datatracker.ietf.org/doc/
draft-morrison-substrate-observation/>.
[IDACCORD] Morrison, B. and C. Whiteside, "Identity Accord Protocol:
A Peer Ceremony for Bilateral Agreements Between Identity-
Substrate-Bound Principals", Work in Progress, Internet-
Draft, draft-morrison-identity-accord-03, 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
accord/>.
[MCP] Agentic AI Foundation, "Model Context Protocol
Specification", 2026, <https://modelcontextprotocol.io>.
17. Informative References
[ALTER-URI]
Morrison, B., "The 'alter' URI Scheme for Dispatchable
~handle References", Work in Progress, Internet-Draft,
draft-morrison-alter-uri-scheme-05, 2026,
<https://datatracker.ietf.org/doc/draft-morrison-alter-
uri-scheme/>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[SSE] WHATWG, "HTML Living Standard: Server-sent events", 2026,
<https://html.spec.whatwg.org/multipage/server-sent-
events.html>.
Author's Address
Blake Morrison
Alter Meridian Pty Ltd
Email: blake@truealter.com
Morrison Expires 24 April 2027 [Page 24]