Generalise the CARING section 32 role set (R-2, INFO-DEC-2026-001)

The role set — Principal, effective actor, Delegator, tool or agent, policy
ceiling, execution context, audit identity — now applies wherever a subject's
access is exercised through another party, rather than to non-human subjects
only.

The gap this closes is not about agents. A support operator impersonating a
customer involves no non-human subject anywhere in the path, yet without the
decomposition that operator's audit identity and policy ceiling collapse into
the customer's, which is the outcome CARING's exposure analysis exists to
prevent. CARING already names customer impersonation as an exposure mode and
ImpersonationBlocked as a control; the vocabulary for analysing it was gated to
subjects the case does not involve. Section 33 was already subject-agnostic, so
the canon applied the execution paths to any subject while restricting the roles
along those paths to non-human ones — an artifact of the section heading, not a
considered position.

Accepted narrowly. Section 32.1 stays agent-stated, with a note on reading the
capability ceiling for a human effective actor. No role is removed, renamed or
added, and section 33 is untouched. Option C, a twelfth dimension, is rejected as
duplicating sections 32 and 33 while touching a dimension set the Kubernetes RBAC
benchmark depends on.

Canon version moves to 0.4.0-RC2-itc2; source version stays 0.4.0-RC2, since
this revises the InfoTechCanon-aligned standard and claims nothing about
upstream CARING. The change is additive: an implementation that applied the set
only to non-human subjects stays conformant for those subjects.

Review record in history/; the SecurityCanon boundary file and placement record
are updated to show R-2 resolved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da

history/2026-09-20_235357+0200-caring-32-generalisation.md

@@ -0,0 +1,80 @@
+# CARING section 32 generalisation — review and decision
+
+Date: 2026-09-20 (Europe/Berlin)
+Residual: R-2, raised by the SecurityCanon boundary review and explicitly not
+accepted there, "an InfoTechCanon change requiring its own review".
+Decision: **INFO-DEC-2026-001 — accept, narrowly.**
+
+## The proposal
+
+SecurityCanon's implications note, section 4, offers three options for the
+CARING section 32 role set — Principal, effective actor, Delegator, tool or
+agent, policy ceiling, execution context, audit identity — which section 32
+scopes with the words "For non-human subjects".
+
+| Option | Description | Their assessment |
+| --- | --- | --- |
+| A | Leave CARING unchanged; SecurityCanon maps into it. | Viable, zero upstream cost, leaves a real gap. |
+| B | Drop the non-human scoping; the roles apply to any subject. | Recommended if and when InfoTechCanon wants it. Additive and non-breaking. |
+| C | Promote actor and authority context to a twelfth CARING dimension. | Premature; sections 32 and 33 already cover the cases. |
+
+SecurityCanon raised B as a demand signal and stated that nothing in its own
+work blocks on the outcome. That is the correct handling under SEC-ADR-001 and
+is why this review is free to decide on the merits rather than under pressure.
+
+## Assessment
+
+**The gap is real and is not about agents.** A support operator impersonating a
+customer involves no non-human subject anywhere in the path. Without the role
+decomposition, that operator's audit identity and policy ceiling collapse into
+the customer's — which is precisely the outcome CARING's own exposure analysis
+exists to prevent. CARING already names the case: "Customer impersonation" is an
+exposure mode and `ImpersonationBlocked` is a control. The vocabulary for
+analysing it was gated to subjects the case does not involve.
+
+**Section 33 is already subject-agnostic.** It classifies access by execution
+path — direct, delegated, mediated, induced — and its definitions speak of "the
+subject" without qualification. Only its examples are agent-flavoured. So the
+canon already applies the *paths* to any subject while restricting the *roles*
+along those paths to non-human ones. That asymmetry is not a considered position;
+it is an artifact of section 32 having been written under an agent-focused
+heading.
+
+**Option C is correctly rejected.** A twelfth dimension would duplicate sections
+32 and 33, and CARING's dimension set is load-bearing for the Kubernetes RBAC
+benchmark and the descriptor work. Adding to it is a heavier change than this
+gap justifies.
+
+**Option A is defensible and was the status quo for a reason.** CARING is a
+release candidate, and the conservative move is to leave it alone. The argument
+against A is that the gap is in the standard, not in SecurityCanon: leaving it
+means the canon has vocabulary for agent impersonation and none for human
+impersonation, and any consumer meeting the human case has to invent it.
+
+## Decision
+
+Accept **Option B, narrowly scoped**:
+
+- Section 32's role set now applies where a subject's access is exercised
+  **through another party**, rather than to non-human subjects only.
+- Section 32.1, the Agent Access Formula, stays where it is and stays agent-
+  stated, since the capability ceiling is a property of the tool. A note says how
+  to read it for a human effective actor.
+- No role is removed, renamed or added. Section 33 is untouched.
+- Canon version moves from `0.4.0-RC2-itc1` to `0.4.0-RC2-itc2`. Source version
+  stays `0.4.0-RC2`: this is an InfoTechCanon-side revision of an aligned
+  standard, not a claim about upstream CARING.
+
+## Compatibility
+
+Additive and non-breaking. An implementation that applied the role set only to
+non-human subjects remains conformant for those subjects; it simply now has
+vocabulary for a case it previously had to describe by analogy. Nothing that was
+required becomes optional, and nothing optional becomes required.
+
+## Limits
+
+This is an agent review, not human sign-off, and it records no consumer
+adoption. It generalises the scope of an existing role set; it does not add the
+on-behalf-of relation that the access-control model still lacks, which the
+SecurityCanon mapping table records as a blank cell and which remains open.

