67 KiB
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:
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:
What does this system actually allow, deny, expose, obscure, delegate, induce, or fail to govern?
Outputs may include:
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:
How should access be structured for clarity, safety, speed, collaboration, and governance?
Outputs may include:
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:
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:
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:
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:
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:
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:
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:
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:
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:
Declared capability:
Create workload.
Derived capabilities:
Execute code.
Use mounted secrets.
Use mounted service account.
Access mounted volumes.
Derived capabilities are especially important in:
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:
Human
Group
Organization
Service
Automation
Agent
System
Device
Process
Anonymous
Unknown
9.1 Human
A natural person acting directly.
Examples:
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:
Vendor company
Customer company
Consultancy
Open-source foundation
Regulator
9.4 Service
A non-human technical identity that performs system functions.
Examples:
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:
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:
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:
Identity provider
Cluster controller
Replication system
Managed service
9.8 Device
A hardware or virtual device acting as or constraining a subject.
Examples:
Trusted workstation
Mobile device
Hardware security module
IoT device
9.9 Process
An executing runtime process with attributable behavior.
Examples:
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:
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:
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:
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:
Distributor Coach
Distributor Integrator
Distributor Manager
10.4 Consultant
An entity that helps configure, customize, adopt, extend, or optimize the system.
Examples:
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:
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:
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:
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:
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:
Intent
Scope
Roadmap
Concept
Requirements
Product direction
Vision documents
Not automatically granted:
Production data
Runtime operation
Tenant administration
Customer plaintext
Policy override
Examples:
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:
Source repositories
Development environments
Test data
Build systems
Design documents
Issue context
Generated artifacts
Not automatically granted:
Production operation
Customer plaintext
Policy management
Tenant-wide data access
Secret access
Examples:
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:
Test systems
Logs
Evidence
Requirements
Security findings
Quality reports
Acceptance criteria
Audit records
Common verifier modes:
Quality Verifier
Security Verifier
Compliance Verifier
Acceptance Verifier
Policy Verifier
Not automatically granted:
Unbounded production write access
Customer plaintext
Policy override
Destructive access
Examples:
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:
Issue tracker
Release planning
Change approval
Merge coordination
Documentation
Version history
Support escalation context
Community discussions
Not automatically granted:
Runtime operation
Tenant content
Production secrets
Customer data
Unbounded policy authority
Examples:
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:
Setup
Initial configuration
Environment connection
Identity federation
Data migration
API integration
Tenant onboarding
System handover
Acceptance preparation
Critical characteristic:
Integrator access should usually be temporary.
Default lifecycle:
Pre-production
Onboarding
Migration
Handover
Post-go-live support window
Expiry
Examples:
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:
Runtime status
Deployment state
Logs
Metrics
Alerts
Backup and restore
Job control
Infrastructure control
Incident tooling
Operational dashboards
Not automatically granted:
Business content
Tenant plaintext
Policy grant authority
Customer impersonation
Bulk export
Product modification
Principle:
Operator access is runtime continuity access, not automatic information access.
Examples:
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:
Can shape the system within a defined governance boundary.
Typical access needs:
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:
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:
Operator keeps the system running.
Manager shapes how the system is used.
Distinction from Builder:
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:
Demo spaces
Training material
Support cases
Usage analytics
Configuration advice
Customer context
Documentation
Best practices
Common coach modes:
Promoter
Trainer
Supporter
Consultant
Success Guide
Community Guide
The canonical role remains Coach.
Examples:
Vendor Coach
Distributor Coach
Consultant Coach
Customer Coach
Community Coach
AI Support Agent as Coach
Coach access should often be:
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:
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:
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:
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:
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:
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:
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:
Customer Doer may read Employee Record
but not Salary Field.
21.17 Action
A specific operation.
Example:
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:
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:
Creator
Manager
Maintainer
Verifier
22.2 Build Plane
Source code, artifacts, schemas, tests, pipelines, documentation, models, prompts, agent recipes.
Typical roles:
Builder
Verifier
Maintainer
22.3 Runtime Plane
Deployments, jobs, services, health, incidents, monitoring, scaling, backups, runtime objects.
Typical roles:
Operator
Integrator
Verifier
22.4 Execution Plane
The ability to cause code, jobs, commands, workflows, agents, scripts, or workloads to run.
Typical roles:
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:
Manager
Integrator
Coach
22.6 Data Plane
Business content, documents, records, messages, files, knowledge, operational data.
Typical roles:
Doer
Manager
Coach
Verifier
22.7 Identity Plane
Users, groups, service accounts, agents, federation, authentication, lifecycle, certificates.
Typical roles:
Manager
Integrator
Operator
Verifier
22.8 Policy Plane
Authorization rules, ACLs, approval flows, restrictions, delegation boundaries, role bindings, policy objects.
Typical roles:
Manager
Verifier
Maintainer
22.9 Secret Plane
Keys, credentials, certificates, tokens, encryption material, signing keys, recovery keys.
Typical roles:
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:
Verifier
Operator
Manager
Authority
22.11 Commercial Plane
Contracts, subscriptions, billing, license entitlements, quotas, purchased modules, commercial terms.
Typical roles:
Manager
Coach
Distributor
Vendor
22.12 Community Plane
Issues, pull requests, discussions, public docs, contribution records, extension catalogs, reputation, public roadmap.
Typical roles:
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:
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:
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
Canonical Role:
Doer
Capabilities:
View
Plane:
Data
Exposure:
Plaintext or masked, depending on data policy
24.2 Contributor / Author
Canonical Role:
Doer
Capabilities:
View
Create
EditOwn or EditAssigned
Plane:
Data
24.3 Editor
Canonical Role:
Doer
Capabilities:
View
Create
EditOwn
EditAny
Plane:
Data
24.4 Depositor / Submitter
Canonical Role:
Doer
Capabilities:
Submit
Create
Not granted:
View
Plane:
Data
Exposure:
None or minimal confirmation after submission
24.5 Designer
Canonical Role:
Builder
Capabilities:
Create
EditAny
Configure
Review
Plane:
Build / Configuration
24.6 Runtime Operator
Canonical Role:
Operator
Capabilities:
Operate
Restore
Inspect
Deploy, if authorized
Plane:
Runtime
24.7 Tenant Manager
Canonical Role:
Manager
Capabilities:
Configure
Grant
Revoke
Delegate
Archive
Restore
Scope:
Tenant
24.8 Namespace Manager
Canonical Role:
Manager
Capabilities:
Configure
Grant
Revoke
Bind
Create
EditAny
DeleteAny
Scope:
Namespace
Planes:
Runtime
Configuration
Policy
24.9 Full Manager / Database Manager
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
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:
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:
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:
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:
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:
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:
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:
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:
Consultant Integrator access is valid during Onboard and Integrate.
It does not remain valid during Operate unless explicitly extended.
Agentic development compresses lifecycle loops:
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:
NoAccess
Suspended
Terminated
Quarantined
ScopeExcluded
DataClassRestricted
LegalHold
ExportBlocked
ImpersonationBlocked
CrossTenantBlocked
SecretAccessBlocked
PolicyFrozen
EmergencyLocked
RiskDenied
ExecutionBlocked
WorkloadCreationBlocked
PrivilegeEscalationBlocked
28.1 Restriction Precedence
Recommended precedence:
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:
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:
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:
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:
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:
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:
Principal
Effective actor
Delegator
Tool or agent
Policy ceiling
Execution context
Audit identity
32.1 Agent Access Formula
Effective Agent Access =
Delegated Human/System Authority
∩ Agent Capability Ceiling
∩ Scope Boundary
∩ Exposure Policy
∩ Runtime Conditions
Example:
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
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:
A user opens a document.
33.2 Delegated Access
The subject delegates authority to another subject.
Example:
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:
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:
A user creates a custom resource.
A privileged controller reacts and modifies infrastructure elsewhere.
Another example:
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:
Canonical Role
Capability Profile
Local Role
Local Title
Group
Native Policy Object
34.1 Canonical Role
Lifecycle responsibility posture.
Example:
Builder
Operator
Manager
Doer
34.2 Capability Profile
A named bundle of capabilities.
Example:
Reader
Editor
RuntimeOperator
DatabaseManager
ClusterAdmin
34.3 Local Role
An application-specific or system-specific role.
Example:
[Approver]
FinanceReviewer
ProjectLead
NamespaceAdmin
34.4 Local Title
Human-readable organizational title.
Example:
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:
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:
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:
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:
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:
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:
Under whose authority does the subject act?
Vendor?
ServiceProvider?
Distributor?
Consultant?
Customer?
Community?
Authority?
Unknown?
Step 3: Map Native Roles and Policy Objects
Questions:
Is the native role a canonical role, capability profile,
local title, group, policy object, or access assignment?
Step 4: Map to Canonical Roles
Questions:
Is this subject creating, building, verifying, maintaining,
integrating, operating, managing, coaching, or doing?
Step 5: Identify Scope
Questions:
Where does the access apply?
Platform?
Cluster?
Environment?
Tenant?
Namespace?
Workspace?
Project?
Process?
Dataset?
Resource?
Subresource?
Record?
Field?
Action?
Step 6: Identify Plane
Questions:
What kind of thing is accessed?
Intent?
Build?
Runtime?
Execution?
Configuration?
Data?
Identity?
Policy?
Secret?
Audit?
Commercial?
Community?
Step 7: Extract Declared Capabilities
Questions:
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:
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:
What information becomes visible?
None?
Metadata?
Masked?
Aggregated?
Synthetic?
Pseudonymous?
Encrypted?
Plaintext?
SecretMaterial?
Exportable?
Cross-tenant aggregate?
Step 10: Identify Conditions
Questions:
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:
Why does this access exist now?
Design?
Build?
Test?
Onboard?
Operate?
Support?
Incident?
Legal?
Terminate?
Step 12: Identify Restrictions
Questions:
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:
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:
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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:
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:
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:
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:
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
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.