# 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.