> ## Documentation Index > Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt > Use this file to discover all available pages before exploring further. # Identity, Access & Safety > Compliance & Control Layer: identity, RBAC/ABAC, markings, purpose-tagged access, break-glass, encryption, and the Kill Switch that lets operators stop any AI work at any granularity in seconds. # 15 — Compliance & control layer — identity, access & safety. Identity is the substrate's first invariant: every authenticated request is bound to a principal with a typed identity, a role-set, attribute predicates, and a clearance against data markings. Agents are principals too; they have no ambient authority. Above identity sits the broader **Compliance & Control Layer** — the substrate's cross-cutting safety surface that consolidates Guardrail Rules, PII / Screening checks, an autonomous QA Model, Confidence Scoring, and a Kill Switch. Every Decision and every Action passes through it. ## 15.0 Compliance & Control Layer This section unifies the substrate's safety controls into one named layer. It is not a new component — the controls are spread across the planes — but global CTOs need to see them as a single governance surface, because that is how regulators, auditors, and risk committees evaluate them. ```mermaid theme={null} flowchart TB AG[Agent runtime] --> CTRL ACT[Action plane] --> CTRL RAG[RAG knowledge base] --> CTRL subgraph CTRL [Compliance and control layer] G1[Identity and access §15.1 to 15.10] G2[Guardrail rules §16] G3[PII and screening §15.4 and 15.7] G4[QA model §13.4] G5[Confidence scoring §8.3] G6[Kill switch §15.11] G7[Audit and lineage §17] end CTRL --> SOR[Carrier systems of record] CTRL --> OPS[Operator surfaces] CTRL --> AUD[(Audit chain)] classDef ctrl fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111; classDef ext fill:#fff,stroke:#111,color:#111; class CTRL ctrl; class AG,ACT,RAG,SOR,OPS,AUD ext; ``` *Fig. 15.0 — Compliance & Control Layer. Seven control surfaces govern every request between agents, actions, retrieval, and the carrier's systems and operators.* **Control surfaces** | Control | What it enforces | Specified in | | ---------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------ | | **Identity & access** | Authn, scopes (RBAC), attributes (ABAC), markings, purposes, row / field filters, break-glass. | §15.1–§15.10 | | **Guardrail rules** | Tool-invocation policy decisions (PDP) per call, deny-by-default, fail-closed, cached evaluation. | §16 | | **PII & screening** | Marking propagation, redaction at read, screening of outbound payloads, PHI handling, regulator-list checks. | §15.4, §15.7 | | **QA model** | Independent verifier model that grades a candidate Decision against rule packs and golden examples before it commits. | §11.4, §13.4 | | **Confidence scoring** | Calibrated, per-property and per-Decision confidence; drives auto-approve thresholds and human-review routing. | §8.3, §14.5 | | **Kill switch** | Tenant- and platform-scoped cut-outs that stop runs, agents, models, or tools at any granularity. | §15.11 | | **Audit & lineage** | Hash-chained, append-only audit; Decision and Action lineage; replay bundles; legal-hold pinning. | §17 | The Compliance & Control Layer is **not skippable**. There is no "fast path" that omits it; there is no debug bypass; there is no operator endpoint that commits an Action without traversing it. The layer is the price of admission to the Action Plane. ## 15.1 Principal model Every actor in the system is a typed principal. There are five classes: | Class | Provisioning | Auth method | Audit signature | | ----------------------- | ----------------------------- | ------------------------------------------- | ----------------------------- | | **human.user** | SCIM from corporate IdP | SAML/OIDC + MFA + step-up | per-call principalRef | | **human.reviewer** | SCIM | SAML/OIDC + MFA | per-decision principalRef | | **service.integration** | tenant config | mTLS + signed assertion | per-request principalRef | | **agent** | agent registry (§10) | scoped service-identity, run-bound | runRef + agentRef | | **system.operator** | Layerup-side, tenant-approved | mTLS + step-up + purpose-tagged break-glass | operator span on tenant chain | ## 15.2 Authentication * SSO via SAML 2.0 and OIDC. The platform is itself a relying party; it does not host primary credentials. * Strong MFA required for all human principals. Step-up (re-auth or hardware key) required for sensitive purposes. * SCIM 2.0 for provisioning and de-provisioning. * mTLS for service-to-service traffic; client-cert pinning at the boundary. * Tokens are short-lived; refresh requires presence of original auth context. ## 15.3 RBAC scopes Scopes are the platform's primitive grant. Every tool, object read, action stage, and approval requires one or more scopes. Scope grants are recorded; revocation is itself a typed AuditEvent. ```text theme={null} policy.read claim.read document.read evidence.read policy.write claim.write document.write evidence.write uw.review claim.adjust payment.commit reserve.commit agent.run tool..invoke audit.read ontology.write gov.action.approve gov.action.compensate ``` ## 15.4 ABAC predicates Predicates are evaluated at decision time over (principal, object, environment) attributes. ```text theme={null} principal.region == object.region principal.lineOfBusiness ⊇ object.lineOfBusiness object.marking.allows(principal.clearance) environment.now ∈ principal.workingHours object.amount <= principal.authority.ceiling ``` ## 15.5 Markings & clearance Markings (§4.2) are first-class labels carried by every object. Examples: `pii.medium`, `pii.high`, `regulated.hipaa`, `regulated.gdpr`, `tenant.eu-only`, `commercial-in-confidence`. Each marking has a clearance predicate; a principal must satisfy it to access the marked data. Markings propagate through derivation. A property derived from PII-marked sources is itself PII-marked unless the derivation tool is registered as a de-classifier — and de-classification is its own AuditEvent reviewed by the security plane. ## 15.6 Purpose-tagged access Every tool call and every direct read declares a purpose. The PDP checks the purpose against the marking's allowed-purpose set: ```yaml theme={null} id: marking.regulated.hipaa clearance: [ phi.handler ] allowedPurposes: - claims.adjustment - underwriting.review.health - quality.calibration disallowedPurposes: - marketing.* - analytics.unredacted.* inheritance: union # propagates through derivations declassifier: tool.deidentify.phi.v3 retention: PT0H # do not retain plaintext; redact on read where allowed ``` ## 15.7 Row-level & field-level access RBAC + ABAC + markings combine into row- and field-level filters that are evaluated on every read: 1. **Row filter**: ABAC predicate decides whether the row is even visible. 2. **Field filter**: per-field marking checks decide which fields render; redaction is the default for failed checks. 3. **Read shape**: the resolver returns only the fields the principal is cleared for; missing fields are explicit nulls with a typed redaction reason. ## 15.8 Break-glass For incident response, a step-up break-glass grant is supported. It is purpose-tagged, time-limited, hardware-key-required, and emits a special AuditEvent (`identity.break_glass`) on the tenant chain. The tenant's security primary is notified in real-time. Break-glass cannot grant scopes the tenant has marked irrevocable. ## 15.9 Service identity for agents Agents authenticate as a service identity that is bound to the AgentRun. The identity has only the scopes declared in the agent definition; cross-run reuse is forbidden by construction. Compromise of an agent identity is constrained to the run's wall-clock window. ## 15.10 Encryption * TLS 1.3 for all transport. mTLS at the substrate boundary. * AES-256-GCM at rest. Per-tenant keys; BYOK supported with HSM or KMS integration. * Field-level envelope encryption for high-sensitivity fields; access requires marking clearance even by operators. * Key rotation on schedule and on suspected compromise; rotations are typed AuditEvents. ## 15.11 Kill Switch The Kill Switch is the substrate's emergency cut-out: a tenant- and platform-scoped mechanism to stop AI work at any granularity in seconds, without bringing the rest of the platform down. It is the control a global CTO most often asks about and the one most often missing in pre-platform deployments. **Granularities** | Scope | Effect | Authorisation | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | **Tool** | Disables a specific tool version; in-flight tool calls drain to a typed Exception. Agents using the tool fail closed. | Tenant security or platform on-call. | | **Capability lane** | Suspends a lane in the Model Gateway (e.g. `reasoning.long`); routing falls back to the configured fallback or fails closed. | Tenant security or platform on-call; SoD with Reasoning ops. | | **Model** | Demotes an approved model to `retired`; gateway routes to fallback. Used for live drift incidents or vendor outages. | Tenant security; can be triggered automatically by drift breach (§13). | | **Agent** | Disables a specific agent definition; queued runs drain to handoff; in-flight runs complete or are cancelled per policy. | Tenant operator with `agent.kill` scope. | | **Workflow** | Suspends a workflow domain (e.g. all underwriting agents) tenant-wide. | Tenant security primary; step-up + dual-control. | | **Tenant** | Stops every agent run, every staged Action commit, every model call — for one tenant only. | Tenant security primary, hardware-key + dual-control. | | **Region** | Stops every agent run / Action / model call within one region cell. Used during regional incidents (§19.10). | Platform incident commander, dual-control, with tenant notify. | | **Platform** | Last-resort substrate-wide stop. Reserved for severe incidents; platform-side authorisation only. | Layerup CISO + on-call SVP, dual-control. | **Properties** * **Fast.** Activation propagates to runtime workers within the platform's standard cache fan-out window (single-digit seconds in healthy operation). * **Typed.** Every kill is a typed `governance.kill_switch.engage` AuditEvent with scope, principal, reason, evidence, and ETA. * **Reversible.** Disengagement is a separate AuditEvent (`governance.kill_switch.disengage`) and is gated by the same step-up. * **Containing, not corrupting.** A kill never silently drops in-flight work. Runs drain to handoff with a typed Exception; staged Actions remain staged; data already written is unchanged. Recovery is by re-enable, not by data repair. * **Auto-engageable.** Drift breach (§13) automatically demotes the affected model. PDP can auto-engage tool kills on policy breach. Auto-engagements are typed AuditEvents with their detector identity. * **Cell-bounded.** Tenant- and region-scoped kills do not affect other tenants or other regions. Platform-scope is the only blast radius the carrier should never need to encounter; it exists for correctness, not for use. **Operator surface** The kill switch is exposed to authorised operators through a dedicated console page, with one-click engagement at scope, mandatory reason text, and live blast-radius preview. Behind the UI is a typed contract; the same kill can be issued via the substrate's integration plane to the carrier's existing incident-response tooling. "Can you stop one model in one region right now without taking the platform down?" is a yes-or-no question. On Layerup, the answer is yes, in seconds, via this control, with full audit. That property is what lets a global CTO underwrite running AI agents against production systems of record.