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