security-canon/docs/260920-actor-subject-implications.md

---
id: SEC-NOTE-260920
type: analysis
title: "Implications of the Actor/Subject split for CARING and the access-control model"
repo: security-canon
status: for-discussion
created: "2026-09-20"
relates_to: SEC-ADR-001
carried_by: SECURITY-WP-0001-T07
---

# Implications of the Actor/Subject split

Question 3 of the [Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md),
left open by [SEC-ADR-001](adr-001-securitycanon-boundary.md) for review and
discussion. This note does not decide it.

## 1. What MoA proposes

MoA §19–20 splits the acting entity from the authority context:

```text
actor   = support-agent      ← the entity performing the action
subject = customer-123       ← whose authority context is being used
relation = IMPERSONATED      ← or DELEGATED
```

The claim is that `actor = subject` is the normal case but not the universal
one, and that delegation, impersonation, service accounts, token exchange and
agentic automation all depend on being able to say so.

The claim is correct. The problem is entirely one of naming.

## 2. The finding that reframes the question

**The split already exists downstream — twice — under different names.**

### InfoTechCanon access-control model §11.2

```text
Subject is the access-control view of an actor.
Actor semantics are owned by the Organization Model.
```

So InfoTechCanon already owns both words, and binds them in a **specific
relationship**: Subject is a *view of* Actor. Actor is owned by the Organization
Model, not by access control at all.

MoA uses the same two words for a **different relationship**: Actor and Subject
are two distinct parties, one acting on behalf of the other.

This is not an overlap that can be papered over. Under SEC-ADR-001 D2 — related
concepts at different layers must not share a word for different things — this is
the clearest violation in the entire vocabulary, and it is MoA's to fix, because
InfoTechCanon owns the terms and owned them first.

### CARING §32

For non-human subjects, CARING already distinguishes:

```text
Principal
Effective actor
Delegator
Tool or agent
Policy ceiling
Execution context
Audit identity
```

with an explicit agent access formula:

```text
Effective Agent Access =
    Delegated Human/System Authority
  ∩ Agent Capability Ceiling
  ∩ Scope Boundary
  ∩ Exposure Policy
```

and it classifies execution paths as Direct, Delegated, Mediated and Induced
(§33), with an `ImpersonationBlocked` restriction (§29).

**CARING therefore does not lack the distinction.** It has a richer one than MoA
— Delegator, audit identity, capability ceiling, induced paths — but it is scoped
to non-human subjects and expressed as a formula rather than as a general
dimension.

### Consequence

The original framing — "does MoA's split replace CARING's single Subject
dimension?" — rests on a false premise. CARING's Subject dimension is not single;
§32 and §33 already carry the split. The real questions are narrower:

1. What does MoA call its two parties, given InfoTechCanon owns *Actor* and
   *Subject* with a different meaning?
2. Should CARING's §32 vocabulary be generalised beyond non-human subjects?

## 3. Options for question 1 — naming

| Option | Description | Assessment |
| --- | --- | --- |
| **A. MoA adopts the downstream names** | Use CARING's `Principal` / `Effective actor` / `Delegator`. | Rejected. Imports implementation vocabulary into the architecture layer, which inverts the layering SEC-ADR-001 D2 establishes. |
| **B. MoA renames its second term** | Keep `Actor`; rename MoA's `Subject` to something unambiguous — `Authority Context`, `Mandate Source`, or `On-Behalf-Of Party`. | **Recommended.** Smallest change, no upstream churn, and it removes the collision at its source. `Actor` survives because MoA's use is compatible with the Organization Model's ownership of actor semantics. |
| **C. Change InfoTechCanon** | Redefine Subject upstream so both readings align. | Rejected. Edits a release-candidate standard and eleven dependent models to accommodate a draft. Contradicts D1's "help, not hinder". |
| **D. Document and live with it** | Keep both meanings, add a disambiguation page. | Rejected as a primary answer. A disambiguation page is needed regardless, but it is not a substitute for not having the collision. |

Under option B, the MoA notation becomes:

```text
support-agent:
  USE @ tenant/acme
  authority_context = customer-42
  relation = IMPERSONATED
```

`Authority Context` is preferred over the alternatives because it names what the
field actually holds — the authority being drawn on — rather than a party, which
keeps it true when the on-behalf-of target is a role or a mandate rather than a
person.

## 4. Options for question 2 — generalising CARING §32

The split matters for human-on-human cases too: a support agent impersonating a
customer involves no non-human subject, yet needs exactly the same treatment.

| Option | Description | Assessment |
| --- | --- | --- |
| **A. Leave CARING unchanged** | Non-human scoping stands; SecurityCanon maps into it. | Viable. Zero upstream cost. Leaves a real gap for human impersonation. |
| **B. Generalise the §32 role set** | Drop "for non-human subjects"; the roles apply to any subject. | **Recommended, if and when InfoTechCanon wants it.** Additive, non-breaking, and the formula already generalises unchanged. |
| **C. Add a full dimension** | Promote actor/authority-context to a twelfth CARING dimension. | Premature. §32 and §33 cover the cases; a new dimension would duplicate them. |

Option B is an InfoTechCanon change, not a SecurityCanon one. Per SEC-ADR-001 it
should be raised as a demand signal against InfoTechCanon and accepted on its own
merits, not bundled into SecurityCanon's vocabulary work. **Nothing in
SecurityCanon blocks on it.**

## 5. What SecurityCanon does regardless of the outcome

Independent of both questions, the vocabulary promotion (`SECURITY-WP-0001-T06`)
must publish a mapping table at the boundary, because three vocabularies describe
these entities today and readers will meet all three:

| MoA (architecture) | ITC access control | CARING (implementation) |
| --- | --- | --- |
| Actor | Subject / Principal | Principal, Effective actor |
| Authority Context *(proposed)* | — | Delegator |
| relation = DELEGATED | — | Delegated Access (§33.2) |
| relation = IMPERSONATED | — | Customer impersonation; `ImpersonationBlocked` |
| — | — | Audit identity, capability ceiling |

The blank cells are informative: MoA has no notion of a capability ceiling, and
InfoTechCanon's access-control model has no on-behalf-of relation at all. Neither
gap is urgent, and neither is a reason to move content between canons.

## 6. Recommendation

Adopt **3B** — rename MoA's second party to `Authority Context` — and treat
**4B** as a separate, optional demand signal against InfoTechCanon. Publish the
mapping table in §5 as part of the vocabulary promotion either way.

This keeps the collision out of the canon without touching a release-candidate
standard, which is what SEC-ADR-001 D1 and D2 jointly ask for.