infospace/interfaces/security-canon-boundary.md

@@ -64,9 +64,12 @@ Limits of this acceptance:
 - Scoped to SecurityCanon draft 0.2.0. No stable promotion is asserted.
 - Acceptance covers the semantic boundary and import declarations. It records no
   consumer adoption, no runtime claim, and no conformance statement.
-- A proposal to generalise CARING section 32 beyond non-human subjects is
-  referenced by SecurityCanon but is **not** accepted here. It would be an
-  InfoTechCanon change requiring its own review.
+- A proposal to generalise CARING section 32 beyond non-human subjects was
+  referenced by SecurityCanon and not accepted at the time of this review. It
+  was reviewed separately on 2026-09-20 and **accepted** as INFO-DEC-2026-001;
+  see `history/2026-09-20_235357+0200-caring-32-generalisation.md`. CARING moves
+  to canon version 0.4.0-RC2-itc2. The change is additive and affects no
+  SecurityCanon declaration.
 - The G7 validator in `prj-canon-federation` pins card paths for
   info-tech-canon, commerce-canon and the-custodian. Registering the
   security-canon card is that project's change; this review does not make it.

infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md

@@ -60,7 +60,7 @@ updated_at: 2026-05-23
 **CARING:** Canonical Access Roles for Information Needs Governance
 **Document Status:** Release Candidate, InfoTechCanon-aligned refactor
 **Source Version:** 0.4.0-RC2
-**Canon Version:** 0.4.0-RC2-itc1
+**Canon Version:** 0.4.0-RC2-itc2
 **Document Type:** Specialized InfoTechCanon Standard
 **Recommended Repository Path:** `standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md`
 
@@ -3321,7 +3321,8 @@ If a namespace is used as a tenant boundary, the analysis must verify whether th
 
 CARING treats agents, automations, and services as first-class subjects.
 
-For non-human subjects, access must distinguish:
+Where a subject's access is exercised **through another party**, access must
+distinguish:
 
 ```text
 
@@ -3341,8 +3342,25 @@ Audit identity
 
 ```
 
+This role set was written for non-human subjects and generalised to any subject
+in canon version 0.4.0-RC2-itc2, under INFO-DEC-2026-001. The motivating case is
+human-on-human: a support operator impersonating a customer involves no agent at
+all, yet without this decomposition the operator's audit identity and policy
+ceiling collapse into the customer's. Section 33 classifies the execution paths
+— delegated, mediated, induced — over which the role set applies, and it is
+already subject-agnostic.
+
+The generalisation is additive. No role is removed or renamed, the formula in
+32.1 generalises unchanged, and an implementation that applied the set only to
+non-human subjects remains conformant for those subjects.
+
 ### 32.1 Agent Access Formula
 
+The formula below is stated for the agent case, where the capability ceiling is
+a property of the tool. For a human effective actor, read the ceiling as the
+impersonating operator's own policy ceiling.
+
+
 ```text
 
 Effective Agent Access =