Org-Alter-Mediated Policy Provision and Governance Inheritance for Agent Runtimes Bound to a Principal Identity
draft-morrison-org-alter-policy-provision-00
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-05-15 | ||
| 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-00
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational May 2026
Expires: 16 November 2026
Org-Alter-Mediated Policy Provision and Governance Inheritance for Agent
Runtimes Bound to a Principal Identity
draft-morrison-org-alter-policy-provision-00
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, with cross-organisational residual conflicts routed to the
peer-protocol Identity Accord ceremony [IDACCORD] rather than to a
meta-federation authority. The memo is Informational. The wire
surface relies on the DNS-based discovery of [MCPDNS] and the handle
namespace of [IDPRONOUNS]; 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/.
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 2 November 2026.
Morrison Expires 16 November 2026 [Page 1]
Internet-Draft Org-Alter Policy Provision May 2026
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. Status of This Memo . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Operative Surfaces . . . . . . . . . . . . . . . . . . . 5
4.2. Flow Stages . . . . . . . . . . . . . . . . . . . . . . . 6
5. Discovery and Resolution . . . . . . . . . . . . . . . . . . 7
6. Enforcement Gate Grammar . . . . . . . . . . . . . . . . . . 8
7. Audit Signal Flow . . . . . . . . . . . . . . . . . . . . . . 9
8. Live Policy Updates . . . . . . . . . . . . . . . . . . . . . 11
9. Multi-Organisational Composition . . . . . . . . . . . . . . 11
10. Compliance-State Inheritance . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12.1. Substrate Compromise . . . . . . . . . . . . . . . . . . 14
12.2. Trust-Tier Escalation . . . . . . . . . . . . . . . . . 14
12.3. Multi-Organisational Conflict Exploitation . . . . . . . 15
12.4. Live-Update Replay . . . . . . . . . . . . . . . . . . . 15
12.5. Pseudonymous Discovery Substrates . . . . . . . . . . . 16
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
13.1. Significance-Predicate Scope . . . . . . . . . . . . . . 16
13.2. Argument Redaction . . . . . . . . . . . . . . . . . . . 16
13.3. Cross-Substrate Audit Fan-Out . . . . . . . . . . . . . 16
14. Relation to Companion Memos . . . . . . . . . . . . . . . . . 17
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
16.1. Normative References . . . . . . . . . . . . . . . . . . 18
16.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Morrison Expires 16 November 2026 [Page 2]
Internet-Draft Org-Alter Policy Provision May 2026
1. 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."
2. 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 articulates a different arrangement and specifies 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. Policy provision is a byproduct of principal
identification rather than a separate ceremony.
The arrangement composes directly 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. The contribution of this memo is the specification of
Morrison Expires 16 November 2026 [Page 3]
Internet-Draft Org-Alter Policy Provision May 2026
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.
The doctrinal grounding of the arrangement is articulated in
[AGENTGOV]. This memo specifies the protocol surface only; it does
not restate the doctrine.
3. 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.
The following terms are defined for the purposes of this document.
Terms previously defined by the referenced Morrison-family memos
retain their established meaning and are reproduced here only when
operative for the present specification.
~handle A principal identity handle as defined by [IDPRONOUNS]. A
Sovereign-tier handle is human-controlled (e.g. ~blake); an
Instrument-tier handle is agent-runtime-vendor-controlled and
conventionally prefixed ~cc- (e.g. ~cc-opus-4-7). 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. ~truealter.com for the
operator of this memo).
Policy artefact A datum retrieved from the organisational identity
substrate that constrains an agent runtime's subsequent behaviour.
The load-bearing 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
Morrison Expires 16 November 2026 [Page 4]
Internet-Draft Org-Alter Policy Provision May 2026
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.
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 (project-resident anchor file, DNS TXT record
under the _alter. scheme of [MCPDNS], environment variable, or
handle- scoped fallback) that names the target organisational
identity substrate for the session.
Accord The peer-protocol cross-organisational ceremony defined by
[IDACCORD]. Referenced here as the terminator of unresolvable
multi-organisational policy-composition residuals.
4. Architecture
The arrangement specified by this memo comprises four operative
surfaces and three flow stages.
4.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
Morrison Expires 16 November 2026 [Page 5]
Internet-Draft Org-Alter Policy Provision May 2026
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
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
load-bearing minimum specified here.
4.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 load-bearing 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 16 November 2026 [Page 6]
Internet-Draft Org-Alter Policy Provision May 2026
5. 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.
The first source that yields a handle is operative; later sources are
not consulted.
1. *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.
2. *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.
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, which 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.
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.
Morrison Expires 16 November 2026 [Page 7]
Internet-Draft Org-Alter Policy Provision May 2026
6. 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.
* 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.
Morrison Expires 16 November 2026 [Page 8]
Internet-Draft Org-Alter Policy Provision May 2026
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.
7. 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:
Morrison Expires 16 November 2026 [Page 9]
Internet-Draft Org-Alter Policy Provision May 2026
* 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) RFC 3339 timestamp at which the runtime
emitted the signal.
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. The structural co-location of policy and
audit at the same substrate is the load-bearing property of this
section; an audit channel addressable separately from the policy that
governed the audited events does not satisfy this specification.
Morrison Expires 16 November 2026 [Page 10]
Internet-Draft Org-Alter Policy Provision May 2026
8. 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 [RFC8441] 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.
9. Multi-Organisational Composition
A principal MAY be concurrently recognised by multiple organisational
identity substrates. When the manifest source resolution of
Section 4 returns more than one substrate handle (for example, when
the project-resident anchor 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.
Morrison Expires 16 November 2026 [Page 11]
Internet-Draft Org-Alter Policy Provision May 2026
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 fan-out An audit signal arising from a gate whose
evaluation drew on policy from multiple substrates SHALL be
emitted to the audit- signal endpoints of all participating
substrates. Each substrate receives the audit trail for its share
of the agent runtime's activity. Fan-out is realised by parallel
append calls to each substrate's audit endpoint.
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 be routed to
the peer-protocol Identity Accord ceremony [IDACCORD] between the
participating substrates. The agent runtime emits an accord.residual
audit signal to all participating substrates and suspends the
conflicting action pending resolution by the substrates' principals.
Resolution does not proceed via a meta- federation authority; a meta-
federation authority is structurally precluded by the multi-
organisational topology this section specifies.
10. 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).
Morrison Expires 16 November 2026 [Page 12]
Internet-Draft Org-Alter Policy Provision May 2026
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.
11. IANA Considerations
This memo defines a set of Model Context Protocol tool-surface names
under the org_alter_ prefix. The four load-bearing names
(org_alter_handbook, org_alter_sop_registry,
org_alter_enforcement_gates, org_alter_ingest) are registered under
the existing Morrison-family org_alter_* namespace established by the
operator of the reference substrate (Alter Meridian Pty Ltd) and
surfaced in the discovery records of [MCPDNS].
This memo requests that IANA establish, if not already established by
a companion specification, a Model Context Protocol Tool Surface
Names registry, with the four names above registered as the initial
entries, each carrying:
* The surface name.
* A reference to this document.
* A short specification of the surface's typed return shape.
* The required authentication scope (member recognition; trust tier
permitted; further substrate-specific predicates).
If the Model Context Protocol Tool Surface Names registry is
established by [MCPDNS] or a successor document, the four names above
are added to that registry under the same allocation policy.
No new DNS RR types, transport identifiers, port numbers, URI
schemes, or media types are introduced by this memo. The reuse of
the _alter.<domain> DNS label (Section 4(2)) is per [MCPDNS] and
requires no further allocation here.
The session-manifest path layout referenced by Section 4(1) and
Section 4(3) is implementation-defined and is not registered.
Morrison Expires 16 November 2026 [Page 13]
Internet-Draft Org-Alter Policy Provision May 2026
12. 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 concentration is the load-
bearing property; it is also the principal source of the following
security considerations.
12.1. 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.
12.2. 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
Sovereign-tier gate set, which is by construction more permissive.
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.
Morrison Expires 16 November 2026 [Page 14]
Internet-Draft Org-Alter Policy Provision May 2026
* 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, so that an
Instrument-tier session in possession of the Sovereign-tier
session credential cannot satisfy a confirmation on the
principal's behalf.
12.3. 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 principal's signing key per [IDPRONOUNS]
so that a forged precedence claim cannot install a less-
restrictive substrate as the primary.
12.4. 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.
* 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.
Morrison Expires 16 November 2026 [Page 15]
Internet-Draft Org-Alter Policy Provision May 2026
12.5. 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.
13. 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. Three privacy
postures arise.
13.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.
13.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.
13.3. Cross-Substrate Audit Fan-Out
Under multi-organisational composition (Section 8), audit signals
arising from gates contributed by multiple substrates are fanned out
to all contributing substrates. Each substrate receives the audit
trail for invocations its policy participated in evaluating; each
substrate may therefore see activity the principal did not intend to
surface to it. Principals SHOULD be made aware of the fan-out
posture at the time their multi-organisational membership is
Morrison Expires 16 November 2026 [Page 16]
Internet-Draft Org-Alter Policy Provision May 2026
established; substrates SHOULD declare in their handbook artefact the
fan-out events they expect to receive from sessions of members
concurrently bound to peer substrates.
14. Relation to Companion Memos
This memo composes with five Morrison-family Internet-Drafts.
[MCPDNS] supplies the DNS-based discovery surface from which the
manifest-source resolution of Section 4(2) 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 handle namespace and trust-tier taxonomy
referenced 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 a Acted-By: / Drafted-With: commit trailer block
carry the same attribution shape, one at runtime, one at version-
control commit time.
[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 to which Section 8's
cross-organisational residuals are routed.
15. Implementation Status
A reference implementation of the agent-runtime side of this
specification is operated by the present author against the substrate
~truealter.com, which exposes the surfaces of Section 3.1. The
reference deployment supplies policy artefacts to instrument-tier
agent-runtime sessions of the recognised member ~blake and writes
audit signals to the substrate's append-only event log.
Morrison Expires 16 November 2026 [Page 17]
Internet-Draft Org-Alter Policy Provision May 2026
In the spirit of [RFC7942], the present author notes that this
section is intended to document implementation experience and is
expected to be removed before the document advances beyond the
Independent Stream. No claim of interoperability is made; the
reference deployment is a single substrate operated by the
specification's author.
16. References
16.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>.
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
discovery/>.
[IDPRONOUNS]
Morrison, B., "Identity Pronouns: A Reference-Axis
Extension to ~handle Identity Systems", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
pronouns/>.
[IDCOMMITS]
Morrison, B., "Identity-Attributed Git Commits via Tier-
Structured Trailers", 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", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-
substrate-observation/>.
Morrison Expires 16 November 2026 [Page 18]
Internet-Draft Org-Alter Policy Provision May 2026
[IDACCORD] Morrison, B., "Identity Accord Protocol", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
accord/>.
[MCP] Agentic AI Foundation, "Model Context Protocol
Specification", 2026, <https://modelcontextprotocol.io>.
16.2. Informative References
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 8499, DOI 10.17487/RFC8499, January
2019, <https://www.rfc-editor.org/info/rfc8499>.
[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>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/info/rfc8441>.
[AGENTGOV] Morrison, B., "Policy is an Org-Alter Primitive (Proposed
Architectural Decision D-AGENT-GOVERNANCE-VIA-ORG-ALTER-
1)", 2026, <https://truealter.com/docs/decisions/agent-
governance-via-org-alter>.
Acknowledgements
This memo grew out of internal architectural work on the question of
how an agent runtime, bound to a principal at instantiation, should
receive the corpus of policy artefacts a real organisation supplies a
new contractor on commencement of an engagement. The realisation
that the corpus is structurally co-located with the identity that
names the principal as a member, and that the prevailing
architectural separation between governance plane and identity plane
is itself the failure mode, is the load-bearing insight behind this
specification.
Author's Address
Blake Morrison Alter Meridian Pty Ltd Cronulla, NSW Australia Email:
blake@truealter.com
Author's Address
Morrison Expires 16 November 2026 [Page 19]
Internet-Draft Org-Alter Policy Provision May 2026
Blake Morrison
Alter Meridian Pty Ltd
Cronulla, NSW
Australia
Email: blake@truealter.com
Morrison Expires 16 November 2026 [Page 20]