Insider-Resistant System Design: UEBA, Autonomous Response, and Verifiable Audit

seeded

Chapter 01 ended on an uncomfortable truth: the patient authorized insider, acting within their own scope from a real browser, defeats every probabilistic control, and only three things contain them — scope, accountability, revocation. This chapter takes that ceiling as its starting point and goes deeper. It is the field's account of the systems you build around the deterministic floor when the adversary is already inside: behavioral analytics (UEBA), capability-based object references, data-centric defense (DLPwatermarkingtraitor-tracing), anti-instrumentation signal, automated response (SOAR) with a human in the loop, tamper-evident audit, insider-access governance, and the discipline of measuring detection coverage. Throughout, one honesty is repeated until it is reflex: none of this is a gate on the authorized insider — it shortens detection latency, raises cost, and produces evidence. It is deliberately vendor-agnostic; real mechanisms (Isolation Forest, DeepLog, Tardos codes, Merkle trees, DPoP, CAEP, MITRE ATT&CK) are named as examples of a class. Where the Koder Stack makes a concrete composition decision, that lives in engineering canon (stack-RFC-036, 19 controls C1–C19; stack-RFC-037, UEBA + SOAR + verifiable audit), which cites this chapter.

1. The problem this chapter inherits

The previous chapter established that the user interface is not a security boundary, that hiding the request shape is not a defense, and that the root fix is server-side object-level authorization plus invariant validation — a deterministic floor that decides scope from the authenticated identity, never from a client-supplied id, filter, or flag. It also named the threat model that organizes everything here: the authorized adversary. Concretely, a current or recently-departed operator — the "ex-contractor" — who already holds a valid credential and knows the API, and who abuses it through a small, well-understood set of vectors:

V1 — IDOR / URL-crafting. Supplying or incrementing an object id to reach records the
identity should not see. Two distinct sub-problems hide here: enumeration (a guessable id-space) and authorization failure (the server honoring a reference without checking scope). They have different fixes; conflating them is a common error.
V2 — Copy-as-cURL session replay. Capturing a valid request, token and all, and
re-issuing it from another machine or repeatedly within the token's validity window.
V3 — Batch exfiltration. Issuing a legitimate read hundreds or thousands of times to
drain data — each call individually valid, the aggregate an abuse.
V4 — Flow-step skipping. Calling the final consequential endpoint directly, skipping the
consentvalidationreview steps the UI enforces between screens.
V5 — Direct machine-to-machine (M2M). Talking to the API with no browser at all. The
acid test: every client-side defense is simply absent here.
V6 — DevTools / in-UI reconnaissance. Using developer tools, CDP, a webdriver, or RPA to
map the surface and craft the other vectors.
V7 — Anti-forensic tampering. Editing or deleting the audit trail to erase the evidence
of any of the above — the meta-vector that attacks accountability itself.

The chapter's spine is the three-legged containment of the authorized insider, and the honest partition of every technique against it:

Scope — least-privilege, object-level authorization (RLS), and volume caps decide what
the identity can touch and how much, even inside their role. This is the only thing that prevents.
Accountability — a tamper-evident audit trail and alerting make abuse *detectable and
attributable*, turning silent misuse into an investigable, provable event.
Revocation — instantly disabling the certificate, passkey, refresh token, or device key
of a departed operator closes the ex-insider window.

Everything else in this chapter — UEBA, SOAR, watermarking, capability-URLs, anti-instrumentation — is defense in depth on top of those three legs. Each earns its place by shortening the time between abuse and detection, raising the cost of the fast/scripted variants, or producing evidence. None of them is the wall. Saying otherwise is the specific dishonesty this field must refuse.

2. Scope vs. accountability vs. revocation — the organizing frame

It is worth being precise about why these three, and only these three, contain the authorized insider, because the precision dictates where every later technique may and may not be sold.

Scope is the sole preventive leg. Object-level authorization enforced in the data layer (row/object-level security) means a query for a record the identity may not see returns nothing — regardless of what URL, id, or capability the client presented. Volume and rate caps bound the quantity even of in-scope access. Crucially, scope is a deterministic property: given the authenticated subject and the object, the answer is a fixed yes/no, fully explainable to an auditor. This is why scope can be a gate and a probabilistic score can never be.

Accountability is detective and attributive, never preventive. A verifiable audit log does not stop the insider from reading what they are authorized to read; it makes the reading a record that cannot be silently erased, so the abuse becomes provable after the fact. Its value is entirely conditional on two things the audit log itself cannot guarantee: that the event was actually emitted (completeness) and that someone will look (an operational, not cryptographic, property). Section 9 treats both honestly.

Revocation addresses only the time dimension of the ex-insider: it shrinks the window in which a departed operator's still-live credential works. Its effectiveness is bounded by the slowest link in the credential's lifetime — a self-contained access token with a fifteen- minute TTL is not revocable mid-life without per-request introspection, so "revoke" in practice means *revoke the refresh path and the certificates, and rely on a short TTL for the access token*. This is a real, declared gap, not a solved problem (Section 10).

The frame yields a blunt architectural priority: *invest first in the deterministic floor and in fast revocation; treat every analytic, watermark, and response automation as observability and friction on top.* The rest of the chapter is organized as a tour of that "on top" — each technique introduced as the field understands it, grounded in how industry and academia actually build it, and closed with what it does not do.

3. UEBA — User and Entity Behavior Analytics

User and Entity Behavior Analytics is the discipline of building a statistical model of "normal" for each actor and entity, then scoring live activity against it to surface anomalies. In the insider context its job is narrow and honest: *shorten detection latency for the fast, scripted, or out-of-pattern variants of abuse, and produce explainable evidence* — never to gate access, which remains the deterministic floor's job. The Koder instantiation is a self-hosted engine (stack-RFC-037's UEBA arm, in services/ai/ueba), but the concepts below are the field's.

3.1 Peer-group baselining vs. self-baselining

The foundational idea, shared by every serious UEBA product (Splunk UBA, Securonix, Exabeam, Microsoft Sentinel UEBA), is that "normal" is defined relative to a comparison population. Two baselines matter:

