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. 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.

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.<name>.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.

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:

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:

Row filter: ABAC predicate decides whether the row is even visible.
Field filter: per-field marking checks decide which fields render; redaction is the default for failed checks.
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.

Foundations

Ontology

Data Plane

Logic & Reasoning

Models

Action Plane

Security & Governance

Operations

Enterprise

Identity, Access & Safety

15 — Compliance & control layer — identity, access & safety.

15.0 Compliance & Control Layer

15.1 Principal model

15.2 Authentication

15.3 RBAC scopes

15.4 ABAC predicates

15.5 Markings & clearance

15.6 Purpose-tagged access

15.7 Row-level & field-level access

15.8 Break-glass

15.9 Service identity for agents

15.10 Encryption

15.11 Kill Switch

​15 — Compliance & control layer — identity, access & safety.

​15.0 Compliance & Control Layer

​15.1 Principal model

​15.2 Authentication

​15.3 RBAC scopes

​15.4 ABAC predicates

​15.5 Markings & clearance

​15.6 Purpose-tagged access

​15.7 Row-level & field-level access

​15.8 Break-glass

​15.9 Service identity for agents

​15.10 Encryption

​15.11 Kill Switch

15 — Compliance & control layer — identity, access & safety.

15.0 Compliance & Control Layer

15.1 Principal model

15.2 Authentication

15.3 RBAC scopes

15.4 ABAC predicates

15.5 Markings & clearance

15.6 Purpose-tagged access

15.7 Row-level & field-level access

15.8 Break-glass

15.9 Service identity for agents

15.10 Encryption

15.11 Kill Switch