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.