Enterprise AI governance has collapsed two distinct control problems into a single vocabulary. This collapse is the root cause of the current control gap, and it is a category error, not a matter of degree.
Alignment is the discipline of shaping a model's outputs to reflect intended values, preferences, and behavioral norms. It operates on probability distributions over token sequences. Its methods — reinforcement learning from human feedback, constitutional AI, system prompts, instruction tuning — adjust the likelihood that a model produces one class of output over another. Alignment is a statement about tendencies.
Security is the discipline of guaranteeing that a defined set of actions either occurs or does not occur, regardless of the internal state that produced the request. It operates on discrete events at a boundary. Its methods — access control, cryptographic verification, policy enforcement — do not adjust likelihoods. They permit or deny, and they produce evidence of which occurred.
These are non-overlapping control domains. Alignment answers: what does the model tend to produce? Security answers: what was permitted to cross the boundary, and can that be proven? No amount of improvement in the first domain answers the question posed by the second. A model that is 99.99% aligned still requires a security architecture for the 0.01%, because security is not a confidence interval — it is a binary condition with an evidentiary trail.
Enterprise risk, compliance, and legal functions require answers in the security domain: what happened, when, under what authorization, and how is that demonstrable to an auditor, regulator, or opposing counsel. Alignment techniques do not produce that class of answer. They were not built to.
RLHF and guardrail systems — content filters, moderation classifiers, system-prompt instructions, refusal training — share a structural property: they operate inside the model's inference process or as adjacent probabilistic classifiers evaluating the model's own output. This produces three specific, technically identifiable failure conditions.
1. Probabilistic enforcement. A guardrail trained via RLHF reduces the probability of an undesired output class. It does not eliminate it. Any system whose defense is a probability distribution has, by construction, a non-zero failure rate. That rate is often unknown, unmeasured in production, and unbounded under distribution shift — meaning the failure rate at deployment is not the failure rate observed in evaluation.
2. Adversarial bypass. Because guardrails are trained against a fixed or slowly-updated distribution of adversarial examples, they are subject to the same generalization gap as any classifier. Prompt injection, jailbreak chaining, encoding obfuscation, and multi-turn context manipulation are not edge cases — they are the predictable output of adversarial search against a static decision boundary. A published jailbreak technique does not require re-discovery; it requires re-application. This is a solved-and-reopened cycle, not a converging one.
3. Unverifiable post-hoc assessment. When a guardrail fails, the enterprise typically learns of it after the fact, through customer complaint, audit, or incident. There is no cryptographic record generated at the moment of decision that proves what the model was permitted to do versus what it did. The absence of a tamper-evident record means the enterprise cannot produce evidence — only reconstruction and inference. In a legal or regulatory proceeding, reconstruction is not evidence of control. It is an admission that no control existed at the time of action.
These three properties are not implementation defects correctable by better training data or a larger RLHF budget. They are consequences of enforcing security-domain requirements using alignment-domain mechanisms. The mechanism class is mismatched to the guarantee required.
A control that satisfies security-domain requirements must have three properties: it must be enforced outside the space where probabilistic generation occurs, it must apply irrespective of the model's internal weights, prompts, or training procedure, and it must produce a record of its own operation that a third party can verify without trusting the enforcing party's testimony.
This is the deterministic membrane: an output-boundary control layer, external to model inference, that evaluates every candidate action against an explicit, versioned policy before that action is permitted to execute or exit the system. The membrane does not ask "did the model intend this responsibly?" It asks "is this specific action, as specified, permitted under this specific policy, at this specific time?" The answer is binary. It is computed the same way regardless of which model produced the candidate action, what that model was trained on, or what system prompt preceded the request.
Because the membrane is independent of model internals, it is unaffected by prompt injection, jailbreak phrasing, fine-tuning drift, or model substitution. An attacker who successfully manipulates a model's output has manipulated a candidate — not an executed action. The candidate must still cross the boundary, and the boundary does not evaluate candidates on the basis of how persuasively they were generated.
A boundary control is only as strong as the evidence it produces. The deterministic membrane generates a cryptographically signed execution receipt for every decision it makes, using HMAC (Hash-based Message Authentication Code) construction.
The mechanism, stated precisely:
The verifiability properties that follow are specific, not asserted:
Non-repudiation. Because the signature is computed over the exact decision inputs and outcome, any alteration to the record — after the fact — invalidates the signature. A party holding the verification key can confirm whether a receipt is authentic without needing to trust the party that generated it. This converts "we have logs" into "we have cryptographic proof that these logs were not altered."
Falsifiability. The claim "this action was permitted under policy version X at time Y" is a testable assertion. Recomputing the HMAC from the stored inputs and comparing it to the stored signature either confirms or falsifies the claim. This is a mechanism, not a representation the enterprise asks a court or regulator to accept on faith.
Evidentiary standard. For General Counsel, this receipt structure is the difference between a log entry — which is a business record subject to challenge on grounds of alteration, access control, or retention practice — and a cryptographically verifiable artifact whose integrity can be independently confirmed by opposing counsel, a regulator, or a court-appointed expert, using only the public verification procedure. This is the evidentiary posture required for defensible compliance under frameworks that demand demonstrable control (SOC 2, ISO 27001 control objectives, and sector-specific regulatory audit requirements that ask not "do you have a policy" but "prove the policy was enforced at the time of the event").
This argument does not claim that alignment techniques are without value, or that RLHF should be discontinued. Alignment reduces the frequency with which undesired candidates are generated in the first place, which is operationally useful. The claim is narrower and specific: alignment cannot serve as the enterprise's security control, because it does not produce a binary, boundary-enforced, independently verifiable guarantee. It was not designed to, and no amount of additional training changes what class of guarantee a probability distribution can offer.
The deterministic membrane is not a competing alignment technique. It is the security layer that alignment was never structurally positioned to provide.
Every claim above is falsifiable by construction: the failure modes of guardrails are demonstrable through published adversarial technique reproduction; the membrane's independence from model internals is demonstrable by substituting models behind the same policy boundary and confirming identical enforcement; the receipt's non-repudiation is demonstrable by attempting to alter a stored record and recomputing its signature.
A live implementation of the deterministic membrane, generating real HMAC-signed execution receipts against a defined policy set, is available for direct examination at:
gateway.qualequest.com
Security architects are invited to attempt boundary bypass. Legal and compliance teams are invited to request a receipt, verify its signature independently, and assess its evidentiary sufficiency against internal audit standards. The proof is operational, not descriptive.