Data, DevSecOps, Network, Observability, Information Space
Standards
InfoTechCanonTaggingStandard
InfoTechCanonCaringAccessGovernanceStandard
```
CARING defines a named orthogonal framework for access-governance analysis and design. It composes concepts from Access Control, Organization, Governance, Security, Data, DevSecOps, Network, Observability, Task, and Tagging, but it also owns several distinctive access-governance concepts.
## 0.2 Canonical Name and Namespace
Canonical file name:
```text
InfoTechCanonCaringAccessGovernanceStandard.md
```
Recommended namespace:
```text
itc-caring
```
Recommended repository placement:
```text
info-tech-canon/
standards/
caring/
InfoTechCanonCaringAccessGovernanceStandard.md
agent-brief.md
concepts/
profiles/
mappings/
benchmarks/
examples/
validation/
```
## 0.3 Purpose in the Kernel
CARING provides a rigorous way to analyze and design access governance by separating access into independent dimensions:
```text
Subject
Organization Relation
Canonical Role
Scope
Plane
Capability
Exposure Mode
Condition
Lifecycle State
Restriction
Exposure Event
```
Its strongest kernel contribution is the disciplined separation of local or native access constructs from canonical access-governance meaning.
A native construct named `role` may be a role, a capability profile, a group, a local title, a policy object, a rule bundle, or an access assignment. CARING requires analysis of the actual semantics before mapping.
## 0.4 Imports from Generic Models
CARING imports the following generic model concepts instead of redefining them:
| Remediation, review, redesign, access-review work items | InfoTechCanonTaskModel |
| Classification of descriptors, findings, benchmark cases | InfoTechCanonTaggingStandard |
## 0.5 Concepts Owned by CARING
CARING owns its distinctive analytical dimensions and procedures:
```text
CARINGAccessDescriptor
CARINGCanonicalRole
CARINGOrganizationRelation
CARINGPlane
CARINGCapabilityProfile
CARINGExposureMode
CARINGExposureEvent
CARINGDeclaredAccessMap
CARINGEffectiveAccessMap
CARINGDerivedCapability
CARINGInducedAccess
CARINGRestrictionPrecedence
CARINGAnalysisFitnessTest
CARINGAnalysisProcedure
CARINGRedesignProcedure
CARINGBenchmarkCorpus
```
## 0.6 Boundary Rules
```text
Organization Role != AccessRole != CARINGCanonicalRole
```
- **Organization Role** is a pattern of responsibility, authority, participation, or behavior.
- **AccessRole** is a permission-bearing construct in an authorization model.
- **CARINGCanonicalRole** is a lifecycle responsibility posture used for access-governance analysis.
```text
CARING Plane != InfoTechCanon Domain
```
A CARING Plane is an access surface such as Build, Runtime, Data, Identity, Policy, Secret, or Audit. It may map to InfoTechCanon domains, but it does not replace those domains.
```text
CARING Scope != ResourceScope != Landscape Scope
```
A CARING Scope is an access-governance boundary. It may map to an Access Control resource scope or a Landscape containment boundary, but the mapping must be explicit.
```text
Namespace != Tenant Boundary
```
A namespace may support tenant isolation, but it MUST NOT be treated as a tenant boundary unless the wider effective access model supports that claim.
## 0.7 Relationship to the Access Control Model
The Access Control Model owns the generic authorization primitives:
```text
Subject
Principal
Resource
Action
Permission
Privilege
Entitlement
Grant
AccessRole
AuthorizationRequest
AuthorizationDecision
PolicyEnforcementPoint
AccessReview
```
CARING specializes these into an analysis and design grammar that asks:
```text
Who or what acts?
Under whose authority?
In which lifecycle responsibility posture?
Within which scope?
On which access plane?
With which capabilities?
With what exposure mode?
Under what conditions?
For which lifecycle state?
Subject to which restrictions?
And when does access become exceptional or irregular?
CARING sits between them for access governance. It identifies declared access, effective access, induced access, exposure modes, exposure events, tenant-boundary findings, and privilege-escalation findings. Those outputs should then connect to Governance reviews, Security findings, Access Control remediation, Task work items, and Observability evidence.
This file preserves the substantive CARING 0.4.0-RC2 content while renaming and positioning the standard according to the InfoTechCanon kernel structure.
Future refinement should:
```text
1. Extract each CARING dimension into its own concept page.
2. Create machine-readable schemas for CARING access descriptors.
3. Add mappings to InfoTechCanon Access Control, Governance, Security, Data, DevSecOps, Network, and Observability.
4. Add benchmark cases, starting with Kubernetes RBAC and Lotus/Domino ACL.
5. Add an agent brief for access-analysis tasks.
```
---
# Original CARING Standard Content, Canon-Aligned
## 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.
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.
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.
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 may not 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.
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 |
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 access-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.
