generated from coulomb/repo-seed
3618 lines
67 KiB
Markdown
3618 lines
67 KiB
Markdown
# CARING Standard
|
||
## Canonical Access Roles for Information Needs Governance
|
||
|
||
**Version:** 0.4.0-RC2
|
||
**Status:** Release Candidate 2
|
||
**Document Type:** Canonical Access Governance Standard
|
||
**Primary Use:** Analysis, design, mapping, improvement, and validation of access-control systems for information products and runtime platforms
|
||
**Scope:** Humans, services, automations, agents, organizations, tenants, communities, infrastructure platforms, information systems, lifecycle processes, and exceptional access events
|
||
|
||
---
|
||
|
||
## 1. Purpose
|
||
|
||
CARING — **Canonical Access Roles for Information Needs Governance** — provides a practical, canonical vocabulary for describing and governing access to information systems across the full lifecycle of an information product.
|
||
|
||
It is intended for systems where humans, services, automations, AI agents, organizations, customers, communities, vendors, service providers, consultants, and authorities collaborate across product creation, deployment, operation, support, use, feedback, continuous improvement, and exceptional access events.
|
||
|
||
CARING exists to prevent access-control systems from degrading into unmanaged collections of local roles, implicit exceptions, historical permissions, support backdoors, hidden operator powers, unclear tenant boundaries, uncontrolled service accounts, induced privilege paths, and poorly understood data-exposure risks.
|
||
|
||
CARING is not tied to one access-control technology. It may be mapped to IAM roles, ACLs, RBAC groups, ABAC policies, ReBAC relations, service accounts, workflow permissions, database grants, Kubernetes permissions, Git permissions, support tooling, agent execution policies, runtime controllers, CI/CD pipelines, or other access-control mechanisms.
|
||
|
||
---
|
||
|
||
## 2. Core Hypothesis
|
||
|
||
CARING is based on the following hypothesis:
|
||
|
||
> Existing access-control implementations can be analyzed as compositions of CARING dimensions. A successful CARING mapping reconstructs the implementation’s declared and effective access semantics while revealing bundled roles, missing scopes, hidden exposures, weak lifecycle controls, restrictive design choices, induced access paths, and governance gaps.
|
||
|
||
A CARING analysis is considered successful when an access-control implementation can be rebuilt as a set of CARING access descriptors without introducing ad-hoc concepts outside the standard.
|
||
|
||
If an implementation cannot be modeled cleanly, the mismatch is itself valuable. It may indicate:
|
||
|
||
```text
|
||
1. A genuine gap in CARING.
|
||
2. An implementation-specific constraint below CARING’s abstraction level.
|
||
3. Hidden authority.
|
||
4. Ambiguous scope.
|
||
5. Mixed responsibility.
|
||
6. Implicit exposure.
|
||
7. Missing lifecycle governance.
|
||
8. An unmanaged exception path.
|
||
9. A gap between declared access and effective access.
|
||
10. An induced access path through automation, controllers, agents, services, or workflows.
|
||
```
|
||
|
||
This makes CARING both a standard and an evolving analytical framework.
|
||
|
||
---
|
||
|
||
## 3. Descriptive and Prescriptive Use
|
||
|
||
CARING may be used in two modes.
|
||
|
||
### 3.1 Descriptive CARING
|
||
|
||
Descriptive use maps an existing access-control implementation into CARING dimensions.
|
||
|
||
The purpose is to answer:
|
||
|
||
```text
|
||
What does this system actually allow, deny, expose, obscure, delegate, induce, or fail to govern?
|
||
```
|
||
|
||
Outputs may include:
|
||
|
||
```text
|
||
Access descriptor catalog
|
||
Capability profile map
|
||
Declared access map
|
||
Effective access map
|
||
Derived capability map
|
||
Scope model
|
||
Plane classification
|
||
Exposure map
|
||
Restriction map
|
||
Lifecycle access map
|
||
Exceptional access map
|
||
Role bundling findings
|
||
Tenant-boundary findings
|
||
Privilege-escalation findings
|
||
Induced-access findings
|
||
Redesign recommendations
|
||
```
|
||
|
||
### 3.2 Prescriptive CARING
|
||
|
||
Prescriptive use designs or improves an access-control model using CARING dimensions.
|
||
|
||
The purpose is to answer:
|
||
|
||
```text
|
||
How should access be structured for clarity, safety, speed, collaboration, and governance?
|
||
```
|
||
|
||
Outputs may include:
|
||
|
||
```text
|
||
Canonical role model
|
||
Capability profiles
|
||
Scope hierarchy
|
||
Plane model
|
||
Exposure rules
|
||
Condition rules
|
||
Agent access ceilings
|
||
Service-account rules
|
||
Exception workflows
|
||
Review cycles
|
||
Governance controls
|
||
Policy linting rules
|
||
Conformance tests
|
||
```
|
||
|
||
CARING does not require an existing system to be well-designed in order to describe it.
|
||
|
||
---
|
||
|
||
## 4. Core Principle: Orthogonality
|
||
|
||
CARING separates access governance into independent dimensions.
|
||
|
||
The core dimensions are:
|
||
|
||
```text
|
||
Subject
|
||
Organization Relation
|
||
Canonical Role
|
||
Scope
|
||
Plane
|
||
Capability
|
||
Exposure Mode
|
||
Condition
|
||
Lifecycle State
|
||
Restriction
|
||
Exposure Event
|
||
```
|
||
|
||
No single dimension should be overloaded to express all others.
|
||
|
||
A role does not fully define access.
|
||
|
||
A role only becomes an effective access policy when combined with organization relation, scope, plane, capability, exposure mode, conditions, lifecycle controls, and restrictions.
|
||
|
||
---
|
||
|
||
## 5. Native Role Warning
|
||
|
||
Many systems use the word **role** for constructs that are not equivalent to a CARING Canonical Role.
|
||
|
||
A native construct named `role` may represent:
|
||
|
||
```text
|
||
A capability profile
|
||
A local title
|
||
A group
|
||
A rule bundle
|
||
A policy object
|
||
An access assignment
|
||
A workflow responsibility
|
||
An application-specific modifier
|
||
```
|
||
|
||
Therefore:
|
||
|
||
> A native construct named “role” SHOULD NOT be assumed to map to a CARING Canonical Role. It must be analyzed according to its actual semantics.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
A Lotus/Domino ACL level such as Reader or Editor
|
||
→ usually a Capability Profile under Doer.
|
||
|
||
A Kubernetes Role
|
||
→ usually a Capability Profile over verbs, resources, and scope.
|
||
|
||
A business title such as Department Admin
|
||
→ usually a Local Title that must be mapped to role, scope, plane, and capabilities.
|
||
```
|
||
|
||
---
|
||
|
||
## 6. CARING Access Descriptor
|
||
|
||
Every relevant access assignment should be expressible as:
|
||
|
||
```text
|
||
Subject
|
||
has Canonical Role
|
||
from Organization Relation
|
||
within Scope
|
||
on Plane
|
||
with Capabilities
|
||
under Conditions
|
||
with Exposure Mode
|
||
for Lifecycle State
|
||
unless overridden by Restrictions
|
||
or classified as an Exposure Event.
|
||
```
|
||
|
||
Example:
|
||
|
||
```text
|
||
A Vendor Operator
|
||
may restart production services
|
||
for Tenant Alpha
|
||
on the Runtime Plane
|
||
with Operate and Restore capabilities
|
||
under ticket + MFA + audit conditions
|
||
with metadata-only exposure
|
||
for incident recovery.
|
||
```
|
||
|
||
This is different from:
|
||
|
||
```text
|
||
A Customer Operator
|
||
may restart customer-managed automations
|
||
inside Workspace Finance
|
||
on the Execution Plane
|
||
with Operate capability
|
||
under tenant policy
|
||
with no platform access.
|
||
```
|
||
|
||
Same canonical role word: **Operator**.
|
||
Different organization relation, scope, plane, exposure, and governance context.
|
||
|
||
---
|
||
|
||
## 7. Declared Access and Effective Access
|
||
|
||
CARING distinguishes declared access from effective access.
|
||
|
||
### 7.1 Declared Access
|
||
|
||
**Declared Access** is access explicitly represented by the native access-control system.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
A database ACL grants Editor.
|
||
A Kubernetes Role grants create pods.
|
||
An IAM policy allows s3:GetObject.
|
||
A Git repository role grants Maintainer.
|
||
```
|
||
|
||
### 7.2 Effective Access
|
||
|
||
**Effective Access** is access that can actually be achieved through direct, delegated, mediated, derived, or induced execution paths.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
A user can create a workload.
|
||
The workload can mount a service account.
|
||
The service account can read secrets.
|
||
Therefore the user may effectively gain secret exposure.
|
||
```
|
||
|
||
### 7.3 Analysis Requirement
|
||
|
||
CARING analysis MUST attempt to reconstruct effective access, not merely declared access.
|
||
|
||
A CARING map that only records declared policy may miss the actual security posture of a system.
|
||
|
||
---
|
||
|
||
## 8. Derived Capability
|
||
|
||
A **Derived Capability** is a capability that is not directly granted as a named permission, but becomes available as a consequence of another permission.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Declared capability:
|
||
Create workload.
|
||
|
||
Derived capabilities:
|
||
Execute code.
|
||
Use mounted secrets.
|
||
Use mounted service account.
|
||
Access mounted volumes.
|
||
```
|
||
|
||
Derived capabilities are especially important in:
|
||
|
||
```text
|
||
Kubernetes and container platforms
|
||
CI/CD systems
|
||
Workflow engines
|
||
Agentic coding systems
|
||
Automation platforms
|
||
Plugin systems
|
||
Integration platforms
|
||
Low-code/no-code platforms
|
||
```
|
||
|
||
CARING analysis SHOULD identify derived capabilities where they materially affect exposure, scope, tenant isolation, or privilege escalation.
|
||
|
||
---
|
||
|
||
# Part I — Core Dimensions
|
||
|
||
---
|
||
|
||
## 9. Dimension: Subject
|
||
|
||
A **Subject** is the entity to which access may be assigned or attributed.
|
||
|
||
Canonical subject types:
|
||
|
||
```text
|
||
Human
|
||
Group
|
||
Organization
|
||
Service
|
||
Automation
|
||
Agent
|
||
System
|
||
Device
|
||
Process
|
||
Anonymous
|
||
Unknown
|
||
```
|
||
|
||
### 9.1 Human
|
||
|
||
A natural person acting directly.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Developer
|
||
Customer employee
|
||
Consultant
|
||
Support agent
|
||
Auditor
|
||
Trainer
|
||
```
|
||
|
||
### 9.2 Group
|
||
|
||
A collection of subjects.
|
||
|
||
Groups are assignment conveniences. They are not equivalent to canonical roles.
|
||
|
||
### 9.3 Organization
|
||
|
||
A legal, contractual, commercial, or community entity.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor company
|
||
Customer company
|
||
Consultancy
|
||
Open-source foundation
|
||
Regulator
|
||
```
|
||
|
||
### 9.4 Service
|
||
|
||
A non-human technical identity that performs system functions.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Service account
|
||
Database replication identity
|
||
CI/CD runner identity
|
||
Monitoring service
|
||
Operator controller
|
||
Kubernetes ServiceAccount
|
||
```
|
||
|
||
### 9.5 Automation
|
||
|
||
A deterministic or semi-deterministic mechanism executing defined tasks.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Scheduled job
|
||
Workflow automation
|
||
Deployment pipeline
|
||
Import job
|
||
Backup job
|
||
```
|
||
|
||
### 9.6 Agent
|
||
|
||
A goal-seeking or semi-autonomous subject, often AI-supported, that acts through tools, workflows, or APIs.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Coding agent
|
||
Support agent
|
||
Ops remediation agent
|
||
Research agent
|
||
Policy review agent
|
||
```
|
||
|
||
### 9.7 System
|
||
|
||
A larger technical system treated as an acting subject.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Identity provider
|
||
Cluster controller
|
||
Replication system
|
||
Managed service
|
||
```
|
||
|
||
### 9.8 Device
|
||
|
||
A hardware or virtual device acting as or constraining a subject.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Trusted workstation
|
||
Mobile device
|
||
Hardware security module
|
||
IoT device
|
||
```
|
||
|
||
### 9.9 Process
|
||
|
||
An executing runtime process with attributable behavior.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Application process
|
||
Worker process
|
||
Container process
|
||
Agent runtime process
|
||
```
|
||
|
||
### 9.10 Anonymous
|
||
|
||
A subject without authenticated identity.
|
||
|
||
### 9.11 Unknown
|
||
|
||
A subject that cannot be classified or identified.
|
||
|
||
This includes adversarial, accidental, misconfigured, or not-yet-classified access attempts.
|
||
|
||
---
|
||
|
||
## 10. Dimension: Organization Relation
|
||
|
||
The **Organization Relation** describes the structural relationship of the subject to the information product, tenant, operating environment, or governance context.
|
||
|
||
It is not a role.
|
||
|
||
Canonical organization relations:
|
||
|
||
```text
|
||
Vendor
|
||
ServiceProvider
|
||
Distributor
|
||
Consultant
|
||
Customer
|
||
Community
|
||
Authority
|
||
Unknown
|
||
```
|
||
|
||
### 10.1 Vendor
|
||
|
||
The entity that creates, owns, licenses, or governs the product or core platform.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Builder
|
||
Vendor Maintainer
|
||
Vendor Operator
|
||
Vendor Coach
|
||
Vendor Integrator
|
||
```
|
||
|
||
### 10.2 ServiceProvider
|
||
|
||
An entity that operates the system or parts of it on behalf of another party.
|
||
|
||
The ServiceProvider may be the same legal entity as the Vendor, but should still be conceptually separable.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
ServiceProvider Operator
|
||
ServiceProvider Integrator
|
||
ServiceProvider Manager
|
||
```
|
||
|
||
### 10.3 Distributor
|
||
|
||
An entity that brings the product to market, resells it, bundles it, or introduces it to customers.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Distributor Coach
|
||
Distributor Integrator
|
||
Distributor Manager
|
||
```
|
||
|
||
### 10.4 Consultant
|
||
|
||
An entity that helps configure, customize, adopt, extend, or optimize the system.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Consultant Integrator
|
||
Consultant Coach
|
||
Consultant Builder
|
||
Consultant Manager
|
||
```
|
||
|
||
### 10.5 Customer
|
||
|
||
The tenant, buyer, subscriber, internal department, business unit, or end organization using the information product.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Customer Manager
|
||
Customer Doer
|
||
Customer Operator
|
||
Customer Coach
|
||
```
|
||
|
||
### 10.6 Community
|
||
|
||
A participant who contributes feedback, code, documentation, extensions, issue reports, tests, examples, training material, governance input, or public knowledge without necessarily belonging to the vendor or customer organization.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Community Builder
|
||
Community Maintainer
|
||
Community Coach
|
||
Community Verifier
|
||
```
|
||
|
||
### 10.7 Authority
|
||
|
||
A legal, regulatory, or institutional entity with exceptional access claims.
|
||
|
||
Authority access should normally be modeled as an exposure event, not as ordinary standing access.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Authority LegalDemand
|
||
Authority AuditDemand
|
||
Authority DisclosureDemand
|
||
```
|
||
|
||
### 10.8 Unknown
|
||
|
||
An organization relation that is unidentified, untrusted, adversarial, anonymous, or not yet classified.
|
||
|
||
---
|
||
|
||
## 11. Dimension: Canonical Role
|
||
|
||
A **Canonical Role** describes the lifecycle responsibility posture of a subject toward an information product, system, tenant, resource, or process.
|
||
|
||
A canonical role is not a permission level.
|
||
|
||
CARING defines nine primary canonical roles:
|
||
|
||
```text
|
||
Creator
|
||
Builder
|
||
Verifier
|
||
Maintainer
|
||
Integrator
|
||
Operator
|
||
Manager
|
||
Coach
|
||
Doer
|
||
```
|
||
|
||
These are deliberately limited.
|
||
|
||
Local systems may define additional titles, groups, application-specific roles, or native policy objects, but they should be mapped to these canonical roles where possible.
|
||
|
||
---
|
||
|
||
## 12. Role: Creator
|
||
|
||
The **Creator** provides original intent, concept, purpose, direction, or authority of meaning.
|
||
|
||
The Creator may define why the system exists, what problem it solves, what values shape it, and what boundaries should be respected.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Intent
|
||
Scope
|
||
Roadmap
|
||
Concept
|
||
Requirements
|
||
Product direction
|
||
Vision documents
|
||
```
|
||
|
||
Not automatically granted:
|
||
|
||
```text
|
||
Production data
|
||
Runtime operation
|
||
Tenant administration
|
||
Customer plaintext
|
||
Policy override
|
||
```
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Creator
|
||
Community Creator
|
||
Customer Creator
|
||
```
|
||
|
||
---
|
||
|
||
## 13. Role: Builder
|
||
|
||
The **Builder** creates or modifies system artifacts.
|
||
|
||
This includes code, configuration templates, schemas, UI components, workflows, automations, agent prompts, tests, deployment definitions, documentation, integration adapters, and models.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Source repositories
|
||
Development environments
|
||
Test data
|
||
Build systems
|
||
Design documents
|
||
Issue context
|
||
Generated artifacts
|
||
```
|
||
|
||
Not automatically granted:
|
||
|
||
```text
|
||
Production operation
|
||
Customer plaintext
|
||
Policy management
|
||
Tenant-wide data access
|
||
Secret access
|
||
```
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Builder
|
||
Community Builder
|
||
Consultant Builder
|
||
Customer Builder
|
||
AI Coding Agent as Builder
|
||
CI/CD Service as Builder
|
||
```
|
||
|
||
---
|
||
|
||
## 14. Role: Verifier
|
||
|
||
The **Verifier** checks correctness, safety, quality, compliance, security, and fit to intent.
|
||
|
||
Verifier deserves canonical status because fast agentic innovation cycles require continuous independent checking.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Test systems
|
||
Logs
|
||
Evidence
|
||
Requirements
|
||
Security findings
|
||
Quality reports
|
||
Acceptance criteria
|
||
Audit records
|
||
```
|
||
|
||
Common verifier modes:
|
||
|
||
```text
|
||
Quality Verifier
|
||
Security Verifier
|
||
Compliance Verifier
|
||
Acceptance Verifier
|
||
Policy Verifier
|
||
```
|
||
|
||
Not automatically granted:
|
||
|
||
```text
|
||
Unbounded production write access
|
||
Customer plaintext
|
||
Policy override
|
||
Destructive access
|
||
```
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Verifier
|
||
Customer Verifier
|
||
Community Verifier
|
||
Authority Verifier
|
||
AI Test Agent as Verifier
|
||
Monitoring Service as Verifier
|
||
```
|
||
|
||
---
|
||
|
||
## 15. Role: Maintainer
|
||
|
||
The **Maintainer** keeps a product, component, information space, or artifact coherent over time.
|
||
|
||
Maintainers coordinate feedback, bugs, releases, patches, compatibility, deprecation, community interaction, and lifecycle continuity.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Issue tracker
|
||
Release planning
|
||
Change approval
|
||
Merge coordination
|
||
Documentation
|
||
Version history
|
||
Support escalation context
|
||
Community discussions
|
||
```
|
||
|
||
Not automatically granted:
|
||
|
||
```text
|
||
Runtime operation
|
||
Tenant content
|
||
Production secrets
|
||
Customer data
|
||
Unbounded policy authority
|
||
```
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Maintainer
|
||
Community Maintainer
|
||
Customer Maintainer
|
||
Repository Maintainer
|
||
```
|
||
|
||
---
|
||
|
||
## 16. Role: Integrator
|
||
|
||
The **Integrator** connects, installs, configures, migrates, adapts, or ramps up a system for a specific environment.
|
||
|
||
Integrator is not a generic administrator. Integrator is a lifecycle role around bringing a system into a working context.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Setup
|
||
Initial configuration
|
||
Environment connection
|
||
Identity federation
|
||
Data migration
|
||
API integration
|
||
Tenant onboarding
|
||
System handover
|
||
Acceptance preparation
|
||
```
|
||
|
||
Critical characteristic:
|
||
|
||
```text
|
||
Integrator access should usually be temporary.
|
||
```
|
||
|
||
Default lifecycle:
|
||
|
||
```text
|
||
Pre-production
|
||
Onboarding
|
||
Migration
|
||
Handover
|
||
Post-go-live support window
|
||
Expiry
|
||
```
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Integrator
|
||
ServiceProvider Integrator
|
||
Distributor Integrator
|
||
Consultant Integrator
|
||
Customer Integrator
|
||
Automation Integrator
|
||
```
|
||
|
||
---
|
||
|
||
## 17. Role: Operator
|
||
|
||
The **Operator** keeps the system running.
|
||
|
||
This role covers monitoring, incident response, backup, restore, updates, scaling, technical health, runtime intervention, and service continuity.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Runtime status
|
||
Deployment state
|
||
Logs
|
||
Metrics
|
||
Alerts
|
||
Backup and restore
|
||
Job control
|
||
Infrastructure control
|
||
Incident tooling
|
||
Operational dashboards
|
||
```
|
||
|
||
Not automatically granted:
|
||
|
||
```text
|
||
Business content
|
||
Tenant plaintext
|
||
Policy grant authority
|
||
Customer impersonation
|
||
Bulk export
|
||
Product modification
|
||
```
|
||
|
||
Principle:
|
||
|
||
```text
|
||
Operator access is runtime continuity access, not automatic information access.
|
||
```
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Operator
|
||
ServiceProvider Operator
|
||
Customer Operator
|
||
Automation Operator
|
||
Ops Agent as Operator
|
||
Kubernetes Controller as Operator
|
||
```
|
||
|
||
---
|
||
|
||
## 18. Role: Manager
|
||
|
||
The **Manager** governs a bounded information, application, tenant, process, or policy scope.
|
||
|
||
Manager captures framework-bound administration, customization, configuration, and data governance.
|
||
|
||
Manager is not a generic super-admin.
|
||
|
||
Manager means:
|
||
|
||
```text
|
||
Can shape the system within a defined governance boundary.
|
||
```
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Application configuration
|
||
Tenant settings
|
||
Workspace settings
|
||
User and group assignment
|
||
Business rules
|
||
Workflow configuration
|
||
Data lifecycle settings
|
||
Template management
|
||
Controlled access delegation
|
||
Policy administration within scope
|
||
```
|
||
|
||
Manager can exist at many scopes:
|
||
|
||
```text
|
||
Tenant Manager
|
||
Workspace Manager
|
||
Project Manager
|
||
Dataset Manager
|
||
Workflow Manager
|
||
Policy Manager
|
||
Namespace Manager
|
||
```
|
||
|
||
But CARING does not create separate canonical roles for each. The role remains **Manager**; the scope defines the boundary.
|
||
|
||
Distinction from Operator:
|
||
|
||
```text
|
||
Operator keeps the system running.
|
||
Manager shapes how the system is used.
|
||
```
|
||
|
||
Distinction from Builder:
|
||
|
||
```text
|
||
Builder changes the product or artifact.
|
||
Manager changes allowed configuration within the product.
|
||
```
|
||
|
||
---
|
||
|
||
## 19. Role: Coach
|
||
|
||
The **Coach** helps others understand, adopt, use, sell, teach, support, or improve their practical use of the system.
|
||
|
||
Coach unifies promoter, consultant, trainer, supporter, success guide, and similar roles under one canonical role.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Demo spaces
|
||
Training material
|
||
Support cases
|
||
Usage analytics
|
||
Configuration advice
|
||
Customer context
|
||
Documentation
|
||
Best practices
|
||
```
|
||
|
||
Common coach modes:
|
||
|
||
```text
|
||
Promoter
|
||
Trainer
|
||
Supporter
|
||
Consultant
|
||
Success Guide
|
||
Community Guide
|
||
```
|
||
|
||
The canonical role remains Coach.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Vendor Coach
|
||
Distributor Coach
|
||
Consultant Coach
|
||
Customer Coach
|
||
Community Coach
|
||
AI Support Agent as Coach
|
||
```
|
||
|
||
Coach access should often be:
|
||
|
||
```text
|
||
Case-scoped
|
||
Delegated
|
||
Time-limited
|
||
Masked by default
|
||
Audited
|
||
Purpose-bound
|
||
```
|
||
|
||
---
|
||
|
||
## 20. Role: Doer
|
||
|
||
The **Doer** uses the system to perform actual work.
|
||
|
||
This is the business-use role.
|
||
|
||
Typical access needs:
|
||
|
||
```text
|
||
Read
|
||
Create
|
||
Edit
|
||
Comment
|
||
Submit
|
||
Approve
|
||
Execute
|
||
Publish
|
||
Collaborate
|
||
Consume information
|
||
Produce information
|
||
```
|
||
|
||
Doer is not a single permission level.
|
||
|
||
Capability profiles such as Reader, Author, Editor, Depositor, Approver, Publisher, or Executor may be modeled under Doer.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Customer Doer
|
||
Community Doer
|
||
Vendor Doer
|
||
External Doer
|
||
```
|
||
|
||
---
|
||
|
||
## 21. Dimension: Scope
|
||
|
||
Scope defines where the role applies.
|
||
|
||
Scope prevents canonical roles from exploding into countless local variants.
|
||
|
||
Canonical scope ladder:
|
||
|
||
```text
|
||
Ecosystem
|
||
Product
|
||
Platform
|
||
Cluster
|
||
Environment
|
||
Tenant
|
||
Namespace
|
||
Domain
|
||
Workspace
|
||
Project
|
||
Process
|
||
Dataset
|
||
Resource
|
||
Subresource
|
||
Record
|
||
Field
|
||
Action
|
||
```
|
||
|
||
### 21.1 Ecosystem
|
||
|
||
The whole collaboration environment: vendor, community, distributors, customers, services, extensions, agents, governance processes, and shared artifacts.
|
||
|
||
### 21.2 Product
|
||
|
||
The information product or software product as a governed artifact.
|
||
|
||
### 21.3 Platform
|
||
|
||
Shared infrastructure, shared services, runtime substrate, or common technical foundation.
|
||
|
||
### 21.4 Cluster
|
||
|
||
A bounded infrastructure or runtime control domain.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Kubernetes cluster
|
||
Database cluster
|
||
Search cluster
|
||
Compute cluster
|
||
```
|
||
|
||
Cluster is not automatically equivalent to tenant or environment.
|
||
|
||
### 21.5 Environment
|
||
|
||
Development, test, staging, production, sandbox, demo, customer-managed instance, etc.
|
||
|
||
### 21.6 Tenant
|
||
|
||
A customer or isolated organizational unit.
|
||
|
||
Tenant should be treated as a structural isolation boundary, not merely as a group.
|
||
|
||
### 21.7 Namespace
|
||
|
||
A technical partition inside a platform, cluster, product, tenant, or environment.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Kubernetes namespace
|
||
Object-store namespace
|
||
Package namespace
|
||
Application namespace
|
||
```
|
||
|
||
Namespace may be used for tenant separation, but it is not automatically a tenant boundary.
|
||
|
||
### 21.8 Domain
|
||
|
||
A tenant-internal domain such as finance, HR, legal, operations, procurement, support, engineering, or sales.
|
||
|
||
### 21.9 Workspace
|
||
|
||
A collaborative space, team space, department, case room, project area, or knowledge area.
|
||
|
||
### 21.10 Project
|
||
|
||
A bounded effort or initiative.
|
||
|
||
### 21.11 Process
|
||
|
||
A workflow or business process.
|
||
|
||
### 21.12 Dataset
|
||
|
||
A collection of information objects.
|
||
|
||
### 21.13 Resource
|
||
|
||
A specific document, entity, file, ticket, record collection, dashboard, agent, automation, repository, model, API, workload, deployment, secret, service account, or system component.
|
||
|
||
### 21.14 Subresource
|
||
|
||
A subordinate access surface of a resource.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
pods/log
|
||
pods/exec
|
||
deployments/scale
|
||
nodes/proxy
|
||
object/metadata
|
||
object/content
|
||
```
|
||
|
||
### 21.15 Record
|
||
|
||
An individual business object.
|
||
|
||
### 21.16 Field
|
||
|
||
A specific attribute or field.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Customer Doer may read Employee Record
|
||
but not Salary Field.
|
||
```
|
||
|
||
### 21.17 Action
|
||
|
||
A specific operation.
|
||
|
||
Example:
|
||
|
||
```text
|
||
May approve payment
|
||
but may not edit payment recipient.
|
||
```
|
||
|
||
---
|
||
|
||
## 22. Dimension: Plane
|
||
|
||
Plane defines what kind of system layer or access surface is being accessed.
|
||
|
||
Canonical planes:
|
||
|
||
```text
|
||
Intent Plane
|
||
Build Plane
|
||
Runtime Plane
|
||
Execution Plane
|
||
Configuration Plane
|
||
Data Plane
|
||
Identity Plane
|
||
Policy Plane
|
||
Secret Plane
|
||
Audit Plane
|
||
Commercial Plane
|
||
Community Plane
|
||
```
|
||
|
||
### 22.1 Intent Plane
|
||
|
||
Purpose, scope, requirements, values, roadmap, product direction, governance intent.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Creator
|
||
Manager
|
||
Maintainer
|
||
Verifier
|
||
```
|
||
|
||
### 22.2 Build Plane
|
||
|
||
Source code, artifacts, schemas, tests, pipelines, documentation, models, prompts, agent recipes.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Builder
|
||
Verifier
|
||
Maintainer
|
||
```
|
||
|
||
### 22.3 Runtime Plane
|
||
|
||
Deployments, jobs, services, health, incidents, monitoring, scaling, backups, runtime objects.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Operator
|
||
Integrator
|
||
Verifier
|
||
```
|
||
|
||
### 22.4 Execution Plane
|
||
|
||
The ability to cause code, jobs, commands, workflows, agents, scripts, or workloads to run.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Operator
|
||
Builder
|
||
Doer
|
||
Automation
|
||
Agent
|
||
```
|
||
|
||
Execution Plane is separated from Runtime Plane because the ability to run something may create derived or induced access beyond ordinary runtime visibility.
|
||
|
||
### 22.5 Configuration Plane
|
||
|
||
Application settings, tenant settings, workflows, templates, business rules, integrations, config maps, feature flags.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Manager
|
||
Integrator
|
||
Coach
|
||
```
|
||
|
||
### 22.6 Data Plane
|
||
|
||
Business content, documents, records, messages, files, knowledge, operational data.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Doer
|
||
Manager
|
||
Coach
|
||
Verifier
|
||
```
|
||
|
||
### 22.7 Identity Plane
|
||
|
||
Users, groups, service accounts, agents, federation, authentication, lifecycle, certificates.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Manager
|
||
Integrator
|
||
Operator
|
||
Verifier
|
||
```
|
||
|
||
### 22.8 Policy Plane
|
||
|
||
Authorization rules, ACLs, approval flows, restrictions, delegation boundaries, role bindings, policy objects.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Manager
|
||
Verifier
|
||
Maintainer
|
||
```
|
||
|
||
### 22.9 Secret Plane
|
||
|
||
Keys, credentials, certificates, tokens, encryption material, signing keys, recovery keys.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Operator
|
||
Integrator
|
||
Verifier
|
||
```
|
||
|
||
Secret Plane access should usually be heavily restricted, separated, and audited.
|
||
|
||
### 22.10 Audit Plane
|
||
|
||
Logs, access records, evidence, compliance reports, security findings, traceability.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Verifier
|
||
Operator
|
||
Manager
|
||
Authority
|
||
```
|
||
|
||
### 22.11 Commercial Plane
|
||
|
||
Contracts, subscriptions, billing, license entitlements, quotas, purchased modules, commercial terms.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Manager
|
||
Coach
|
||
Distributor
|
||
Vendor
|
||
```
|
||
|
||
### 22.12 Community Plane
|
||
|
||
Issues, pull requests, discussions, public docs, contribution records, extension catalogs, reputation, public roadmap.
|
||
|
||
Typical roles:
|
||
|
||
```text
|
||
Community Builder
|
||
Community Maintainer
|
||
Community Coach
|
||
Community Verifier
|
||
```
|
||
|
||
---
|
||
|
||
## 23. Dimension: Capability
|
||
|
||
Capabilities describe what can be done.
|
||
|
||
Roles must not be confused with capabilities.
|
||
|
||
Canonical capability verbs:
|
||
|
||
```text
|
||
View
|
||
ViewCollection
|
||
Observe
|
||
Create
|
||
EditOwn
|
||
EditAssigned
|
||
EditAny
|
||
DeleteOwn
|
||
DeleteAny
|
||
BulkDelete
|
||
Submit
|
||
Comment
|
||
Review
|
||
Approve
|
||
Reject
|
||
Publish
|
||
Archive
|
||
Restore
|
||
Execute
|
||
Configure
|
||
Operate
|
||
Deploy
|
||
Integrate
|
||
Grant
|
||
Revoke
|
||
Delegate
|
||
Impersonate
|
||
Export
|
||
Import
|
||
Replicate
|
||
Encrypt
|
||
Decrypt
|
||
Mask
|
||
Inspect
|
||
Audit
|
||
Override
|
||
Escalate
|
||
Bind
|
||
Use
|
||
```
|
||
|
||
### 23.1 Capability Profiles
|
||
|
||
A **Capability Profile** is a named bundle of capabilities.
|
||
|
||
Capability profiles are useful for human understanding and compatibility with existing systems.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Reader
|
||
Author
|
||
Contributor
|
||
Editor
|
||
Depositor
|
||
Approver
|
||
Publisher
|
||
Designer
|
||
RuntimeOperator
|
||
TenantManager
|
||
DatabaseManager
|
||
NamespaceAdmin
|
||
ClusterAdmin
|
||
```
|
||
|
||
Capability profiles are not canonical roles. They should be mapped to canonical roles, scopes, planes, and capabilities.
|
||
|
||
---
|
||
|
||
## 24. Common Capability Profiles
|
||
|
||
### 24.1 Reader
|
||
|
||
```text
|
||
Canonical Role:
|
||
Doer
|
||
|
||
Capabilities:
|
||
View
|
||
|
||
Plane:
|
||
Data
|
||
|
||
Exposure:
|
||
Plaintext or masked, depending on data policy
|
||
```
|
||
|
||
### 24.2 Contributor / Author
|
||
|
||
```text
|
||
Canonical Role:
|
||
Doer
|
||
|
||
Capabilities:
|
||
View
|
||
Create
|
||
EditOwn or EditAssigned
|
||
|
||
Plane:
|
||
Data
|
||
```
|
||
|
||
### 24.3 Editor
|
||
|
||
```text
|
||
Canonical Role:
|
||
Doer
|
||
|
||
Capabilities:
|
||
View
|
||
Create
|
||
EditOwn
|
||
EditAny
|
||
|
||
Plane:
|
||
Data
|
||
```
|
||
|
||
### 24.4 Depositor / Submitter
|
||
|
||
```text
|
||
Canonical Role:
|
||
Doer
|
||
|
||
Capabilities:
|
||
Submit
|
||
Create
|
||
|
||
Not granted:
|
||
View
|
||
|
||
Plane:
|
||
Data
|
||
|
||
Exposure:
|
||
None or minimal confirmation after submission
|
||
```
|
||
|
||
### 24.5 Designer
|
||
|
||
```text
|
||
Canonical Role:
|
||
Builder
|
||
|
||
Capabilities:
|
||
Create
|
||
EditAny
|
||
Configure
|
||
Review
|
||
|
||
Plane:
|
||
Build / Configuration
|
||
```
|
||
|
||
### 24.6 Runtime Operator
|
||
|
||
```text
|
||
Canonical Role:
|
||
Operator
|
||
|
||
Capabilities:
|
||
Operate
|
||
Restore
|
||
Inspect
|
||
Deploy, if authorized
|
||
|
||
Plane:
|
||
Runtime
|
||
```
|
||
|
||
### 24.7 Tenant Manager
|
||
|
||
```text
|
||
Canonical Role:
|
||
Manager
|
||
|
||
Capabilities:
|
||
Configure
|
||
Grant
|
||
Revoke
|
||
Delegate
|
||
Archive
|
||
Restore
|
||
|
||
Scope:
|
||
Tenant
|
||
```
|
||
|
||
### 24.8 Namespace Manager
|
||
|
||
```text
|
||
Canonical Role:
|
||
Manager
|
||
|
||
Capabilities:
|
||
Configure
|
||
Grant
|
||
Revoke
|
||
Bind
|
||
Create
|
||
EditAny
|
||
DeleteAny
|
||
|
||
Scope:
|
||
Namespace
|
||
|
||
Planes:
|
||
Runtime
|
||
Configuration
|
||
Policy
|
||
```
|
||
|
||
### 24.9 Full Manager / Database Manager
|
||
|
||
```text
|
||
Canonical Role:
|
||
Manager
|
||
|
||
Capabilities:
|
||
Configure
|
||
Grant
|
||
Revoke
|
||
Delegate
|
||
View
|
||
Create
|
||
EditAny
|
||
DeleteAny
|
||
Archive
|
||
Restore
|
||
Replicate, if authorized
|
||
|
||
Planes:
|
||
Policy
|
||
Configuration
|
||
Data
|
||
```
|
||
|
||
This is a compound profile and should be treated as high authority.
|
||
|
||
### 24.10 Cluster Superuser / Cluster Admin
|
||
|
||
```text
|
||
Canonical Roles:
|
||
Operator
|
||
Manager
|
||
sometimes Integrator
|
||
|
||
Capabilities:
|
||
Operate
|
||
Configure
|
||
Grant
|
||
Revoke
|
||
Bind
|
||
Escalate
|
||
Override
|
||
Impersonate, if included
|
||
View
|
||
Create
|
||
EditAny
|
||
DeleteAny
|
||
Restore
|
||
|
||
Scope:
|
||
Cluster
|
||
|
||
Planes:
|
||
Runtime
|
||
Execution
|
||
Configuration
|
||
Policy
|
||
Identity
|
||
Secret
|
||
Audit
|
||
```
|
||
|
||
This is a compound maximum-authority profile and should be treated as exceptional or highly controlled.
|
||
|
||
---
|
||
|
||
## 25. Dimension: Exposure Mode
|
||
|
||
Exposure Mode describes how much information the subject may perceive, derive, retain, extract, or transfer.
|
||
|
||
Canonical exposure modes:
|
||
|
||
```text
|
||
None
|
||
Metadata
|
||
Masked
|
||
Aggregated
|
||
Synthetic
|
||
Pseudonymous
|
||
Encrypted
|
||
Plaintext
|
||
SecretMaterial
|
||
Exportable
|
||
CrossTenantAggregate
|
||
```
|
||
|
||
### 25.1 None
|
||
|
||
No information is exposed.
|
||
|
||
### 25.2 Metadata
|
||
|
||
Only metadata is exposed.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Resource name
|
||
Timestamp
|
||
Status
|
||
Size
|
||
Owner identifier
|
||
Record count
|
||
Runtime status
|
||
```
|
||
|
||
### 25.3 Masked
|
||
|
||
Sensitive values are hidden or redacted.
|
||
|
||
### 25.4 Aggregated
|
||
|
||
Information is shown only in aggregated form.
|
||
|
||
### 25.5 Synthetic
|
||
|
||
Non-real information is used.
|
||
|
||
Typical for development, testing, demos, and training.
|
||
|
||
### 25.6 Pseudonymous
|
||
|
||
Direct identifiers are replaced with pseudonyms.
|
||
|
||
### 25.7 Encrypted
|
||
|
||
Information is stored or transmitted but not intelligible to the subject.
|
||
|
||
### 25.8 Plaintext
|
||
|
||
The subject can perceive the real content.
|
||
|
||
### 25.9 SecretMaterial
|
||
|
||
The subject can perceive, copy, use, or derive secret material.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Passwords
|
||
API keys
|
||
Private keys
|
||
Tokens
|
||
Certificates
|
||
Session secrets
|
||
Recovery material
|
||
```
|
||
|
||
SecretMaterial is separated from ordinary Plaintext because it can create further access beyond the immediate system.
|
||
|
||
### 25.10 Exportable
|
||
|
||
The subject can extract, copy, replicate, download, forward, or otherwise remove information from its controlled context.
|
||
|
||
Exportable is not implied by Plaintext.
|
||
|
||
### 25.11 CrossTenantAggregate
|
||
|
||
The subject can see aggregated information across tenants.
|
||
|
||
This should be separately governed.
|
||
|
||
Important rules:
|
||
|
||
```text
|
||
Plaintext is not implied by role.
|
||
Exportable is not implied by plaintext.
|
||
SecretMaterial is not ordinary plaintext.
|
||
CrossTenantAggregate is not implied by platform access.
|
||
Secret visibility is not implied by runtime visibility.
|
||
```
|
||
|
||
---
|
||
|
||
## 26. Dimension: Condition
|
||
|
||
Conditions define when and under what obligations access is valid.
|
||
|
||
Canonical conditions:
|
||
|
||
```text
|
||
MFARequired
|
||
DeviceTrusted
|
||
NetworkTrusted
|
||
TicketRequired
|
||
TenantConsentRequired
|
||
CustomerApprovalRequired
|
||
DualApprovalRequired
|
||
TimeLimited
|
||
BusinessHoursOnly
|
||
EmergencyOnly
|
||
TrainingRequired
|
||
ContractRequired
|
||
NDARequired
|
||
PurposeBound
|
||
CaseBound
|
||
EnvironmentBound
|
||
NamespaceBound
|
||
PipelineBound
|
||
ChangeWindowBound
|
||
Logged
|
||
Recorded
|
||
NotificationRequired
|
||
PostReviewRequired
|
||
HumanReviewRequired
|
||
PolicyReviewRequired
|
||
WorkloadIdentityRequired
|
||
```
|
||
|
||
Example:
|
||
|
||
```text
|
||
Vendor Coach may access Tenant Alpha support case data
|
||
only when:
|
||
TicketRequired
|
||
TenantConsentRequired
|
||
TimeLimited
|
||
Logged
|
||
PurposeBound
|
||
```
|
||
|
||
Conditions are part of effective access.
|
||
If required conditions are not satisfied, access is denied.
|
||
|
||
---
|
||
|
||
## 27. Dimension: Lifecycle State
|
||
|
||
Lifecycle State describes why access exists now.
|
||
|
||
Canonical lifecycle states:
|
||
|
||
```text
|
||
Design
|
||
Build
|
||
Test
|
||
Review
|
||
Release
|
||
Onboard
|
||
Integrate
|
||
Migrate
|
||
Operate
|
||
Support
|
||
Improve
|
||
Deprecate
|
||
Archive
|
||
Incident
|
||
Legal
|
||
Terminate
|
||
```
|
||
|
||
Lifecycle matters because access that is legitimate in one state may become illegitimate in another.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Consultant Integrator access is valid during Onboard and Integrate.
|
||
It does not remain valid during Operate unless explicitly extended.
|
||
```
|
||
|
||
Agentic development compresses lifecycle loops:
|
||
|
||
```text
|
||
Customer feedback
|
||
→ issue
|
||
→ generated patch
|
||
→ test
|
||
→ review
|
||
→ deployment
|
||
→ runtime observation
|
||
→ further improvement
|
||
```
|
||
|
||
CARING therefore requires lifecycle-aware access governance.
|
||
|
||
---
|
||
|
||
## 28. Dimension: Restriction
|
||
|
||
Restrictions are overriding policy effects.
|
||
|
||
They are not normal roles.
|
||
|
||
Canonical restrictions:
|
||
|
||
```text
|
||
NoAccess
|
||
Suspended
|
||
Terminated
|
||
Quarantined
|
||
ScopeExcluded
|
||
DataClassRestricted
|
||
LegalHold
|
||
ExportBlocked
|
||
ImpersonationBlocked
|
||
CrossTenantBlocked
|
||
SecretAccessBlocked
|
||
PolicyFrozen
|
||
EmergencyLocked
|
||
RiskDenied
|
||
ExecutionBlocked
|
||
WorkloadCreationBlocked
|
||
PrivilegeEscalationBlocked
|
||
```
|
||
|
||
### 28.1 Restriction Precedence
|
||
|
||
Recommended precedence:
|
||
|
||
```text
|
||
1. Tenant boundary
|
||
2. Legal hold / quarantine / suspension / termination
|
||
3. Explicit deny
|
||
4. Data classification restriction
|
||
5. Secret restriction
|
||
6. Execution restriction
|
||
7. Conditional requirements
|
||
8. Scoped allow
|
||
9. Default deny
|
||
```
|
||
|
||
### 28.2 NoAccess
|
||
|
||
NoAccess is an explicit deny effect.
|
||
|
||
It should not be treated as an ordinary role.
|
||
|
||
### 28.3 Suspended
|
||
|
||
Subject exists but cannot access until reinstated.
|
||
|
||
### 28.4 Terminated
|
||
|
||
Subject is no longer eligible for access.
|
||
|
||
### 28.5 Quarantined
|
||
|
||
Access blocked due to risk, incident, malware, abuse, or investigation.
|
||
|
||
### 28.6 ScopeExcluded
|
||
|
||
Subject is member of a broader group but explicitly excluded from this scope.
|
||
|
||
### 28.7 DataClassRestricted
|
||
|
||
Sensitive class, field, or tag overrides otherwise broad access.
|
||
|
||
### 28.8 LegalHold
|
||
|
||
Resource cannot be deleted or altered because of legal or compliance hold.
|
||
|
||
### 28.9 ExportBlocked
|
||
|
||
Subject may view but may not export.
|
||
|
||
### 28.10 SecretAccessBlocked
|
||
|
||
Subject may operate or configure without access to secret material.
|
||
|
||
### 28.11 CrossTenantBlocked
|
||
|
||
Subject may not cross tenant boundaries.
|
||
|
||
This should generally be structural and non-bypassable.
|
||
|
||
### 28.12 ExecutionBlocked
|
||
|
||
Subject may inspect or configure but may not cause execution.
|
||
|
||
### 28.13 WorkloadCreationBlocked
|
||
|
||
Subject may not create workloads that could induce broader access.
|
||
|
||
### 28.14 PrivilegeEscalationBlocked
|
||
|
||
Subject may not bind, escalate, impersonate, or otherwise expand effective authority.
|
||
|
||
---
|
||
|
||
## 29. Dimension: Exposure Event
|
||
|
||
Exposure Events are controlled exceptions or observed irregularities.
|
||
|
||
They are not ordinary roles.
|
||
|
||
Canonical exposure event classes:
|
||
|
||
```text
|
||
X-Support
|
||
X-BreakGlass
|
||
X-SecurityTest
|
||
X-Incident
|
||
X-LegalDemand
|
||
X-ComplianceAudit
|
||
X-Migration
|
||
X-Recovery
|
||
X-Adversarial
|
||
X-Misconfiguration
|
||
X-InducedAccess
|
||
X-PrivilegeEscalation
|
||
```
|
||
|
||
### 29.1 X-Support
|
||
|
||
Support case required access to tenant data or environment.
|
||
|
||
### 29.2 X-BreakGlass
|
||
|
||
Emergency privileged access to prevent or repair serious harm.
|
||
|
||
### 29.3 X-SecurityTest
|
||
|
||
Authorized penetration test, red-team activity, white-hat test, or vulnerability validation.
|
||
|
||
### 29.4 X-Incident
|
||
|
||
Security or reliability incident investigation.
|
||
|
||
### 29.5 X-LegalDemand
|
||
|
||
Court order, regulator demand, police request, subpoena, statutory duty, or similar legal access demand.
|
||
|
||
### 29.6 X-ComplianceAudit
|
||
|
||
Compliance investigation or audit.
|
||
|
||
### 29.7 X-Migration
|
||
|
||
Data migration, tenant move, onboarding, export/import, or restructuring.
|
||
|
||
### 29.8 X-Recovery
|
||
|
||
Backup restore, disaster recovery, corruption repair, or data reconstruction.
|
||
|
||
### 29.9 X-Adversarial
|
||
|
||
Unauthorized or hostile access attempt or confirmed compromise.
|
||
|
||
### 29.10 X-Misconfiguration
|
||
|
||
Unexpected exposure caused by configuration error, policy error, implementation error, or misunderstood inheritance.
|
||
|
||
### 29.11 X-InducedAccess
|
||
|
||
Unexpected or high-risk access caused indirectly through automation, controllers, workloads, workflows, agents, service accounts, or other mediated execution paths.
|
||
|
||
### 29.12 X-PrivilegeEscalation
|
||
|
||
Access expansion caused by policy manipulation, impersonation, binding, escalation, secret exposure, induced workload authority, or other privilege growth.
|
||
|
||
Each exposure event should record:
|
||
|
||
```text
|
||
event_id
|
||
actor
|
||
subject
|
||
organization_relation
|
||
canonical_role
|
||
scope
|
||
plane
|
||
capabilities_used
|
||
derived_capabilities
|
||
exposure_mode
|
||
reason
|
||
authority_source
|
||
approval
|
||
start_time
|
||
end_time
|
||
resources_accessed
|
||
evidence
|
||
notification_status
|
||
post_review
|
||
```
|
||
|
||
---
|
||
|
||
# Part II — Structural Rules
|
||
|
||
---
|
||
|
||
## 30. Tenant Isolation
|
||
|
||
Tenant isolation is a structural boundary.
|
||
|
||
It must not be treated merely as a role, group, namespace, label, or naming convention.
|
||
|
||
CARING tenant isolation principles:
|
||
|
||
```text
|
||
1. Every protected resource should have a tenant context
|
||
or be explicitly classified as platform-global.
|
||
|
||
2. Every authorization decision involving tenant resources
|
||
should include tenant context.
|
||
|
||
3. A subject’s role in Tenant A does not imply the same role in Tenant B.
|
||
|
||
4. Platform access does not imply tenant data access.
|
||
|
||
5. Cross-tenant access requires explicit purpose, scope, exposure mode,
|
||
authority source, and audit trail.
|
||
|
||
6. Internal tenant groupings may overlap, but overlap must be resolved
|
||
by scope, relationship, attributes, capabilities, and restrictions.
|
||
|
||
7. Tenant boundary violations should be classified as incidents
|
||
or exposure events.8. Technical namespaces may support tenant isolation,
|
||
but they are not automatically sufficient tenant boundaries.
|
||
```
|
||
|
||
Example:
|
||
|
||
```text
|
||
A Customer Manager in Tenant Alpha
|
||
has no access in Tenant Beta
|
||
unless separately assigned.
|
||
```
|
||
|
||
---
|
||
|
||
## 31. Namespace and Tenant Separation
|
||
|
||
A namespace is a technical scope. A tenant is a governance and isolation scope.
|
||
|
||
The two may correspond, but they are not equivalent by default.
|
||
|
||
CARING analysis SHOULD ask:
|
||
|
||
```text
|
||
Is the namespace intended to represent a tenant?
|
||
Can subjects in one namespace affect another namespace?
|
||
Can controllers or operators cross namespaces?
|
||
Can workloads mount service accounts or secrets that expand authority?
|
||
Are network, storage, secrets, identity, and policy boundaries aligned?
|
||
Are cluster-scoped resources shared across namespaces?
|
||
```
|
||
|
||
If a namespace is used as a tenant boundary, the analysis must verify whether the effective access model supports that claim.
|
||
|
||
---
|
||
|
||
## 32. Agents, Automations, and Services
|
||
|
||
CARING treats agents, automations, and services as first-class subjects.
|
||
|
||
For non-human subjects, access must distinguish:
|
||
|
||
```text
|
||
Principal
|
||
Effective actor
|
||
Delegator
|
||
Tool or agent
|
||
Policy ceiling
|
||
Execution context
|
||
Audit identity
|
||
```
|
||
|
||
### 32.1 Agent Access Formula
|
||
|
||
```text
|
||
Effective Agent Access =
|
||
Delegated Human/System Authority
|
||
∩ Agent Capability Ceiling
|
||
∩ Scope Boundary
|
||
∩ Exposure Policy
|
||
∩ Runtime Conditions
|
||
```
|
||
|
||
Example:
|
||
|
||
```text
|
||
Human Alice is Customer Doer.Editor in Project A.
|
||
Agent DraftBot may create drafts but cannot publish or export.
|
||
|
||
Therefore DraftBot acting for Alice can create drafts in Project A,
|
||
but cannot publish, export, or access Project B.
|
||
```
|
||
|
||
### 32.2 Agent Principles
|
||
|
||
```text
|
||
1. No agent receives access merely because it participates in a workflow.
|
||
|
||
2. Every agent should have an organization relation,
|
||
canonical role, scope, plane, capability ceiling,
|
||
exposure limit, delegation source, and audit trail.
|
||
|
||
3. Agent access should be purpose-bound.
|
||
|
||
4. Agent access should be inspectable.
|
||
|
||
5. Agent access should not silently inherit all human capabilities.
|
||
|
||
6. Agent access should not silently cross tenant boundaries.
|
||
|
||
7. Agent output that changes system state should be attributable.
|
||
```
|
||
|
||
---
|
||
|
||
## 33. Direct, Delegated, Mediated, and Induced Access
|
||
|
||
CARING distinguishes access by execution path.
|
||
|
||
### 33.1 Direct Access
|
||
|
||
The subject acts directly.
|
||
|
||
Example:
|
||
|
||
```text
|
||
A user opens a document.
|
||
```
|
||
|
||
### 33.2 Delegated Access
|
||
|
||
The subject delegates authority to another subject.
|
||
|
||
Example:
|
||
|
||
```text
|
||
A user authorizes an agent to draft a reply.
|
||
```
|
||
|
||
### 33.3 Mediated Access
|
||
|
||
The subject’s action is mediated by a system component that performs work on the subject’s behalf.
|
||
|
||
Example:
|
||
|
||
```text
|
||
A workflow engine creates a task after a user submits a form.
|
||
```
|
||
|
||
### 33.4 Induced Access
|
||
|
||
The subject triggers a privileged component whose actual authority exceeds the subject’s direct authority.
|
||
|
||
Example:
|
||
|
||
```text
|
||
A user creates a custom resource.
|
||
A privileged controller reacts and modifies infrastructure elsewhere.
|
||
```
|
||
|
||
Another example:
|
||
|
||
```text
|
||
A user can create a workload.
|
||
The workload runs under a service account.
|
||
The service account can read secrets.
|
||
The user may thereby induce secret access.
|
||
```
|
||
|
||
Induced access is especially important for agentic systems, workflow engines, Kubernetes operators, integration platforms, CI/CD systems, and automation frameworks.
|
||
|
||
### 33.5 Analysis Requirement
|
||
|
||
CARING analysis MUST consider whether a granted capability induces additional effective capabilities through controllers, agents, workflows, service accounts, admission hooks, pipelines, plugins, runtime execution, or other mediated mechanisms.
|
||
|
||
---
|
||
|
||
## 34. Local Roles, Capability Profiles, and Titles
|
||
|
||
CARING distinguishes:
|
||
|
||
```text
|
||
Canonical Role
|
||
Capability Profile
|
||
Local Role
|
||
Local Title
|
||
Group
|
||
Native Policy Object
|
||
```
|
||
|
||
### 34.1 Canonical Role
|
||
|
||
Lifecycle responsibility posture.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Builder
|
||
Operator
|
||
Manager
|
||
Doer
|
||
```
|
||
|
||
### 34.2 Capability Profile
|
||
|
||
A named bundle of capabilities.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Reader
|
||
Editor
|
||
RuntimeOperator
|
||
DatabaseManager
|
||
ClusterAdmin
|
||
```
|
||
|
||
### 34.3 Local Role
|
||
|
||
An application-specific or system-specific role.
|
||
|
||
Example:
|
||
|
||
```text
|
||
[Approver]
|
||
FinanceReviewer
|
||
ProjectLead
|
||
NamespaceAdmin
|
||
```
|
||
|
||
### 34.4 Local Title
|
||
|
||
Human-readable organizational title.
|
||
|
||
Example:
|
||
|
||
```text
|
||
Senior Developer
|
||
Department Admin
|
||
Support Engineer Level 2
|
||
Regional Sales Analyst
|
||
```
|
||
|
||
### 34.5 Group
|
||
|
||
A collection of subjects.
|
||
|
||
Groups may be used for assignment, but group membership should not be confused with canonical role semantics.
|
||
|
||
### 34.6 Native Policy Object
|
||
|
||
A system-native object that expresses permissions.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Kubernetes Role
|
||
AWS IAM policy
|
||
Azure role assignment
|
||
Database grant
|
||
Unix sudo rule
|
||
```
|
||
|
||
Native policy objects should be mapped to CARING dimensions according to their actual semantics.
|
||
|
||
---
|
||
|
||
# Part III — Normative Requirements
|
||
|
||
---
|
||
|
||
## 35. Normative Statements
|
||
|
||
### CRS-001: Orthogonality
|
||
|
||
CARING-compliant access models MUST distinguish organization relation, canonical role, scope, plane, capability, exposure mode, condition, lifecycle state, restriction, and exposure event.
|
||
|
||
### CRS-002: Role limitation
|
||
|
||
CARING implementations SHOULD map local roles to the canonical roles:
|
||
|
||
```text
|
||
Creator
|
||
Builder
|
||
Verifier
|
||
Maintainer
|
||
Integrator
|
||
Operator
|
||
Manager
|
||
Coach
|
||
Doer
|
||
```
|
||
|
||
### CRS-003: Native role analysis
|
||
|
||
A native construct named `role` MUST NOT be assumed to map directly to a CARING Canonical Role. It may represent a capability profile, local title, group, policy object, rule bundle, or access assignment.
|
||
|
||
### CRS-004: Scope binding
|
||
|
||
No role assignment is complete without an explicit scope.
|
||
|
||
### CRS-005: Plane binding
|
||
|
||
No role assignment is complete without identifying the plane or planes on which it applies.
|
||
|
||
### CRS-006: Capability binding
|
||
|
||
Roles MUST NOT imply unlimited capabilities. Effective permissions MUST be expressed as capabilities within scope.
|
||
|
||
### CRS-007: Tenant isolation
|
||
|
||
Tenant isolation MUST be enforced as a structural boundary and MUST NOT depend solely on role naming, group membership, namespace naming, labels, or convention.
|
||
|
||
### CRS-008: Exposure separation
|
||
|
||
Plaintext visibility, secret-material visibility, export ability, impersonation, and cross-tenant aggregation MUST be separately controlled capabilities or exposure modes.
|
||
|
||
### CRS-009: Operator separation
|
||
|
||
Operator access MUST NOT imply ordinary business data access.
|
||
|
||
### CRS-010: Builder separation
|
||
|
||
Builder access MUST NOT imply production data access unless explicitly granted through a governed exposure event.
|
||
|
||
### CRS-011: Integrator expiry
|
||
|
||
Integrator access SHOULD be time-limited and SHOULD expire after onboarding, migration, or handover unless explicitly extended.
|
||
|
||
### CRS-012: Coach delegation
|
||
|
||
Coach access to tenant data SHOULD be case-bound, purpose-bound, delegated, time-limited, and auditable.
|
||
|
||
### CRS-013: Manager boundary
|
||
|
||
Manager access MUST be bounded by scope and MUST distinguish configuration authority from runtime operation and product modification.
|
||
|
||
### CRS-014: Agent ceiling
|
||
|
||
Automated and agentic subjects MUST have explicit capability ceilings independent of the delegating user.
|
||
|
||
### CRS-015: Exposure events
|
||
|
||
Exceptional access MUST be recorded as an exposure event with actor, reason, authority source, scope, plane, exposure mode, derived capabilities where relevant, and post-event review.
|
||
|
||
### CRS-016: Default deny
|
||
|
||
Access not explicitly granted within the relevant scope, plane, capability, condition, and lifecycle context MUST be denied by default.
|
||
|
||
### CRS-017: Restriction precedence
|
||
|
||
Restrictions MUST be evaluated before scoped allow grants.
|
||
|
||
### CRS-018: NoAccess semantics
|
||
|
||
NoAccess MUST be treated as a restriction or deny effect, not as an ordinary role.
|
||
|
||
### CRS-019: Export separation
|
||
|
||
Export, replicate, copy, bulk download, and external sharing capabilities MUST be distinguished from ordinary view access.
|
||
|
||
### CRS-020: Secret separation
|
||
|
||
Secret Plane access MUST be explicitly modeled and MUST NOT be inferred from Runtime Plane, Configuration Plane, or workload access.
|
||
|
||
### CRS-021: Policy-plane sensitivity
|
||
|
||
Capabilities that grant, revoke, bind, escalate, impersonate, or override permissions MUST be modeled as Policy Plane access.
|
||
|
||
### CRS-022: Execution-plane sensitivity
|
||
|
||
Capabilities that execute code, run workflows, launch jobs, create workloads, or invoke agents MUST be modeled as Execution Plane access where relevant.
|
||
|
||
### CRS-023: Lifecycle review
|
||
|
||
Access SHOULD be reviewed when lifecycle state changes.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Onboard → Operate
|
||
Support → Closed
|
||
Build → Release
|
||
Incident → PostReview
|
||
Employee Active → Terminated
|
||
```
|
||
|
||
### CRS-024: Descriptive completeness
|
||
|
||
A CARING analysis SHOULD attempt to reconstruct effective access, not merely declared access.
|
||
|
||
### CRS-025: Derived capability analysis
|
||
|
||
CARING analysis SHOULD identify derived capabilities where direct grants produce additional effective authority.
|
||
|
||
### CRS-026: Induced access analysis
|
||
|
||
CARING analysis SHOULD identify mediated and induced access effects caused by agents, controllers, workflows, automations, integrations, service accounts, plugins, or privileged services.
|
||
|
||
### CRS-027: Namespace caution
|
||
|
||
A namespace SHOULD NOT be assumed to be a tenant boundary unless the wider effective access model supports that interpretation.
|
||
|
||
---
|
||
|
||
# Part IV — Analysis Process
|
||
|
||
---
|
||
|
||
## 36. CARING Analysis Fitness Test
|
||
|
||
Given an access-control implementation, CARING passes the analysis test if:
|
||
|
||
```text
|
||
1. Every declared access grant can be represented
|
||
as a CARING access descriptor.
|
||
|
||
2. Every effective access grant can be represented
|
||
as a CARING access descriptor.
|
||
|
||
3. Every effective deny or restriction can be represented
|
||
as a CARING restriction or condition.
|
||
|
||
4. Every exceptional or irregular access path can be represented
|
||
as an exposure event.
|
||
|
||
5. The mapping preserves effective access semantics sufficiently
|
||
for governance analysis.
|
||
|
||
6. Any semantic loss is explicitly identifiable as either:
|
||
a) implementation-specific detail below CARING abstraction level, or
|
||
b) a genuine gap in CARING.
|
||
|
||
7. The mapping reveals bundled, ambiguous, risky,
|
||
underspecified, induced, or restrictive access decisions.
|
||
```
|
||
|
||
---
|
||
|
||
## 37. CARING Analysis Procedure
|
||
|
||
### Step 1: Identify Subjects
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Who or what can act?
|
||
Are subjects human, service, automation, agent, group, anonymous, or unknown?
|
||
Are service accounts and agents visible as first-class subjects?
|
||
```
|
||
|
||
### Step 2: Identify Organization Relations
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Under whose authority does the subject act?
|
||
Vendor?
|
||
ServiceProvider?
|
||
Distributor?
|
||
Consultant?
|
||
Customer?
|
||
Community?
|
||
Authority?
|
||
Unknown?
|
||
```
|
||
|
||
### Step 3: Map Native Roles and Policy Objects
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Is the native role a canonical role, capability profile,
|
||
local title, group, policy object, or access assignment?
|
||
```
|
||
|
||
### Step 4: Map to Canonical Roles
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Is this subject creating, building, verifying, maintaining,
|
||
integrating, operating, managing, coaching, or doing?
|
||
```
|
||
|
||
### Step 5: Identify Scope
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Where does the access apply?
|
||
Platform?
|
||
Cluster?
|
||
Environment?
|
||
Tenant?
|
||
Namespace?
|
||
Workspace?
|
||
Project?
|
||
Process?
|
||
Dataset?
|
||
Resource?
|
||
Subresource?
|
||
Record?
|
||
Field?
|
||
Action?
|
||
```
|
||
|
||
### Step 6: Identify Plane
|
||
|
||
Questions:
|
||
|
||
```text
|
||
What kind of thing is accessed?
|
||
Intent?
|
||
Build?
|
||
Runtime?
|
||
Execution?
|
||
Configuration?
|
||
Data?
|
||
Identity?
|
||
Policy?
|
||
Secret?
|
||
Audit?
|
||
Commercial?
|
||
Community?
|
||
```
|
||
|
||
### Step 7: Extract Declared Capabilities
|
||
|
||
Questions:
|
||
|
||
```text
|
||
What does the native policy explicitly allow?
|
||
View?
|
||
Create?
|
||
Edit?
|
||
Delete?
|
||
Execute?
|
||
Configure?
|
||
Grant?
|
||
Export?
|
||
Impersonate?
|
||
Deploy?
|
||
Restore?
|
||
Override?
|
||
```
|
||
|
||
### Step 8: Extract Derived Capabilities
|
||
|
||
Questions:
|
||
|
||
```text
|
||
What does the declared capability make possible indirectly?
|
||
Can execution expose data?
|
||
Can workload creation expose secrets?
|
||
Can policy editing create privilege escalation?
|
||
Can configuration trigger privileged automation?
|
||
```
|
||
|
||
### Step 9: Determine Exposure Mode
|
||
|
||
Questions:
|
||
|
||
```text
|
||
What information becomes visible?
|
||
None?
|
||
Metadata?
|
||
Masked?
|
||
Aggregated?
|
||
Synthetic?
|
||
Pseudonymous?
|
||
Encrypted?
|
||
Plaintext?
|
||
SecretMaterial?
|
||
Exportable?
|
||
Cross-tenant aggregate?
|
||
```
|
||
|
||
### Step 10: Identify Conditions
|
||
|
||
Questions:
|
||
|
||
```text
|
||
When is access valid?
|
||
MFA?
|
||
Ticket?
|
||
Consent?
|
||
Time limit?
|
||
Dual approval?
|
||
Case binding?
|
||
Purpose binding?
|
||
Logging?
|
||
Post-review?
|
||
Pipeline binding?
|
||
Workload identity?
|
||
```
|
||
|
||
### Step 11: Identify Lifecycle State
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Why does this access exist now?
|
||
Design?
|
||
Build?
|
||
Test?
|
||
Onboard?
|
||
Operate?
|
||
Support?
|
||
Incident?
|
||
Legal?
|
||
Terminate?
|
||
```
|
||
|
||
### Step 12: Identify Restrictions
|
||
|
||
Questions:
|
||
|
||
```text
|
||
What overrides access?
|
||
NoAccess?
|
||
Suspension?
|
||
Quarantine?
|
||
Legal hold?
|
||
Data classification?
|
||
Export block?
|
||
Secret access block?
|
||
Execution block?
|
||
Cross-tenant block?
|
||
Privilege-escalation block?
|
||
```
|
||
|
||
### Step 13: Identify Execution Paths
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Is access direct?
|
||
Delegated?
|
||
Mediated?
|
||
Induced?
|
||
Can a subject cause another subject to act?
|
||
Can a low-privilege subject trigger a high-privilege component?
|
||
```
|
||
|
||
### Step 14: Identify Exposure Events
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Are there break-glass paths?
|
||
Support access?
|
||
Legal access?
|
||
Migration access?
|
||
Security testing?
|
||
Incidents?
|
||
Misconfiguration?
|
||
Adversarial access?
|
||
Induced access?
|
||
Privilege escalation?
|
||
```
|
||
|
||
### Step 15: Identify Bundling and Gaps
|
||
|
||
Questions:
|
||
|
||
```text
|
||
Which local roles bundle multiple CARING dimensions?
|
||
Where does runtime access imply data access?
|
||
Where does view imply export?
|
||
Where does configuration imply policy?
|
||
Where does execution imply secret access?
|
||
Where does tenant access leak across boundaries?
|
||
Where does lifecycle access fail to expire?
|
||
Where do declared and effective access differ?
|
||
```
|
||
|
||
---
|
||
|
||
## 38. CARING Redesign Procedure
|
||
|
||
When redesigning an access-control model:
|
||
|
||
```text
|
||
1. Preserve legitimate practical intent.
|
||
2. Decompose bundled roles into CARING dimensions.
|
||
3. Separate canonical role from capability profile.
|
||
4. Make scope explicit.
|
||
5. Make plane explicit.
|
||
6. Make exposure mode explicit.
|
||
7. Separate operator access from data access.
|
||
8. Separate builder access from production data access.
|
||
9. Separate manager access from runtime operation.
|
||
10. Separate view from export.
|
||
11. Separate plaintext from secret material.
|
||
12. Separate declared access from effective access.
|
||
13. Add lifecycle expiry where needed.
|
||
14. Add exposure-event workflows for exceptions.
|
||
15. Add agent and service-account capability ceilings.
|
||
16. Add tenant-boundary enforcement.
|
||
17. Add induced-access analysis.
|
||
18. Review resulting model for usability.
|
||
```
|
||
|
||
---
|
||
|
||
# Part V — Reference Matrices
|
||
|
||
---
|
||
|
||
## 39. Canonical Role Matrix
|
||
|
||
| Role | Core question | Lifecycle center | Default plane |
|
||
|---|---|---|---|
|
||
| **Creator** | Why should this exist? | Intent | Intent |
|
||
| **Builder** | How is it made or changed? | Build | Build |
|
||
| **Verifier** | Is it correct, safe, and fit? | Review | Audit / Build / Data |
|
||
| **Maintainer** | How does it remain coherent over time? | Improve / Release | Build / Community / Intent |
|
||
| **Integrator** | How is it brought into this environment? | Onboard / Migrate | Configuration / Identity / Runtime |
|
||
| **Operator** | How is it kept running? | Operate / Incident | Runtime |
|
||
| **Manager** | How is this bounded scope governed and configured? | Configure / Govern | Configuration / Policy / Data |
|
||
| **Coach** | How are others helped to use it well? | Support / Adoption | Data / Community / Commercial |
|
||
| **Doer** | What work is performed with it? | Use | Data / Execution |
|
||
|
||
---
|
||
|
||
## 40. Organization Relation × Role Examples
|
||
|
||
| Organization Relation | Example role combinations |
|
||
|---|---|
|
||
| Vendor | Vendor Creator, Vendor Builder, Vendor Maintainer, Vendor Operator, Vendor Coach |
|
||
| ServiceProvider | ServiceProvider Operator, ServiceProvider Integrator, ServiceProvider Manager |
|
||
| Distributor | Distributor Coach, Distributor Integrator, Distributor Manager |
|
||
| Consultant | Consultant Integrator, Consultant Builder, Consultant Coach, Consultant Manager |
|
||
| Customer | Customer Manager, Customer Doer, Customer Operator, Customer Verifier |
|
||
| Community | Community Builder, Community Maintainer, Community Coach, Community Verifier |
|
||
| Authority | Authority Verifier, Authority LegalDemand |
|
||
| Unknown | Unknown Actor, Unknown Adversarial Subject |
|
||
|
||
---
|
||
|
||
## 41. Capability Profile Mapping Examples
|
||
|
||
| Capability Profile | Canonical Role | Main Capabilities | Main Plane |
|
||
|---|---|---|---|
|
||
| Reader | Doer | View | Data |
|
||
| Contributor / Author | Doer | View, Create, EditOwn/EditAssigned | Data |
|
||
| Editor | Doer | View, Create, EditAny | Data |
|
||
| Depositor / Submitter | Doer | Submit/Create without View | Data |
|
||
| Designer | Builder | Create/Edit design, Configure | Build / Configuration |
|
||
| RuntimeOperator | Operator | Operate, Inspect, Restore | Runtime |
|
||
| TenantManager | Manager | Configure, Grant, Revoke, Delegate | Configuration / Policy |
|
||
| NamespaceManager | Manager | Configure, Create, EditAny, Grant/Bind | Runtime / Configuration / Policy |
|
||
| SupportAgent | Coach | View/Comment/Guide under case conditions | Data / Configuration |
|
||
| QAReviewer | Verifier | Review, Inspect, Audit | Build / Audit |
|
||
| ReleaseMaintainer | Maintainer | Review, Approve, Publish | Build / Community |
|
||
| ClusterAdmin | Operator + Manager | Operate, Configure, Grant, Override | Runtime / Policy / Secret |
|
||
|
||
---
|
||
|
||
## 42. Native System Mapping Summary
|
||
|
||
| Native system concept | CARING interpretation |
|
||
|---|---|
|
||
| Lotus/Domino Manager | Compound Manager capability profile |
|
||
| Lotus/Domino Designer | Builder capability profile |
|
||
| Lotus/Domino Reader/Author/Editor | Doer capability profiles |
|
||
| Lotus/Domino NoAccess | Restriction |
|
||
| Lotus/Domino Readers/Authors fields | Record-level scope and relationship condition |
|
||
| Kubernetes Role | Capability profile / native policy object |
|
||
| Kubernetes ClusterRole | Cluster-scoped or reusable capability profile |
|
||
| Kubernetes RoleBinding | Access assignment |
|
||
| Kubernetes ClusterRoleBinding | Cluster-scoped access assignment |
|
||
| Kubernetes ServiceAccount | Service / automation subject |
|
||
| Kubernetes verb | Capability |
|
||
| Kubernetes resource | Scope + Plane |
|
||
| Kubernetes namespace | Namespace scope; possible but not automatic tenant boundary |
|
||
| Kubernetes secret access | Secret Plane + SecretMaterial exposure |
|
||
| Kubernetes workload creation | Execution Plane + possible derived capabilities |
|
||
|
||
---
|
||
|
||
# Part VI — Examples
|
||
|
||
---
|
||
|
||
## 43. Vendor Builder
|
||
|
||
```text
|
||
Subject:
|
||
Human or Agent
|
||
|
||
Organization Relation:
|
||
Vendor
|
||
|
||
Canonical Role:
|
||
Builder
|
||
|
||
Scope:
|
||
Product / Module / Repository / Branch / Issue
|
||
|
||
Plane:
|
||
Build
|
||
|
||
Capabilities:
|
||
Create
|
||
EditOwn
|
||
EditAny
|
||
Submit
|
||
Review
|
||
|
||
Exposure Mode:
|
||
Source context
|
||
Issue context
|
||
Synthetic or masked data
|
||
|
||
Conditions:
|
||
Code review
|
||
CI checks
|
||
Signed commits
|
||
No production secrets
|
||
|
||
Lifecycle State:
|
||
Build / Improve
|
||
```
|
||
|
||
---
|
||
|
||
## 44. Community Maintainer
|
||
|
||
```text
|
||
Subject:
|
||
Human
|
||
|
||
Organization Relation:
|
||
Community
|
||
|
||
Canonical Role:
|
||
Maintainer
|
||
|
||
Scope:
|
||
Open-source module
|
||
|
||
Plane:
|
||
Build / Community
|
||
|
||
Capabilities:
|
||
Review
|
||
Approve
|
||
Publish
|
||
|
||
Exposure Mode:
|
||
Public
|
||
Metadata
|
||
|
||
Conditions:
|
||
Maintainer policy
|
||
Contribution rules
|
||
Review process
|
||
|
||
Lifecycle State:
|
||
Improve / Release
|
||
```
|
||
|
||
---
|
||
|
||
## 45. Consultant Integrator
|
||
|
||
```text
|
||
Subject:
|
||
Human or Service
|
||
|
||
Organization Relation:
|
||
Consultant
|
||
|
||
Canonical Role:
|
||
Integrator
|
||
|
||
Scope:
|
||
Customer Tenant / Integration Project
|
||
|
||
Plane:
|
||
Configuration / Identity / Runtime
|
||
|
||
Capabilities:
|
||
Configure
|
||
Integrate
|
||
Import
|
||
Test
|
||
|
||
Exposure Mode:
|
||
Masked by default
|
||
Plaintext only by approval
|
||
|
||
Conditions:
|
||
Tenant consent
|
||
Ticket
|
||
Time limit
|
||
Audit
|
||
|
||
Lifecycle State:
|
||
Onboard / Integrate / Migrate
|
||
```
|
||
|
||
---
|
||
|
||
## 46. ServiceProvider Operator
|
||
|
||
```text
|
||
Subject:
|
||
Human, Service, Automation, or Agent
|
||
|
||
Organization Relation:
|
||
ServiceProvider
|
||
|
||
Canonical Role:
|
||
Operator
|
||
|
||
Scope:
|
||
Production Environment
|
||
|
||
Plane:
|
||
Runtime
|
||
|
||
Capabilities:
|
||
Operate
|
||
Deploy
|
||
Restore
|
||
Inspect
|
||
|
||
Exposure Mode:
|
||
Metadata
|
||
Masked logs
|
||
|
||
Conditions:
|
||
MFA
|
||
Ticket
|
||
Privileged access control
|
||
Logging
|
||
|
||
Lifecycle State:
|
||
Operate / Incident
|
||
```
|
||
|
||
---
|
||
|
||
## 47. Customer Manager
|
||
|
||
```text
|
||
Subject:
|
||
Human
|
||
|
||
Organization Relation:
|
||
Customer
|
||
|
||
Canonical Role:
|
||
Manager
|
||
|
||
Scope:
|
||
Tenant / Workspace
|
||
|
||
Plane:
|
||
Configuration / Policy / Data
|
||
|
||
Capabilities:
|
||
Configure
|
||
Grant
|
||
Revoke
|
||
Delegate
|
||
Archive
|
||
|
||
Exposure Mode:
|
||
Plaintext within tenant policy
|
||
|
||
Conditions:
|
||
Tenant governance rules
|
||
|
||
Lifecycle State:
|
||
Configure / Operate / Improve
|
||
```
|
||
|
||
---
|
||
|
||
## 48. Customer Doer as Depositor
|
||
|
||
```text
|
||
Subject:
|
||
Human, Anonymous, or External Actor
|
||
|
||
Organization Relation:
|
||
Customer / Community / Unknown
|
||
|
||
Canonical Role:
|
||
Doer
|
||
|
||
Capability Profile:
|
||
Depositor / Submitter
|
||
|
||
Scope:
|
||
Submission Process
|
||
|
||
Plane:
|
||
Data
|
||
|
||
Capabilities:
|
||
Submit
|
||
|
||
Exposure Mode:
|
||
None after submission
|
||
|
||
Conditions:
|
||
Purpose-bound
|
||
Form validation
|
||
|
||
Lifecycle State:
|
||
Use
|
||
```
|
||
|
||
---
|
||
|
||
## 49. Vendor Coach
|
||
|
||
```text
|
||
Subject:
|
||
Human or Agent
|
||
|
||
Organization Relation:
|
||
Vendor
|
||
|
||
Canonical Role:
|
||
Coach
|
||
|
||
Scope:
|
||
Customer Support Case
|
||
|
||
Plane:
|
||
Data / Configuration
|
||
|
||
Capabilities:
|
||
View
|
||
Comment
|
||
Guide
|
||
Configure, if delegated
|
||
|
||
Exposure Mode:
|
||
Masked or tenant-approved Plaintext
|
||
|
||
Conditions:
|
||
Ticket
|
||
Tenant consent
|
||
Time limit
|
||
Audit
|
||
|
||
Lifecycle State:
|
||
Support
|
||
```
|
||
|
||
---
|
||
|
||
## 50. AI Coding Agent
|
||
|
||
```text
|
||
Subject:
|
||
Agent
|
||
|
||
Organization Relation:
|
||
Vendor / Community / Customer
|
||
|
||
Canonical Role:
|
||
Builder
|
||
|
||
Scope:
|
||
Repository / Branch / Issue
|
||
|
||
Plane:
|
||
Build
|
||
|
||
Capabilities:
|
||
Create
|
||
EditOwn
|
||
Submit
|
||
|
||
Exposure Mode:
|
||
Source context
|
||
Issue context
|
||
Test output
|
||
|
||
Conditions:
|
||
No secret access
|
||
No production deploy
|
||
Human or policy review
|
||
|
||
Lifecycle State:
|
||
Build / Improve
|
||
```
|
||
|
||
---
|
||
|
||
## 51. AI Support Agent
|
||
|
||
```text
|
||
Subject:
|
||
Agent
|
||
|
||
Organization Relation:
|
||
Vendor
|
||
|
||
Canonical Role:
|
||
Coach
|
||
|
||
Scope:
|
||
Support Case
|
||
|
||
Plane:
|
||
Data / Configuration
|
||
|
||
Capabilities:
|
||
View
|
||
Comment
|
||
Recommend
|
||
|
||
Exposure Mode:
|
||
Masked by default
|
||
|
||
Conditions:
|
||
Case-bound
|
||
Tenant policy
|
||
Logged
|
||
No autonomous export
|
||
|
||
Lifecycle State:
|
||
Support
|
||
```
|
||
|
||
---
|
||
|
||
## 52. Break-Glass Operator Access
|
||
|
||
```text
|
||
Subject:
|
||
Human
|
||
|
||
Organization Relation:
|
||
ServiceProvider
|
||
|
||
Canonical Role:
|
||
Operator
|
||
|
||
Exposure Event:
|
||
X-BreakGlass
|
||
|
||
Scope:
|
||
Tenant Alpha / Affected Runtime Resource Set
|
||
|
||
Plane:
|
||
Runtime / Data if unavoidable / Secret if unavoidable
|
||
|
||
Capabilities:
|
||
Operate
|
||
Restore
|
||
Inspect
|
||
Limited View if required
|
||
|
||
Exposure Mode:
|
||
Metadata by default
|
||
Plaintext only if necessary and recorded
|
||
SecretMaterial only if necessary and recorded
|
||
|
||
Conditions:
|
||
EmergencyOnly
|
||
TicketRequired
|
||
DualApprovalRequired where feasible
|
||
TimeLimited
|
||
Logged
|
||
Recorded
|
||
PostReviewRequired
|
||
NotificationRequired unless prohibited
|
||
|
||
Lifecycle State:
|
||
Incident
|
||
```
|
||
|
||
---
|
||
|
||
## 53. Kubernetes Namespace Pod Reader
|
||
|
||
```text
|
||
Subject:
|
||
User or ServiceAccount bound by RoleBinding
|
||
|
||
Organization Relation:
|
||
Customer / ServiceProvider / Vendor depending on identity source
|
||
|
||
Canonical Role:
|
||
Verifier or Operator
|
||
|
||
Capability Profile:
|
||
PodReader
|
||
|
||
Scope:
|
||
Namespace
|
||
Resource: pods
|
||
|
||
Plane:
|
||
Runtime
|
||
|
||
Capabilities:
|
||
View
|
||
ViewCollection
|
||
Observe
|
||
|
||
Exposure Mode:
|
||
Metadata + runtime object details
|
||
|
||
Conditions:
|
||
Kubernetes authentication
|
||
RoleBinding active
|
||
|
||
Lifecycle State:
|
||
Operate / Verify
|
||
```
|
||
|
||
---
|
||
|
||
## 54. Kubernetes CI/CD Deployer
|
||
|
||
```text
|
||
Subject:
|
||
ServiceAccount ci/deployer
|
||
|
||
Subject Type:
|
||
Service / Automation
|
||
|
||
Organization Relation:
|
||
Vendor or Customer
|
||
|
||
Canonical Role:
|
||
Builder or Operator
|
||
|
||
Capability Profile:
|
||
DeploymentDeployer
|
||
|
||
Scope:
|
||
Environment: staging
|
||
Namespace: staging
|
||
Resource: deployments
|
||
|
||
Plane:
|
||
Runtime / Build / Execution
|
||
|
||
Capabilities:
|
||
Deploy
|
||
Create
|
||
EditAny
|
||
|
||
Exposure Mode:
|
||
Runtime metadata
|
||
Possibly configuration plaintext
|
||
|
||
Conditions:
|
||
PipelineBound
|
||
EnvironmentBound
|
||
Logged
|
||
No production scope unless separately assigned
|
||
|
||
Lifecycle State:
|
||
Release / Build / Test
|
||
```
|
||
|
||
---
|
||
|
||
## 55. Kubernetes Workload Creator with Induced Access
|
||
|
||
```text
|
||
Subject:
|
||
Human or ServiceAccount
|
||
|
||
Organization Relation:
|
||
Customer / ServiceProvider / Vendor
|
||
|
||
Canonical Role:
|
||
Builder / Operator / Doer depending on purpose
|
||
|
||
Scope:
|
||
Namespace app-a
|
||
|
||
Plane:
|
||
Runtime / Execution
|
||
|
||
Declared Capability:
|
||
Create workload
|
||
|
||
Derived Capabilities:
|
||
Execute code
|
||
Use mounted ServiceAccount
|
||
Potentially access Secrets, ConfigMaps, volumes
|
||
|
||
Exposure Mode:
|
||
Potentially SecretMaterial / Plaintext / Runtime metadata
|
||
|
||
Access Path:
|
||
Induced Access
|
||
|
||
Finding:
|
||
Declared namespace-scoped runtime permission may result in
|
||
broader effective authority than expected.
|
||
```
|
||
|
||
---
|
||
|
||
# Part VII — Maturity and Evolution
|
||
|
||
---
|
||
|
||
## 56. Standard Maturity Levels
|
||
|
||
CARING may evolve through maturity levels.
|
||
|
||
### Level 0 — Draft Vocabulary
|
||
|
||
Initial terms, examples, and conceptual distinctions.
|
||
|
||
### Level 1 — Release Candidate
|
||
|
||
Stable enough to analyze real systems and collect feedback.
|
||
|
||
### Level 2 — Mapping Standard
|
||
|
||
Includes tested mappings to major control implementations.
|
||
|
||
Examples:
|
||
|
||
```text
|
||
Lotus/Domino ACL
|
||
Kubernetes RBAC
|
||
Git hosting permissions
|
||
Cloud IAM
|
||
Database grants
|
||
Enterprise IAM systems
|
||
Document management systems
|
||
```
|
||
|
||
### Level 3 — Design Standard
|
||
|
||
Includes prescriptive design profiles, templates, and governance patterns.
|
||
|
||
### Level 4 — Verification Standard
|
||
|
||
Includes test cases, conformance checks, policy linting, and machine-readable schemas.
|
||
|
||
### Level 5 — Operational Standard
|
||
|
||
Includes lifecycle review automation, exposure-event workflows, agent policy ceilings, service-account governance, induced-access analysis, and continuous access governance.
|
||
|
||
---
|
||
|
||
## 57. Standard Refinement Process
|
||
|
||
CARING should evolve through concrete analysis challenges.
|
||
|
||
For each analyzed system:
|
||
|
||
```text
|
||
1. Select access-control implementation.
|
||
2. Describe system-native access model.
|
||
3. Map native constructs to CARING dimensions.
|
||
4. Identify successful mappings.
|
||
5. Identify ambiguous mappings.
|
||
6. Identify missing CARING concepts, if any.
|
||
7. Identify implementation shortcomings exposed by CARING.
|
||
8. Identify CARING terminology refinements.
|
||
9. Update standard or mapping guide.
|
||
10. Add findings to benchmark corpus.
|
||
```
|
||
|
||
A proposed refinement should be accepted only if:
|
||
|
||
```text
|
||
1. It cannot be modeled cleanly with existing dimensions.
|
||
2. It appears in more than one access-control context,
|
||
or is fundamental enough to justify inclusion.
|
||
3. It improves analytical clarity without causing role explosion.
|
||
4. It preserves orthogonality.
|
||
5. It avoids overfitting to one implementation.
|
||
```
|
||
|
||
---
|
||
|
||
## 58. Candidate Analysis Benchmarks
|
||
|
||
Initial benchmark candidates:
|
||
|
||
```text
|
||
1. Lotus/Domino ACL
|
||
2. Kubernetes RBAC
|
||
3. GitHub / GitLab repository access
|
||
4. AWS IAM
|
||
5. Azure RBAC / Entra ID
|
||
6. PostgreSQL roles and grants
|
||
7. SharePoint / Microsoft 365 permissions
|
||
8. Jira / Confluence permissions
|
||
9. Salesforce profiles, permission sets, and sharing rules
|
||
10. Keycloak realm/client/resource permissions
|
||
11. Linux users/groups/sudo
|
||
12. CI/CD platform permissions
|
||
13. Support desk access models
|
||
14. Data warehouse access models
|
||
15. Agentic workflow platform permissions
|
||
```
|
||
|
||
Each benchmark should test different stresses:
|
||
|
||
```text
|
||
Document-level access
|
||
Infrastructure access
|
||
Tenant isolation
|
||
Field-level access
|
||
Secrets
|
||
Service accounts
|
||
Agentic delegation
|
||
Community contribution
|
||
Legal exposure
|
||
Runtime operation
|
||
Commercial entitlement
|
||
Cross-tenant analytics
|
||
Induced access
|
||
Policy-plane escalation
|
||
```
|
||
|
||
---
|
||
|
||
# Part VIII — Glossary
|
||
|
||
---
|
||
|
||
## 59. Access Assignment
|
||
|
||
A declared or effective grant of access to a subject.
|
||
|
||
## 60. Access Descriptor
|
||
|
||
A CARING representation of access using core dimensions.
|
||
|
||
## 61. Capability
|
||
|
||
An action the subject may perform.
|
||
|
||
## 62. Capability Profile
|
||
|
||
A named bundle of capabilities.
|
||
|
||
## 63. Canonical Role
|
||
|
||
A lifecycle responsibility posture defined by CARING.
|
||
|
||
## 64. Condition
|
||
|
||
A requirement that must be satisfied for access to be valid.
|
||
|
||
## 65. Declared Access
|
||
|
||
Access explicitly represented by the native access-control system.
|
||
|
||
## 66. Derived Capability
|
||
|
||
A capability that is not directly granted as a named permission, but becomes available as a consequence of another permission.
|
||
|
||
## 67. Direct Access
|
||
|
||
Access where the subject acts directly.
|
||
|
||
## 68. Delegated Access
|
||
|
||
Access where one subject delegates authority to another subject.
|
||
|
||
## 69. Effective Access
|
||
|
||
Access that can actually be achieved through direct, delegated, mediated, derived, or induced execution paths.
|
||
|
||
## 70. Exposure Event
|
||
|
||
A controlled exception or observed irregularity involving information access.
|
||
|
||
## 71. Exposure Mode
|
||
|
||
The degree and form in which information becomes visible, extractable, or usable.
|
||
|
||
## 72. Induced Access
|
||
|
||
Access caused when a subject triggers a component whose actual authority exceeds the subject’s direct authority.
|
||
|
||
## 73. Lifecycle State
|
||
|
||
The current reason or phase for which access exists.
|
||
|
||
## 74. Local Role
|
||
|
||
An application-specific role name not necessarily identical to a CARING canonical role.
|
||
|
||
## 75. Mediated Access
|
||
|
||
Access where a system component acts on behalf of or in response to a subject.
|
||
|
||
## 76. Native Policy Object
|
||
|
||
A system-native construct that expresses permissions, such as a Kubernetes Role, IAM policy, database grant, or ACL entry.
|
||
|
||
## 77. Organization Relation
|
||
|
||
The structural relationship of a subject to the product, platform, tenant, or governance context.
|
||
|
||
## 78. Plane
|
||
|
||
The kind of system layer or access surface being accessed.
|
||
|
||
## 79. Restriction
|
||
|
||
An overriding deny, block, quarantine, or limiting policy effect.
|
||
|
||
## 80. Scope
|
||
|
||
The boundary within which access applies.
|
||
|
||
## 81. SecretMaterial
|
||
|
||
Credentials, keys, tokens, certificates, or other secret values that can enable further access.
|
||
|
||
## 82. Subject
|
||
|
||
The entity to which access is assigned or attributed.
|
||
|
||
## 83. Tenant
|
||
|
||
A structurally isolated customer, organization, business unit, or operating context.
|
||
|
||
---
|
||
|
||
# 84. Compact Definition
|
||
|
||
> **CARING is a canonical access-control vocabulary for information products and runtime platforms. It defines a small set of lifecycle roles and combines them orthogonally with subject type, organization relation, scope, plane, capability, exposure mode, conditions, lifecycle state, restrictions, and exposure events. It distinguishes declared access from effective access and requires analysis of derived and induced capabilities. This allows vendors, service providers, consultants, customers, communities, humans, services, automations, and agents to collaborate safely across the full product lifecycle without collapsing access governance into unmanageable local role sprawl.**
|
||
|
||
---
|
||
|
||
# 85. Core Mental Model
|
||
|
||
```text
|
||
Role describes lifecycle responsibility.
|
||
Organization Relation says under whose authority the subject acts.
|
||
Scope says where the access applies.
|
||
Plane says what layer is accessed.
|
||
Capability says what action is possible.
|
||
Exposure says what information becomes visible or extractable.
|
||
Condition says when access is valid.
|
||
Lifecycle State says why access exists now.
|
||
Restriction says what overrides access.
|
||
Exposure Event says when access becomes exceptional or irregular.
|
||
Declared Access says what the native policy states.
|
||
Effective Access says what can actually be achieved.
|
||
Derived Capability says what becomes possible as a consequence.
|
||
Induced Access says what privileged behavior can be triggered indirectly.
|
||
```
|
||
|
||
This is the core of CARING 0.4.0-RC2.
|