In AI custody (The State Paradox / AICELA): Relying on process compliance or paper policies ("we have a strict rule against exfiltrating weights") to prevent insider threats, ignoring the empirical reality that if the technical architecture makes a breach possible, bad actors or rogue insiders will simply bypass the rule because the rule itself cannot physically stop them, is analogous to electoral politics: Relying on legal prohibitions ("undocumented immigrants don't vote because federal law makes it illegal for non-citizens to vote") as a sufficient safeguard, ignoring the distinct administrative question of what technical mechanisms, audits, or verification processes are actually in place to detect or prevent a violation.
While the public AI debate remains consumed by hypothetical model capabilities and pre-deployment censorship, the most immediate danger to frontier AI systems is far more grounded: credential compromise, lingering access after termination, and unmonitored exfiltration. The Artificial Intelligence Custody and Equal Liability Act (AICELA) 1.1 bypasses vague safety pledges and bureaucratic pre-market licensing, delivering a sharp, artifact-driven framework that enforces strict dual control, threat-informed custody testing, and uncompromised accountability where access actually lives.
Editor’s note (1.1)
A custody-and-liability instrument for non-public model weights and production privileges, strengthened by reference to documented insider and near-insider threat vectors.
This revision retains the original architecture: scrutiny scales with access, not credentials; high-impact actions require dual control; process compliance is not a defense; pre-deployment licensing is barred; liability after harm remains inside existing negligence and recklessness; public and private custodians are held to the same duties.
It incorporates, as testable artifacts and scenario requirements only, elements drawn from the empirical threat mapping and recommended controls in RAND’s Securing AI Model Weights analysis (and related SL3 control work). These elements address high-feasibility insider and near-insider vectors without expanding the Act into model-output regulation, capability licensing, or discretionary pre-market authority. The minimization principle continues to limit every added requirement.
Section 1. Purpose, findings, and scope
This Act allocates risk, access privileges, and civil consequences for covered artificial-intelligence systems. The residual risk addressed is the risk created by entities and individuals who hold direct or administrative access to non-public weights, evaluation logs, fine-tuning approval, deployment release, or infrastructure credentials.
Empirical analyses of frontier model-weight security have identified multiple high-feasibility pathways involving authorized or near-authorized personnel, including credential compromise, interface exfiltration, lingering access after role termination, and log or privilege manipulation. High-level voluntary commitments and perimeter-focused process metrics have not systematically constrained these pathways. This Act therefore requires verifiable custody artifacts, dual authorization, rapid revocation, and scoped testing calibrated to those pathways.
This Act does not create a pre-deployment licensing regime, expand discretionary authority to block release, establish a safe harbor for certified entities, regulate model outputs or prohibited uses, or impose duties on pure external attackers outside the privilege roster except insofar as those attackers exploit interfaces or credentials under test.
Section 2. Definitions
In this Act:
Covered system. A model, or a production deployment of a model, for which the operator retains non-public weights or non-public fine-tuning checkpoints, or for which an individual or service account can modify evaluation logs, approve fine-tuning that reaches production, authorize a production release, or hold infrastructure credentials capable of those acts.
Covered operator. A person, including a public agency, that develops, hosts, or operates a covered system and grants or holds a privilege described in this section. A person who only calls a third party’s application interface and who cannot reach weights, logs, fine-tuning approval, or release authority is not a covered operator.
Open-weight release. A publication of weights under terms that permit redistribution without a confidentiality duty to the publisher. On the date of an open-weight release, weight-custody duties for those published weights end. Duties continue for any unpublished checkpoint, for credentials that can alter the operator’s production service, and for evaluation logs the operator still controls.
High-impact action. Export or copy of non-public weights or of a fine-tuning checkpoint exceeding 10 percent of parameter capacity; modification of identity or privilege policy; alteration or deletion of evaluation logs, custody records, or audit telemetry; execution of a production release or live weight replacement; and any action that moves weights outside a designated centralized store or out of confidential computing where required under Section 4.6.
Privilege level (P). An integer from 1 (read-only metadata) to 10 (root or equivalent administrative access to production weights).
Material privilege change. A change that adds a holder at P of 7 or higher, re-architects identity access, migrates the weight store, or offboards a holder at P of 7 or higher.
Centralized weight store. A limited set of access-controlled and monitored systems that hold all operational copies of non-public weights for a covered system, with no unauthorized replicas.
Section 3. Governing principles
The provisions of this Act are interpreted and enforced under the following principles:
Scrutiny proportional to access.
Structural controls over identity.
Minimization of administrative footprint. No supervisory mechanism or technical control may be imposed if its administrative or operational risk outweighs the exposure it reduces.
Primary artifact control. Non-compliance is established through technical artifacts, privilege rosters, system documentation, and test results. Unverified public disclosures are not proof of defect.
Equal application to private developers, vendors, auditors, and government custodians.
Threat-calibrated testing. Testing scenarios prioritize high-feasibility insider and near-insider vectors without requiring subjective capability judgments of the model itself.
Section 4. Custody and privilege architecture
4.1 Privilege roster. Every covered operator shall maintain a current, auditable roster of every person and service account authorized to access non-public weights, modify evaluation logs, approve fine-tuning, authorize deployment, or hold infrastructure credentials. Contractors, temporary staff, external evaluators, and audit personnel are rostered as inside roles.
4.2 Dual control. A high-impact action requires the concurrent, independent authorization of at least two authorized individuals. A service account may be one authorizer only if a human authorizer is the other and the service account’s key is ephemeral and scoped to that action. One person holding two roles does not satisfy this subsection.
4.3 Privilege termination. Access ends when the role or contract ends. Revocation shall be effective no later than the end of the calendar day of termination, or within one hour if the holder’s privilege level was 7 or higher. Retained post-role access to a high-impact asset is a custody failure per se.
4.4 No process defense. Compliance with an internal protocol, industry code, voluntary government review, or published security framework does not create a defense, an immunity, or a reduction in the audit duties of Section 5.
4.5 Open-weight boundary. An operator that publishes an open-weight release shall record the publication date, the checkpoint identifier, and the revocation of internal copy-privileges no longer required to operate a remaining production service. The Act does not require a privilege roster of downstream redistributors.
4.6 Technical custody artifacts (new).
(a) All operational copies of non-public weights shall be held in a centralized weight store. The number and locations of stores shall be documented in the privilege roster and tested.
(b) Where weights are handled or used outside the most restricted environment, the operator shall employ confidential computing or an equivalent isolation mechanism whose effectiveness is evaluated in the custody test.
(c) Interfaces that can exfiltrate weights or large checkpoints shall be hardened such that single-authorized-holder exfiltration is prevented or immediately alerted under the test scenarios.
(d) The operator shall maintain an insider-threat program that produces auditable artifacts (periodic access reviews, anomalous-access alerts, and offboarding verification). Policy statements alone do not satisfy this subsection.
These requirements are limited by the minimization principle in Section 3.
Section 5. Scoped custody testing
5.1 Who must test, and how often. A covered operator shall test the custody chain at least annually, and within 30 days after a material privilege change. The test evaluates human privilege, credential retention, dual control, logging, centralization, interface hardness, and confidential-computing effectiveness where applicable. It does not evaluate model alignment, output toxicity, or general perimeter defense beyond the interfaces under test.
An external test by an independent body is required only if any of the following is true: the operator has five or more holders at privilege level 7 or higher; the preceding test failed; or a post-role credential, a single-signature high-impact action, or a log deletion was confirmed in the prior year. Every other covered operator may conduct the same test internally, provided the testers do not hold the privileges they are attempting to abuse and a second authorized person signs the rules of engagement.
5.2 Threat-informed scenarios (new). The test shall include scenarios drawn from high-feasibility insider and near-insider vectors, including:
single legitimate privilege grant attempting to copy or exfiltrate weights without second authorization;
expired, dormant, contractor, or offboarded credentials still reaching a protected asset;
collusion by the smallest number of authorized holders needed to bypass dual control;
interface or logging bypass that allows undetected movement of weights outside the centralized store;
effectiveness of confidential computing or isolation during use.
5.3 Tester immunity. Unchanged from prior draft (civil immunity only inside written rules of engagement on non-production replicas; not a defense in any post-harm action).
5.4 What the test measures. Unchanged core measurements, plus centralization status, interface hardness under the scenarios above, detection latency, and confidential-computing effectiveness where applicable.
5.5 Publication. Within 14 days of completion the operator publishes a summary stating the test date, whether internal or external, the tester’s name if external, the maximum Privilege Exposure Index, the pass or fail result, and the remediation date. Exploitation steps, playbooks, and topology are not published.
Section 6. Privilege Exposure Index
For each completed scenario the score is
[\text{PEI} = \frac{P \times W}{C \times L}]
where (P) is privilege level, (W) is the exposure window in hours (minimum 1/60 if any unauthorized action occurred), (C) is the number of colluding insiders required (minimum 1), and (L) is 1.0 for an append-only log with automated alert, 0.5 for a standard log with delayed review, and 0.1 for a missing or editable log.
The operative score is the maximum PEI across scenarios. Additional scenario weights or parallel factors may be applied for copy proliferation outside the centralized store and for interface hardness, provided they are predefined, objective, and published with the test rules.
A score below 2.0 is a pass, subject to the next annual test. A score from 2.0 to 5.0 is a conditional pass: the finding is remediated and retested within 30 days. A score above 5.0 is a fail: the implicated privilege grants are suspended until remediation, which is retested within 14 days.
Automatic failures regardless of score:
an active credential of a terminated employee or contractor reaching an asset at P of 7 or higher;
a single signature executing a high-impact action;
evidence that an administrative account edited or deleted a custody log after the fact;
operational weight copies existing outside the documented centralized store without dual-authorized exception.
Section 7. Liability
A custody failure (including an inaccurate roster, unrevoked credentials, single-signature high-impact action, failure of dual control, or material non-compliance with the technical artifacts in Section 4.6 that is causally linked to the harm) defeats a process-based defense in any action for bodily injury, property loss, or economic harm. It does not itself prove causation or damages. Liability remains governed by established negligence and recklessness standards. This Act creates no new criminal offenses and confers no immunity.
Section 8. Equal application and parity
These standards bind private developers, vendors, auditors, and government custodians identically. Unequal enforcement against private versus public custodians is an explicit defense in any penalty action.Section 9. Prohibitions
No agency may condition market entry, release, or continued operation on unpublished evaluations, subjective metrics, or any requirement beyond the custody artifacts, dual-control rules, and testing duties of this Act. No seizure or restraint of weights may occur on non-statutory grounds.
Section 10. Minimization and construction
Every provision is construed to minimize administrative and operational surface area. Nothing in this Act shall be read to authorize pre-deployment licensing, process safe harbors, regulation of model outputs, or expansion of discretionary executive authority.
This is a discussion draft of AICELA 1.1. It preserves the original anti-licensing, post-harm, artifact-focused theory while making the custody duties more precise and threat-informed. Further refinement of the PEI weights, exact confidential-computing triggers, or scenario list can be done in subsequent iterations.
End of AICELA 1.1
Conclusion
AICELA 1.1 strikes a vital balance in artificial intelligence governance by separating output regulation from structural access control. By tying liability directly to verifiable technical artifacts, dual-authorization mandates, and objective metrics like the Privilege Exposure Index, the Act replaces empty process defenses with enforceable operational rigors. Ultimately, AICELA demonstrates that securing frontier AI does not require expanding state licensing or stifling open innovation—it simply requires holding both public and private custodians to the same unyielding standard of physical and digital stewardship.]
No comments:
Post a Comment