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