Self-baseline — the actor compared to their own history ("this operator never exported
before midnight until today").
Peer-group baseline — the actor compared to others in the same role or unit ("nurses at
this clinic touch ~40 records a shift; this one touched 4,000").

The critical design choice is how the peer group is formed. The tempting approach is to learn clusters from behavior. The auditable approach — and the one a public-sector deployment must prefer — is to derive the peer group from declared, authoritative metadata: role, unit, site, from the identity system. A derived group is explainable ("this baseline is the median of the 23 operators with rolenurse at siteUBS-Centro") and it solves cold-start (a brand-new operator inherits their peer group's baseline on day one). A learned cluster is a black box that an auditor cannot interrogate and that shifts under the adversary's own influence. The Koder engine derives peer membership from identity metadata for exactly this reason.

Peer statistics are computed robustly — median and median absolute deviation (MAD) rather than mean and standard deviation, because a handful of extreme insiders would otherwise poison the very baseline meant to catch them. The canonical robust anomaly score is the modified z-score z = 0.6745·(x − median)/MAD, whose attribution is exact: the score points at the specific feature that crossed the threshold.

3.2 The explainability requirement is a hard constraint

For a government audit, "the model flagged it" is not an acceptable reason. Any control that can trigger a consequence must be able to *enumerate its reasons in terms a human auditor can check*. This splits the model zoo into two tiers:

Deterministic / exactly-attributable — robust z-score, Markov/n-gram transition surprise,
Exact Data Match. These can be a trigger for automated response because the reason is the exact feature or transition that fired.
Approximately-attributable — Isolation Forest, autoencoders, sequence LSTMs. These are
powerful anomaly detectors but their attribution (via Local-DIFFI [Carletti et al., 2019], KernelSHAP, or attention weights) is a declared approximation, labeled as such, never sold as causal truth.

The hard rule, and the one that keeps "no opaque ML deciding a government action" true: an irreversible automated response, or one that restricts a person, requires either the exact reasons of a deterministic model or a human in the loop. The approximate models may prioritize and alert; they may never be the sole trigger of irreversible action. This is precisely the line the industry's better products draw — Exabeam's "Smart Timelines" are scored by enumerable reasons for exactly this reason; Google Chronicle is *rules-first, ML-augment* (YARA-L). Darktrace is the field's cautionary counter-example: excellent peer-group mathematics wrapped in opacity that a public auditor cannot accept. The mature posture takes the mathematics and refuses the opacity.

3.3 The ensemble: simple to complex, fused transparently

A robust engine runs several detectors in different feature spaces and fuses them additively or by weighted-max, never as an opaque product. A representative ladder:

M0/M1 — robust z-score per peer group (deterministic). The workhorse; exactly
attributable; the only member permitted to contribute to a hard gate (and even then only via caps, not the score itself).
M2 — unsupervised multivariate — Isolation Forest (score = normalized inverse path length)
or an autoencoder (reconstruction error, per-feature residual = attribution). Catches multi-feature anomalies no single threshold would.
M3 — sequence models — a count-based Markov/n-gram transition surprise
−log P(aₜ | aₜ₋ₖ…aₜ₋₁) (deterministic, points at the improbable transition = a skipped step), and optionally a DeepLog-style LSTM [Du et al., CCS 2017] that flags when the observed action falls outside the top-g predicted next actions.

Each member emits a named, signed sub-verdict with its top-N contributing features. Model disagreement is itself a logged signal, never a silent veto. Fusion by weighted-max is high- sensitivity, which is acceptable only because the posture is log-before-block — the ensemble raises alerts and, at most, reversible friction; it never auto-denies.

3.4 Feature families are the threat model made measurable

The features are chosen to discriminate the specific vectors:

Volume / velocity (V3 exfiltration) — counts and rates over rolling windows.
Object dispersion / id entropy / sequential-walk ratio (V1 IDOR/URL-crafting) — a spike in
distinct objects touched, or a suspiciously sequential walk through an id-space.
UI-fraction vs. direct-API + client-integrity attestation presence (V5 M2M, V2 replay) —
a signal that raises the cost of the scripted channel. This attestation runs on the adversary's hardware and is forgeable; its absence is never ground truth. Replay and M2M are contained by scope (RLS) and audit, not by attestation.
Inter-request-interval coefficient of variation (robotic cadence), out-of-shift hour.
UA↔JA4 divergence, geo-velocity, device churn — network-origin signals (Section 4).
Transition surprise over action n-grams + step completeness (V4). Note the division of
labor: enforcing a mandatory step is the state-machine guard's job (a structural, deterministic control); UEBA here only detects the deviation, it does not enforce.

3.5 Cold-start and the small-cohort trap

Two distinct sparse-data problems, with distinct fixes:

Cold-start — too little history for an individual. The fix is a hierarchical fallback
individual → peer → population → absolute cap, with empirical-Bayes shrinkage pulling the sparse individual statistic toward the peer prior with weight w = n/(n+k). Below a minimum number of sessions, the actor is log-only with an absolute cap. You never infer "normal" from an empty sample.
Small-cohort privacy — a peer group so small that its baseline leaks the individual.
The fix is a k-anonymity floor: a peer statistic is published/used only above a minimum group size n; below it, the baseline escalates to the population tier. This is a privacy fix, not an accuracy fix, and it is distinct from shrinkage.

3.6 Reproducibility as an invariant

For evidence to be admissible, a verdict must be reproducible: model version + a *versioned snapshot of the peer statistics* (with the differential-privacy noise materialized, not re-sampled) + the feature snapshot + a hash of the input must let an auditor re-run the scoring and obtain the same score. The subtlety that catches naive implementations: if the DP noise in the baseline is regenerated at replay time, the replay diverges and reproducibility is false. The noise must be persisted. The Koder engine records, per verdict, the feature vector hash, ensemble version, the peer-stat snapshot version, and the attributions, under the tamper-evident store of Section 9.

3.7 Privacy-preserving and adversarially-robust by construction

Two properties the field increasingly treats as non-optional (Section 12 goes deeper):

Privacy — client-integrity sub-scores are computed on the edge/device; only the result
ascends, never the raw behavioral stream. Baselines use per-tenant keyed pseudonymization (HMAC, which under data-protection law is pseudonymization, not anonymization — still personal data) and differential privacy (Laplace/Gaussian noise, epsilon budget accounted per tenant, per the U.S. Census 2020 TopDown precedent) on the population aggregates. No telemetry metric ever carries the pseudonym, a feature value, or an attribution — PII stays out of the observability plane.
Robustness — a heterogeneous ensemble (evading one member does not transfer), features
anchored to the non-forgeable floor (behavior cannot falsify scope), a drift monitor (PSI / KS / Jensen-Shannon) that demotes a drifted model to log-only until human re-validation, and the discipline of log before block. Features that look server-side-expensive to forge (JA4, UA↔JA4 divergence) are costly, not impossible, to forge — uTLS-class tooling defeats lazy spoofing but not a competent adversary who aligns UA and JA4. The honest value is *raised cost, plus the deterministic floor sitting *outside the reach of behavioral manipulation.

3.8 Industrial grounding and honest limits

The design choices are not invented: peer-group + additive risk is the Splunk UBA / Securonix model; reproducible score-by-declared-reasons is Exabeam's; per-principal API-usage baselining is the AWS GuardDuty/CloudTrail logic (adopted without the data egress); call-sequence modeling is Cloudflare API Shield; rules-first-ML-augment is Chronicle's YARA-L.

The limits, stated plainly: the authorized, slow, in-scope insider is not gated by UEBA — scope + audit + revocation contain them; UEBA only shortens detection latency and raises the cost of the fastscripted variants. Peer-group quality depends on clean role metadata. M2M3 attribution is approximate. An adversary who knows the model can mimic normal behavior. DP protects the individual but blinds small cohorts (hence the k-anonymity floor and population tier). And purpose-limitation — that this never becomes employee-productivity surveillance — is a governance guarantee, not a mathematical one.

4. Network origin as a feature: reputation and impossible-travel

A cheap, passive, client-independent signal is where the request came from. Because it does not depend on the client executing anything, it is one of the few signals present on the cURL/M2M channel (V5) where CAPTCHAs and bot-scores are simply absent. It is *signal, never a gate* — municipal NAT alone forbids hard IP blocking.

4.1 A self-hosted reputation and geolocation feed

The sovereignty-and-privacy invariant is absolute: *no request-time lookup ever touches an external service*. Every source — open or licensed — enters *exclusively as a downloaded snapshot file* refreshed on a schedule, never as a per-request API call. The citizen's or operator's IP never leaves the perimeter. A self-hosted feed (infra/net/krep in the Koder instantiation) periodically imports open sources — Tor exit lists, Spamhaus DROP/EDROP, FireHOL Level 1, Team Cymru IP→ASN, PeeringDB (ASN network type), a MaxMind GeoLite2 City+ASN mirror — each write producing a versioned snapshot (rollback) plus a freshness metric with an SLA alert. Licensed adapters (the only sources that can label a residential proxy) are optional, behind a capability flag, and ingested as a downloaded data file on the same snapshot path, never as a live SaaS lookup. This is the general pattern for any self-hosted defense that must import external data: refresh periodically by design, never egress per request.

4.2 Algorithms

Origin resolution — longest-prefix match in an in-memory radix trie built *from the local
snapshot*, hot-reloaded on a version bump. Zero network on the hot path.
Classification — ASN → class (datacenter / cloud / VPN / Tor / residential-proxy /
residential / mobile-CGNAT / gov-known / unknown) via PeeringDB network type and hosting lists; Tor is an exact exit-IP set; VPN and residential-proxy only from an ingested licensed feed (else unknown — no guessing).
Geo-velocity (impossible travel) — haversine(current, last-seen)Δt → implied kmh. Emit
impossible_travel only when: velocity exceeds a threshold (≈900 km/h) and the accuracy radius is smaller than the distance at both points and it is not the same ASN or a mobile handoff and both are not in the tenant's known-egress allowlist. With no history, it never emits — you do not infer "normal" from an empty sample.

The tenant's known-egress allowlist (the town hall's own CIDRs/ASNs) is what converts a noisy IP into a per-tenant baseline.

4.3 What it bites, and the hard honest limit

It bites session replay from a different machine (V2) — *but only when the origin actually changes*: a replay from a datacenter or VPN shifts the origin class and can trip impossible-travel; a replay run from the same municipal network (the on-site insider) changes nothing and trips nothing. It bites cloud-hosted automation (V3). Being client-independent, it covers the cURL/M2M channel (V5).

The limits are severe and must be stated: *municipal NAT/CGNAT erases the IP as an intra-tenant discriminator* — the real discriminator is the pair (account × atypical origin), not the IP alone. IP geolocation is coarse (city-level ~55–80%); legitimate CGNAT/VPN produce false impossible-travel. A residential proxy is nearly undetectable (only with a licensed feed, and still evadable by rotating exits inside the target city). Tor is high-signal but trivially avoided. It *does not contain the insider operating from the town hall's legitimate IP with a valid credential* — that is contained only by scope + accountability + revocation. Nothing here is secret; an informed adversary evades by staying in-region on residential egress. It enters the score as accountable telemetry, never as a barrier. (ATT&CK: T1078, T1090.002/.003, T1583.003T1584, T1550.004, T1020T1119/T1567.)

5. Data-centric defense: DLP, watermarking, and traitor-tracing

Every control so far tries to constrain access. But the defining property of the authorized insider is that their access is legitimate — they are entitled to see the patient record they then exfiltrate. Against that actor the axis must shift from "prevent the access" to *"hold the leak accountable". This is *data-centric defense: it marks, traces, and raises the cost of exfiltration. It is detective / deterrent / attributive — never a gate (with one narrow exception below). It corresponds to control C17 in the Koder canon.

5.1 Three layers, visible to forensic

Visible tiled overlay — a semi-transparent watermark (operator name, a short trace-id code,
a timestamp) composited server-side into the pixel buffer the operator sees. It deters photograph-of-screen and is captured in a full-frame screenshot. It has no DOM element to remove in DevTools because the pixel is the server's — a structural leverage of a *server-side- rendered, DOM-less UI* (the Koder Kroma surface). It can still be cropped away from the data region, so it is a deterrent, not a guarantee.
Robust invisible watermark (rasterized artifacts only) — an opaque token (never raw PII)
embedded in pixel artifacts (PNG, PDF-raster) via spread-spectrum in the DCT domain + error-correcting codes (Reed-Solomon/BCH) + tiled repetition, so a crop of ≥1 tile still decodes. A maturation path uses a trained encoder (HiDDeN/StegaStamp class) for print→photo robustness. The honest boundary: structured exports (xlsxCSVJSON) carry no pixel watermark — they are already "re-typeable" data that any re-sort normalizes — so those are covered only by the canary + Exact Data Match + audit layers, never advertised as marked.
Per-operator canary / traitor-tracing — the token is drawn from a *Tardos fingerprinting
code* [Tardos, 2003] per (tenant, operator, epoch), collusion-resistant up to c traitors: a document colluded from several copies still accuses at least one contributor within the designed bound. This is the only layer that survives an insider who re-types or paraphrases the data (no pixel survives that) — and even then only when the channel carries enough entropy (Section 5.4).

5.2 Canary safety in a healthcare system

Injecting a fake patient into a health system is dangerous — it can become a real appointment or prescription. Preference order: (a) the artifact watermark; (b) *clinically-inert variants of true data* (record ordering, spacing, non-clinical metadata) — *only if proven inert per-dataset by construction, never assumed*, because record order can carry clinical meaning (chronology, priority) and is fragile (any downstream ORDER BY/re-export normalizes it); (c) a small ring of synthetic patients marked by construction, admitted only if billing, dispensing, and care reject the flag by design. A canary is never dispensable or billable.

5.3 Content-aware DLP, kept explainable

Data-loss-prevention inspects two egress points (the export path and the edge). It stays deterministic and explainable: Brazilian info-type detectors (CPF, CNS/SUS-card, RG, CEP, check-digit-validated phone) plus Exact Data Match — a fingerprint using a *secret, rotatable, sealed key HMAC* (not a plain salt: CPF/CNS are small, checksum-enumerable spaces, and a leaked salt would make the index reversible) over the tenant's known patient-id set. A match reads "this export contains 143 records matching known ids" — explainable, *without copying PII in clear. A free-text clinical classifier may run, but *advisory / log-only — it never triggers a BLOCK (the government explainability requirement), and because its output is an inference over a citizen's health content it lives *only in the per-tenant audit plane, never in an observability metric. The inherited rule: *log before block; block only on a high-confidence deterministic rule (a batch over the cap) — the single preventive edge this whole layer has, and it does nothing to the slow, sub-cap, in-scope insider.

5.4 The robustness envelope, stated honestly

Survives: screenshot, JPEG q≳50, crop to ≥1 tile, moderate scale/rotation. Degrades: sub-tile crop, aggressive downscale, low-resolution print→photo, adversarial filtering. Re-typing / re-sorting destroys every pixel and layout/order channel. Collusion beyond c: Tardos attribution degrades — declare the bound, do not sell past it. *Small tenant / low- capacity channel*: few operators, or a low-entropy clinically-inert channel, cannot carry a Tardos codeword of the required length O(c² log(N/ε)), so attribution weakens or c exceeds the operator population — declare when the scheme does not apply. The visible overlay is the fallback when the invisible mark fails; the canary is the only survivor of re-typing, and only with entropy.

5.5 Honest limits and the Kerckhoffs discipline

Detectivedeterrentattributive, not preventive (except the batch-over-cap block, which does
nothing against the slow sub-cap exfil). It marks and traces; it is not a gate.
M2M/API (V5) does not render through the UI → no pixel; only DLP-egress + canary + audit
cover it.
OCR of the server pixels extracts the data — "no DOM" removes the cheap copy path, not the
extraction.
*A watermark/Tardos accusation is an investigative lead with a confidence, never proof by
itself* — the imputation comes from the tamper-evident audit (Section 9). Never sell a probabilistic decoder as a gate or as sole proof.
Obscurity is not security (Kerckhoffs): the scheme is public; robustness comes from ECC +
redundancy + the collusion code + the deterministic audit backbone — not from hiding the algorithm. The HMAC-EDM key is the only secret, and its loss only makes the index reversible, not the rest.
A false positive in DLP over a legitimate clinical export can harm patient care → block
conservatively. (Primary vector V3; ATT&CK T1567, T1020, T1119, T1213, T1030, T1005; photo-of- screen approximates T1052, touched only by overlay + canary.)

6. Capability-URLs and moving-target object references

A capability-URL is an object reference that carries its own authority: an unguessable, cryptographically-protected handle instead of a sequential id. Done correctly it *eliminates enumeration at the root* — but understanding its exact scope is essential, because it is routinely oversold as an authorization mechanism, which it is not. This is control C18.

The reiterated hard rule: the capability is never the authority. The server *resolves and re-validates scope (RLS)* on every use. This is not security by obscurity: the token format is open and offline-verifiable; the strength comes from an Ed25519 signature and an AEAD key (held in a KMS), not from hiding the scheme.

6.1 A representative format

Build on a signed-token format with no algorithm-confusion (e.g., PASETO v4.public, Ed25519). Claims: sub = per-tenant HMAC of the account id (pseudonym, no PII); obj = a blind handle AEAD(key_epoch, tenant‖type‖id, aad=sub); act (permitted actions); a short exp; a jti (unique id); and a cnf confirmation binding the token to the presenter's mTLS certificate thumbprint or DPoP key.

6.2 Why it kills enumeration — and what it does not kill

No sequential id ever leaves the server, so there is no space to increment. The handle is a stateless AEAD ciphertext (the server decrypts it; there is no handle→id table to steal) and it is subject-bound (aad=sub, so a handle stolen by a different principal fails the authentication tag). The moving-target property is key-epoch rotation: an epoch-N handle becomes cryptographically undecryptable once key N expires (keeping K epochs live to honor the max TTL) — the captured link dies by construction, not merely "by policy". Honest marginal gain: because the K live epochs cover the max TTL, this cryptographic death is a backstop to the exp check, not an independent shortening of the window.

The verb-scope caveat is the crux: this kills enumeration (the id-space). It does not kill IDOR-as-authorization-failure. A valid, leaked, or shared capability that resolves to an out-of-scope object is stopped only by scope (RLS). If the backend trusts the capability without re-validating scope, a leak is an IDOR. This is limit (a) below, and it is the single most important thing to understand about the technique.

6.3 Resolution flow and single-use

(1) The client sends the capability in a POST/header, never a GET query (which leaks via logs and Referer). (2) The edge does the structural gate (signatureexpcnf/rate) without touching the origin. (3) The SDK decrypts the handle, checks sub against the *authenticated principal of this request*, consumes the jti if single-use, and *re-validates scope by running the query under RLS* — RLS denies ⇒ deny, ignore what the capability says. (4) A verifiable audit event records jti + object id + decision + trace id.

Single-use is an atomic insert-if-absent into a cap_nonce_consumed(jti, …) table with a UNIQUE index — but this is only correct if the insert is linearizable. In a multi-region store, a replay against a stale replica before replication can pierce single-use; guarantee a linearizable insert or declare the window explicitly.

6.4 Honest limits

(a) It is not authorization — trusting the capability without re-validating scope turns a leak into IDOR. (b) Useless against the insider inside their own scope — they mint a legitimate capability; containment is only scope + audit + revocation. (c) The edge sees the capability to validate it, so a compromised edge or mis-scoped log leaks it — mitigated by secret-class redaction + short TTL + single-use + cnf. cnf is optional per API; a capability without cnf is a pure bearer token, live until its TTL — hence cnf is mandatory for single-useexportsensitive capabilities, so a leak is inert without the certificate or DPoP key. (d) Web transport depends on the browser honoring Referrer-Policy. (e) Single-use requires an idempotency key to avoid punishing a legitimate retry; short TTL requires clock sync. It eliminates the enumeration of V1 and (with cnf+TTL+single-use) limits V2/V5; it does not eliminate IDOR-as-authz-failure — see (a). Synergy with a DOM-less UI: no id or schema ever reaches the client, closing DevTools recon (V6) for object ids.

7. Anti-instrumentation as a signal (never a gate)

DevTools, the Chrome DevTools Protocol, webdrivers, and RPA frameworks are the tooling of in-UI reconnaissance (V6) — today largely invisible to the defender. The purpose of a client-integrity collector is to make that reconnaissance visible as telemetry, raising the user-risk score and firing an alert. It is strictly a signal, never a gate. It does not bite the authorized insider; only scope + audit + revocation contain them. This is control C19.

7.1 The collector and its reason-codes

A collector (in the web/WASM client) emits a report with deterministic reason-codes (no opaque ML), each a low-trust bit:

DEVTOOLS_OPEN — a debugger-timing trap, a getter on console, a viewport-dimension delta.
CDP_DETECTED / WEBDRIVER / HEADLESS_ENV — a Runtime.enable leak via an Error.stack
getter, navigator.webdriver, $cdc_ artifacts, WebGL SwiftShader/llvmpipe, headless UA.
NATIVE_FN_TAMPERED — a Function.prototype.toString native-code check on fetch/XHR.
High false-positive (legitimate extensions — ad-blockers, password managers, accessibility tools — monkeypatch): low weight, requires corroboration, never fires alone.
NONHUMAN_CADENCE — timing entropy of input (catches RPA in a real browser). *Only the
reason-code is emitted; the raw timing series never leaves the client and is never stored* — it is behavioral biometrics and re-identifies (Section 7.4).
EXEC_PROOF_ABSENT — a signed WASM attester of the official client did not complete a
challenge-response. Scored only on the official surface where the proof is guaranteed; on generic web, absence means an old browser / blocked WASM / CSP, so it is not scored — absence of a signal is never security.

7.2 The trust-asymmetry golden rule

The report is attacker-controlled data; it enters as low-trust. Only self-incriminating signals carry weight (the attacker does not report their own open DevTools; the curious operator does), and only when corroborated server-side — the edge stamps JA4TLS, IPASN/geo, origin. *The magnitude of the score comes from that server-side truth, never from a client-asserted number.* A confidence field asserted by the client does not exist in scoring; a session HMAC merely ties the report to the session (anti-replay), it does not raise trust because the key is on the client. "The client says: no DevTools" is worth zero.

7.3 It never blocks; and it is absent on the API channel by design

The maximum reach is an alert plus reversible SOAR rungs R0–R2 (Section 8). Blocking DevTools is hostile and useless — it is not done. On the M2M/cURL channel the collector does not even load; its absence is expected, not suspicious. There, the defense is scope + possession binding + capability-URLs, not this signal.

7.4 Honest limits and mandatory transparency

Trivially evadable (do not open DevTools; use undetected-chromedriver/nodriver; or talk straight to the API) — an admitted cat-and-mouse where specific tricks expire. *Blind on the M2M channel* (the insider's honest path). Does not bite the authorized insider in a real browser at human pace — here it is early-warning/deterrence, not a barrier. exec-proof proves execution, not a human (RPA in the official client passes). NATIVE_FN_TAMPERED/WEBDRIVER have legitimate false positives (extensions, sanctioned data RPA) → hence R0–R2, never a gate. On the LGPD side: input cadence is behavioral biometrics — *sensitive data that re-identifies even under a pseudonym* — so it is computed edge-side, raw timing is never transmitted or stored, the purpose is security-only (never productivity profiling), retention is bounded, and *transparency is mandatory (Arts. 6 & 38)*: the operator is informed that client-integrity monitoring exists and its security purpose, with a documented data-protection impact assessment. The detection heuristics may stay secret (that is security, not a data-subject right); the existence of the monitoring may not (covert employee surveillance would be unlawful). Soft deterrence is *not sold as protection — obscurity is not security*.

8. Autonomous response: SOAR with a human in the loop

Detection without response is a report nobody reads in time. *Security Orchestration, Automation and Response* (SOAR) turns a verdict into an action under a propose → execute → prove model. The Koder instantiation lives in infra/observe, acts via per-tenant capability-scoped adapters into the edge / identity / data layers, and reports back into the tenant alerting pipeline. It inherits log before block.

8.1 The reversible-first ladder

The central industrial principle: *reversible actions automatically, irreversible actions with a human*. Cloudflare and Akamai do not "block" — they climb a cheap, reversible rung (challengetarpitdelay) before hard denial; AWS wires finding → EventBridge → runbook with a human-approval state before anything destructive; CAEP/SSF (Continuous Access Evaluation Profile) propagates a revocation in seconds rather than at token expiry. A representative ladder:

Rung	Action	Gate	Reversal
R0	log + alert	auto	—
R1	session throttle	auto	auto-lift on TTL
R2	forced step-up re-auth	auto	reversible
R3	session quarantine (+ CAEP signal to all resource servers)	auto + notify subject	auto-lift on TTL
R4	credential suspension	HITL by default; auto only with explicit tenant opt-in AND outside an active care encounter → then post-hoc review with SLA	reversible
R5	certificate / passkey revocation (CRL/OCSP push)	HITL pre-action, two-person, step-up	non-trivial

Dead-man / auto-lift: every reversible action expires on its own unless the case is renewed — there is never a silent permanent penalty.

8.2 Human-in-the-loop, LGPD Art. 20, and the care-safety interlock

Rungs that restrict an identifiable person (R3 quarantine, R4 suspension) are *automated decisions that affect the data subject* under LGPD Art. 20 → the subject is notified and has a *right to human review. Reversibility + auto-lift + review *are the Art. 20 safeguard, not an optional extra. The irreversible rungs (R5, and R4 by default) only propose: they assemble a dossier (explainable verdict + trail) and create an approval task with N-of-M sign-off, an SLA timer, and the approval itself step-up-authenticated and audited. If the SLA expires with no approval, the default is safe — hold the current reversible rung, never auto-escalate to the irreversible. Disabling a healthcare operator without a human is a denial-of-service vector via false positive — unacceptable by default.

The care-safety interlock is the sharpest domain-specific rule: with an *active patient encounter*, never auto-R4/R5 — and because a quarantine (R3) *mid-consultation already disrupts care, the interlock degrades to *R2 + alert (non-disruptive step-up); R3-or-above only post-encounter or via HITL. Playbooks are per-tenant, versioned (WORM), edited under two-person control, and dry-run simulable against replayed trails (Section 11) — reporting what each rung would do without acting.

8.3 The case state machine and the action ledger

A response case runs a guarded state machine: proposed → active → under_review → confirmed | rolled_back | expired → closed; an illegal transition is an invariant violation → hard deny + critical. Every rung writes to an append-only, hash-chained action ledger (reusing Section 9): {actor, target, rung, verdict_snapshot, trace_id, ttl, rollback_token, approvers}, idempotent by (case, rung). This is the evidentiary record of the response itself.

8.4 Honest limits

The SOAR only acts on the detectable — against the slow in-scope insider it adds nothing over scope + audit + revocation; the ladder is evadable by a patient low-and-slow adversary, and the deterministic floor is what bites. Automating the irreversible is a DoS weapon (hence HITL + reversible-first + interlock). The SOAR engine is itself a privileged actor (capability-scoped adapters, two-person edits, hash-chained ledger, governed by insider-access policy). Thresholds are not secret-as-defense — concealment is not security. CAEP is near-instant, not instant, and R5 via CRLOCSP is *bounded by the OCSPCRL cache TTL* — without pairing the CAEP session- revocation signal with short-lived certificates / OCSP must-staple, a revoked certificate is accepted until the cache expires. HITL is only as good as the human (a 3-a.m. rubber-stamp — mitigated by two-person + explainable dossier, not eliminated). And the behavioral ledger is sensitive personal data: purpose-limited, bounded retention, never repurposed as productivity/HR monitoring, Merkle-anchored in-sovereignty (no cross-border SaaS transparency log). (D3FEND Credential Revocation, Session Termination, Auth Cache Invalidation; ATT&CK T1550T1078T1119/ T1567T1087T1213/T1592.)

9. Tamper-evident, verifiable audit

Accountability rests entirely on an audit trail that cannot be silently altered — including by the very administrator (root/DBA) who runs the database. The hard, honest framing: *you cannot PREVENT a root from editing a log they administer — you make it DETECTABLE* by publishing a commitment (a hash) into a trust domain that same administrator does not control, *as early as possible*, so a later edit cannot pass silently. Without external anchoring, log cryptography is decoration. This is the detailed design behind control C15.

9.1 Append-only hash-chain

Each event carries a monotonic seq, a prev_hash, and entry_hash = SHA-256( JCS(event_without_hashes) ‖ prev_hash ), canonicalized with RFC 8785 so every producer emits identical bytes. Editing or removing a link breaks every subsequent entry_hash. Enforcement is structural: the app role has INSERT only; a trigger rejects UPDATE/DELETE. Correctness precondition: because each hash depends on the previous link, the append is a single-writer per tenant — under concurrent/batch insertion (exactly the exfil scenario) two writers reading the same prev_hash fork the chain; serialize the append (a per-tenant advisory lock or queue) and accept that liveness cost as part of the contract. Note: a database sequence is not gapless (rollback/cache leave benign holes), so a seq gap is not, by itself, tampering (Section 9.6 disambiguates).

9.2 Integrity is not completeness

The hash-chain proves nothing was altered after it was logged — it does not prove that everything was logged. So the access event is emitted in the same transaction as the RLS- guarded read/write (log-on-access): you cannot take the access through the enforced path without the log existing. Two hard limits: (a) completeness covers only the policy/app path — a physical/out-of-band read by a DBA beneath the policy layer (a raw SELECT) does not trip log-on-access and leaves no trace here; that is a problem for at-rest controls and access governance, not Merkle; (b) removing the emit call via code/deploy access defeats completeness silently — the event never gets a seq, so it produces no gap (do not confuse with deletion, which does). Completeness is an operational property of the non-bypassable path, not a cryptographic guarantee.

9.3 Merkle checkpoints and Signed Tree Heads

Each window (per-minute or per-10k events) a checkpointer builds an RFC 6962 Merkle tree over the leaf entry_hashes in seq order and records a Signed Tree Head (STH): audit_checkpoint(tree_size, root_hash, prev_root, signature). The *signing key lives in a KMS, outside the DBA's domain* (separation of duties: the DBA corrupts rows but cannot forge a valid STH). Chained roots (prev_root) support a consistency proof (append-only between two checkpoints) and an inclusion proof (one event under a root, O(log n)).

9.4 External anchoring — the real defense, self-hosted first

In layers: (1) STHs mirrored to a *Koder transparency log on a separately-administered hostorgtenant* — data-protection-safe, since only root-hash + signature leave, never events; (2) witness cosigning (Sigsum / Go checksum-db model): ≥2 witnesses countersign each STH — but independence is everything: in a single-operator sovereign deployment, witnesses the same root administers are theater. The naturally-independent witness here is the *regulator / data controller* (the health authority) as a distinct legal entity running a witness node — crossing a real trust boundary without third-party SaaS; (3) *optionally, per tenant, a last-resort public timestamp* (RFC 3161 TSA / OpenTimestamps → Bitcoin) of the daily super-root — the only non-self-hostable piece (a permanent third-party dependency): only 32 non-personal bytes cross the boundary, giving an un-backdatable "existed-by-T". It is never the default floor (the witness quorum + separate host carry the default); it is a per-tenant policy choice.

9.5 WORM and erasure

Sealed checkpoint segments + event batches under object-lock/compliance-mode or offline media, under legal retention. Honest: software WORM is only as strong as whoever can reconfigure it — against the privileged insider modeled here, WORM on the same cluster is a speed bump; the external anchor is the guarantee. Retention purge is an append event (a tombstone) + crypto-shredding of the underlying data, never a silent DELETE — an LGPD erasure must not look like tampering, and the anchor keeps validating the (now-shredded) structure.

9.6 On-demand verifier

A verifier (kaudit in the Koder SDK) is runnable by an auditor with read-only access (independence is the point): verify recomputes the chain and every root against the signed STH + cosignatures + external anchor; prove <seq> emits an inclusion proof; consistency <A> <B> proves append-only between checkpoints. It disambiguates seq gaps: a benign sequence hole (no adjacent chain break) ≠ a deletion (a downstream entry_hash mismatch); only the second is tampering, and a gap does not prove every event was emitted (that is §9.2, operational). Output is a signed report naming the exact failing range/root — evidentiary value for a public audit, fully deterministic (hashsignatureMerkle, no ML). A DOM-less UI may render the status server-side (green/red) as dashboard anti-spoof — but the guarantee is the auditor's own kaudit run; an insider controlling the checkpointer and the panel can paint it green, so the dashboard green never substitutes for independent verification.

9.7 Honest limits

Tamper-evidence, not prevention: it only detects if an honest STH was anchored+witnessed before the tampering and if someone runs the verifier (operational, not cryptographic, conditions). A pre-anchor window (events between the last STH and the next checkpoint) exists — shortened by frequent checkpoints, never zeroed; a stalled checkpointer widens it, so its liveness is monitored outside the DBA's domain (else the check is circular). Anchoring in "another tenant" is worthless if one root controls both — the quorum must be genuinely independent (ideally the regulator). Completeness covers only the enforced path; a DBA's out-of-band read and a removed emit are silent to it. L8 does not prevent the breach by the authorized insider in their own scope (that is scope/RLS + revocation); its unique contribution is making the *later cover-up* of any vector (V1–V7) detectable — it is the anti-anti-forensics. (ATT&CK T1070.001.002.004, T1565.001, T1485 via the surviving anchor; partial and monitor-dependent: T1562.008/.001; T1222 only with compliance-mode / a separate control plane.)

10. Insider-access governance

The techniques above shorten the time between signal and action and produce proof. Governance attacks the root of the central actor — the ex-contractor — by shrinking the permanent scope they carry. The inherited principle is zero standing privilege: permanent access is the recertified exception, never the default. Nothing here gates abuse *within currently-legitimate scope* (Section 10.7); it reduces permanent scope and the window.

10.1 Just-in-time elevation — a lease that dies on its own

A request → approve state machine, invariant-guarded so a request never self-approves (approver ≠ requester, or SoD blocks it). On approval, identity issues a *narrow-scope elevated claim* inside the DPoP-bound token with exp = end of the window; the refresh does not re-assert the elevation. Past the window, backend authorization simply does not see the claim → deny. *The expiry is structural, not a sweep.* Elevations feed the user-risk score — signal, not gate.

10.2 Segregation of duties

At grant-time and request-time, the SDK evaluates toxic combinations (a set of toxic pairs — executor↔approver of the same action; admin↔auditor). A terminal-sensitive action (mass export) requires multi-party authorization (MPA) — a human, signed approval as an audit event before the batch releases. MPA is a real preventive gate (a second human), not probabilistic — but only on the high-risk path; in-scope export at the normal rate does not pass through it. Where full separation is infeasible (a one-operator clinic), the compensating control is verifiable audit + MPA on the highest-risk actions — without pretending one person is two, and aware that *two admins can collude*.

10.3 Recertification, deterministic

A cron fires campaigns; the "still needed?" evidence is deterministic (last-use from the audit + peer-group comparison), never opaque ML — auditable by government. A grant unused in the window or without an owner who recertifies auto-revokes by default. Recertification is interval-based: a grant can go stale between campaigns — the last-use auto-revoke narrows, not eliminates, that gap. The role-owner's decision is a signed event.

10.4 Break-glass

A KMS-sealed per-tenant credential; withdrawal requires a justification, fires an *automatic critical alert, has a *short TTL, records the whole session (server-side pixels + audit), and the SOAR arm opens a mandatory post-hoc review ticket. Break-glass frequency is a metric — frequent use signals a mis-calibrated JIT. Break-glass is a deliberate hole: its security is detective (alert + recorded session + review), not preventive — a malicious privileged admin can abuse it and is caught only afterward, via the externally-anchored audit chain. It is per-tenant (it does not pierce RLS isolation) but bypasses SoD/MPA — hence the mandatory review.

10.5 Offboarding = HR-driven revocation — the crux of the ex-contractor

The HR/contract system is the source of truth. An offboard transaction cascades: revoke all grants; certificate serial → CRL + OCSP push; revoke the passkey/WebAuthn credential-ids; *revoke the refresh token server-side* (checked at renewal); and for the self-contained access token, *rely on the short TTL* — without per-request introspection there is no way to invalidate it mid-life; disable single-owner service accounts. Short TTL + OCSP-must-staple make revocation bite without waiting for full CRL propagation.

Against a Copy-as-cURL replay (V2), two cases: (a) a third-party replayer fails immediately on the DPoP binding — the proof is signed by a key they do not have; (b) the *ex-contractor themselves, who holds the captured session key, is only stopped *after revocation bites or the access token expires — *between capture and the offboarding signal, within the valid window, the replayed token still works*. time-to-revoke is an SLO, target near-zero (policy says "same day"; "instant" is a goal, not a guarantee). It returns a signed offboard_receipt enumerating every certificatepasskeytoken/grant killed.

10.6 Service accounts

A short SPIFFE-style SVID, minimal scope, a named human owner, rotation and recertification like any account; the owner's offboarding cascades. This narrows the M2M vector (V5) — no "omnipotent eternal" machine credential — but does not close it: the legitimate owner still uses the SVID within scope/window until revocation or expiry.

10.7 Honest limits

Does not contain the insider inside currently-legitimate scope — governance shrinks permanent scope and the window; abuse within the current valid scope is contained only by RLS + accountability + revocation. Offboarding is only as fast as the HR signal — a manual/overnight HR process opens a window; short TTL + must-staple + passkey revocation-list shorten it, but a long-lived cached access token is a real gap, so short TTL is load-bearing. Moreover, *the HR system must itself be self-hosted/sovereign*: if the offboarding source-of-truth is an external SaaS (Workday via SCIM), that is a third-party dependency on the LGPD boundary — to be declared, never hidden. A self-contained access token is not revocable mid-life without per-request introspection; trading short TTL for per-request introspection is the only way to close that window — a declared latency trade-off. *Data already exfiltrated before offboarding is unrecoverable by revocation* — that is DLPwatermarklegal territory. SoD needs enough people; a one-operator clinic compensates with audit + MPA at the highest-risk points, and *with few admins, MPA is vulnerable to collusion. *Recertification is interval-based — a grant can go stale between campaigns. No obscurity sold as protection — everything here is scope-minimization + time-boxing + accountability, explainable to an auditor; no probabilistic score is a gate.

11. Detection-coverage and purple-team validation

A control catalog does not prove itself. A coverage claim is only true once it is exercised against a realistic emulation of the vector. The discipline (from DeTT&CT and the ATT&CK Evaluations doctrine) is: visibility ≠ detection, mapping ≠ validation, and a *fully green matrix ≠ a secure system*.

11.1 Coverage is measured, never presumed

An uncoverage-exercised cell is presumed, not covered, and the matrix marks it so visually. The hard rule: without an adversarial exercise inside a TTL, a cell decays to presumed — anti- silent-coverage. Every "atomic" test is a safe proxy for a real adversary; a creative variant nobody scripted is invisible to the matrix (an emulation-fidelity gap — declared, not hidden). A coverage % is a floor of blind spots, not a ceiling of security.

11.2 A machine-readable coverage ledger

A coverage_cell(control, vector, technique, kind∈{Prevent,Detect,Govern}, expected_signal, status∈{presumed|validated|partial|failed|na}, grade, last_validated_ts, ttl, mttd, mttr, last_run_id) table, persisted over the tamper-evident audit of Section 9 — so an insider forging a "green" is detectable (it breaks the chain and diverges from the external anchor). This does not close V7 over the validator itself: an admin who controls both the ledger and the anchor remains a residual trust root, governed by access policy, not by this framework. The ledger emits an ATT&CK-Navigator-compatible JSON layer (greenvalidated-technique · yellowpartial · red=failed · grey=presumeddecayed), rendered on a *self-hostedoffline Navigator* — the blind-spot heatmap never uploads to MITRE's hosted Navigator or any third party (the map of where detection fails does not leave the stack).

11.3 A self-hosted emulation harness

A breach-and-attack-simulation harness (koder-atk) runs in an isolated VM (never on a laptop). Atomics, one per technique/vector, drive the real stack (craft-id V1, copy-as-cURL V2, batch-loop V3, final-endpoint-direct V4, headless M2M V5, valid-cred-new-device V6, audit-line-edit V7). Atomic Red Team, CALDERA, and VECTR enter as doctrine/inspiration only — none is a runtime dependency or SaaS; the harness is 100% self-hosted.

11.4 Synthetic identity, oracle, and metrics

The harness authenticates as a synthetic operator (a purple-team certificate/passkey in the identity system), which lets it exercise the SOAR arm for real — quarantine (R3) and even revocation (R5) against that identity, without touching a real operator. An oracle pulls the stream by trace_id and measures per atomic: prevented? (deterministic floor block), detected? (+ an Engenuity-style grade), responded? (rung), MTTD (event → alert), MTTR (alert → action). Metrics are timing/counts by trace_id — no PII on the telemetry path. Everything is explainable (prose + trace-ids), no ML on the validation path. UEBA is the target under test; its false-neg/false-pos feed threshold tuning — it never generates the attack (kept scripted for auditability).

11.5 Safety of the simulation itself

Two harness-enforced modes. PROD-SHADOW: only non-mutating atomics whose expected result is a floor block (a V1-read C1 denies, a replay C3 rejects). Reading is not enough as a safeguard — an out-of-scope read the floor let through (the very bug the atomic hunts) would be unauthorized access to real patient data = an LGPD incident. So in production: (i) the IDOR target is *always a seeded honeytoken record, never a real patient row; (ii) if the floor *fails to deny, the harness records the verdict by the authorization decision/status and does not materialize, log, or retain the returned payload — it aborts and quarantines. Mutating payloads are refused in production. SYNTHETIC-TENANT: full fidelity over a honeytoken dataset (never real patient data), where R0–R5 run for real. All emulation traffic is tagged synthetic at ingest (routing results to the purple-team channel, marking the audit row) — but the tag is invisible to the control under test (a control that could see the tag would be cheating; it must block on its own merit).

11.6 Cadence and the CI gate (detection-as-code)

(a) A changed controlplaybookrule re-runs the affected atomics; *a release touching a security control does not ship if its atomics regress validated → failed*. (b) A full run weekly/monthly. (c) Post-incident, every real failure becomes a permanent regression atomic. Mutation/variant atomics (a fuzzed signature) bar "teaching to the test"; human purple-team review remains (it mitigates, not eliminates, BAS gaming).

11.7 Honest limits

Green ≠ secure. ATT&CK Enterprise maps poorly onto APIbusiness-logic abuse: V1V4 map loosely (T1190T1213) — carry a parallel OWASP API mapping (BOLABFLA/business-flow) and do not fake clean ATT&CK coverage. Obscurity is not security: for V1 the floor is C1/RLS authorization; the cell goes green only on a C1 DENY — a non-enumerable id (C18) is defense-in-depth, never the gate; a V1 cell never goes green because the id was unguessable. Likewise watermark/traitor-trace (C17) is attribution, never prevention. The authorized, slow, in-scope insider (degenerate V3) is *not a detection problem, and the cell *never goes green — contained by scope + audit + revocation, not analytics; a validated V3 covers only the rate-cap-busting variant, not sub-threshold reading at human pace. The V5 atomic demonstrates the total absence of a client-side signal — a confirmed blind spot, not a green cell. Irreversible SOAR (R5) is only measured in the synthetic tenant; production parity is inferred and reported as such. No cell goes covered without a validated run inside its TTL.

12. Adversarial robustness and privacy-by-design

The final layer treats two properties as first-class engineering, not afterthoughts: the analytics must survive an adversary who knows they exist, and they must protect the very citizens and operators whose behavior they model. It creates no new floor — the insider is still contained by scope + audit + revocation; everything here is signal over the floor, log-before-block.

12.1 Evasion resistance (MITRE ATLAS)

Four levers, none oversold: (a) heterogeneity — evading one ensemble member does not transfer to another in a different feature space; (b) server-side-costly features — costly, not impossible, to forge (JA4 is forgeable via TLS-shaping; UA↔JA4 divergence catches lazy spoofing, not the adversary who aligns both); the real value is raised cost plus the deterministic floor outside behavioral reach; (c) oracle hardening — never return the numeric risk score to the client; the oracle output is a coarse outcome (allow / step-up), rate-limited and logged, to deny probing (ATLAS AML.T0040); (d) randomized holdout — a fraction of sessions in shadow/log-only, deep scoring sampled at random. Honestly, (c) and (d) are obscurity-that-raises-cost, never a gate.

12.2 Step-up is not a probabilistic gate

The only non-allow outcome the probabilistic ensemble may trigger is a step-up — a reversible challenge (re-authpasskey), not a deny. A hard denygate stays exclusive to the deterministic floor plus caps. Every step-up fired by a probabilistic signal is logged, rate-limited, reviewable under LGPD Art. 20, and never the sole basis for an irreversible action (R5 requires human-in-the-loop). Thus no opaque ML ever decides a government-scope access.

12.3 Drift detection as a fail-safe

Per feature × peer-group × endpoint: PSI + KS/chi-square over DP aggregates (daily vs trailing-30d); prediction-drift via Jensen-Shannon; ADWIN/Page-Hinkley per endpoint. Benign drift (population-wide, gradual, a known event) is separated from a per-account slow trend. A *drifted model is auto-demoted to log-only* until human re-validation — never a degraded gate (defending ATLAS AML.T0031). A model registry (version, training window, schema hash, metrics, status) gives government reproducibility.

12.4 The differential-privacy boundary, stated precisely

Population baselines (per-roleunitendpoint means, variances, quantiles) use a Laplace/Gaussian mechanism with a per-tenant, accounted, auditable epsilon budget (the U.S. Census 2020 TopDown precedent). The precise boundary: DP protects only the baselinesaggregatesdashboards/drift statistics. Individual scoring is not DP, and — critically — the *individual feature store holds raw (pseudonymized) features NOT covered by DP: it is a *high-value PII concentration protected by RLS + keyed pseudonymization + retention + audited break-glass, not by DP; a leak of it exposes individual behavior. Against membership-inference (AML.T0024) the primary defense is the *non-exposed internal-mTLS scoring oracle* (it denies inference queries), not DP on the aggregates; models trained on individual data still memorize — mitigate with DP-SGD in training or accept and declare the memorization limit.

12.5 LGPD-hard by construction

Purpose-limitation is structural: features are a declared, allow-listed schema in the event contract — an employee-productivity metric is non-derivable (no per-operator throughput dashboard exists to build). Per-tenant keyed pseudonymization; re-identification only via the identity system under RLS + audited break-glass. Explainability satisfies LGPD Art. 20 + human-in-the-loop for the irreversible. A data-protection impact assessment is documented per tenant — the UEBA is itself a processor of sensitive health data. All self-hosted; no citizen telemetry leaves for third-party SaaS.

12.6 Honest limits

(1) It does not contain the authorizedslowin-scope insider better than floor + audit + revocation — it only raises cost and advances detection; the slow-trend detector catches escalation, not a flat in-scope pattern. (2) Evasion by probing is possible (oracle/holdout are cost-raising obscurity; JA4/UA↔JA4 are forgeable by a competent adversary). (3) DP vs. utility is asymmetric: a tight epsilon weakens detection in a small peer group — exactly where re-identification risk is highest — an explicit per-tenant trade-off, not hidden. (4) DP is not full anonymization under LGPD: the feature store remains personal, sensitive-PII-concentrated data — its risk is RLSretentionbreach, not DP. (5) Explainable models detect less exotic anomaly than black-boxes — an accepted trade-off. (6) The UEBA is itself a sensitive-health-data processor — requiring impact assessment, minimization, retention. (7) Sequence "non-human rhythm" only discriminates on the human channel — on M2M/API it is the legitimate baseline, so V5 is carried by caps + JA4 + audit + mTLS/DPoP, not by the sequence model. (8) GeoASNreputation are externally-imported data (periodic refresh), not a native capability.

13. Synthesis: what actually contains the insider

Ten techniques, one spine. It is worth ending exactly where the field's honesty demands, with the partition made explicit:

The only prevention of the authorized insider is scope — object-level authorization (RLS) and
volume caps (C1C5C18). Deterministic, explainable, a legitimate gate.
The only accountability is a verifiable audit trail (C15) — externally anchored so a later
cover-up (V7) is detectable. It does not prevent; it makes provable.
The only defense against the ex-contractor's clock is revocation (C2/CAEP) — bounded by the
slowest credential in the lifetime, so short TTLs are load-bearing.

Everything else — UEBA (Section 3), network origin (Section 4), data-centric marking (Section 5), capability-URLs (Section 6), anti-instrumentation (Section 7), SOAR (Section 8), governance (Section 10), coverage validation (Section 11), adversarial-robust and privacy-preserving analytics (Section 12) — is defense in depth measured against those three legs. Each earns its keep by one of three effects: shortening detection latency, raising the cost of the fast/scripted variants, or producing evidence. Not one of them is the wall.

The mature posture is therefore a layered, honest system: a deterministic floor that gates; an externally-anchored audit that proves; fast revocation that expires the ex-insider; and, on top, a reproducible, explainable, privacy-preserving analytics-and-response fabric that watches, denounces, and — reversibly, with a human on the irreversible — responds. Sell any probabilistic layer as the gate and you have lied to the auditor and to the patient. Name scope + accountability + revocation as the containment, and everything above becomes what it truly is: *observability and friction that buy time and evidence* against an adversary you already let in.