TL;DR: California’s SB 53 requires large AI developers to publish safety frameworks, disclose risk assessments, and report critical incidents, while other states are moving with different rules, creating a fragmented compliance landscape for enterprises, according to Lasso Security. AI governance is shifting from policy discussion to operational obligation, and identity, access, and incident controls now need jurisdiction-aware design.
At a glance
What this is: California SB 53 is a state AI governance law that pushes large AI developers toward safety frameworks, risk disclosure, and incident reporting while adding enforcement pressure.
Why it matters: It matters because practitioners cannot treat AI governance as a single policy layer anymore; identity, access, incident handling, and compliance controls now need to vary by jurisdiction and deployment context.
Context
California SB 53 shows that AI governance is no longer a theoretical policy debate. The law creates concrete obligations for large AI developers, including safety frameworks, risk assessments, and critical incident reporting, and it does so in a state-by-state environment rather than under one unified federal rulebook.
That matters for identity and security programmes because governance is now tied to operational controls, not just policy statements. As states add different transparency, disclosure, and accountability requirements, teams need to think about how access, incident response, and evidence retention will hold up across jurisdictions.
The pattern is already broader than California. Other states are setting different expectations for disclosure, duty of care, consumer transparency, and government use, which means enterprises will face overlapping requirements instead of a single compliance baseline.
Key questions
Q: How do security teams keep AI governance consistent across regions?
A: Security teams should build a single control model that can be mapped to local legal and operational requirements. The practical goal is not identical rules everywhere, but consistent accountability, evidence collection, and exception handling. That reduces fragmentation when AI systems operate across jurisdictions.
Q: Why does fragmented governance create more risk as AI adoption grows?
A: AI increases the speed and reach of data usage, so any inconsistency in policy or access control is amplified across more workflows, more users and more decisions. Fragmentation also makes remediation slower because no one control plane can explain the full path of the data. The result is policy drift and trust erosion.
Q: What do organisations get wrong about AI safety and access control?
A: Organisations often focus on model outputs while ignoring the privileges behind the model. If an agent can read sensitive data or invoke tools, the real risk is what it can cause the environment to do. Effective control starts with scope, policy, and monitoring around actions, not just moderation of generated text.
Q: How do teams know whether AI governance is actually working?
A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement. If auditors can ask for a transaction and receive a complete record in hours, not weeks, the programme is producing usable control evidence rather than just documentation.
Technical breakdown
Why fragmented AI governance creates control drift
Fragmented AI governance means the same AI system can be subject to different disclosure, risk, and reporting obligations depending on where it operates. That breaks the assumption that one control set can satisfy every deployment. In practice, security teams need to map where AI systems are used, what data they touch, and which legal obligations attach to each environment. The control problem is not just policy inconsistency; it is evidence, ownership, and process drift across jurisdictions.
Practical implication: build a jurisdiction-aware control inventory before you standardise any AI governance workflow.
What SB 53 changes for security and identity controls
SB 53 moves AI governance into the same operational territory as security governance. Safety frameworks, risk assessments, and critical incident reporting all depend on traceable ownership, reliable access control, and repeatable review processes. That means identity governance is part of AI governance even when the law does not name IAM directly. If developers, deployers, legal, and security teams cannot agree on who can approve changes, access logs, and incident evidence, compliance will fail at execution time.
Practical implication: assign explicit owners for AI risk sign-off, evidence retention, and incident escalation across the full deployment lifecycle.
Why frontier AI oversight now depends on access discipline
Frontier AI governance is not only about model behaviour. It also depends on who can change prompts, access training data, modify system instructions, and approve releases or incident reports. Those are identity questions wrapped inside regulatory questions. As the governance model fragments by state and country, the weakest point is often not the law itself but the organisation’s ability to prove controlled access and accountable change management across AI operations.
Practical implication: treat privileged access to model operations, logs, and safety artefacts as regulated control surface, not routine admin access.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Fragmented AI regulation is becoming an identity governance problem, not just a legal one. SB 53 and the state laws around it force enterprises to operationalise governance differently by jurisdiction. That creates versioning pressure on approvals, evidence, access, and incident handling. The organisations that will struggle most are the ones still treating AI policy as a single enterprise document rather than a control map tied to deployment context.
Jurisdiction-aware AI governance is now a control design requirement. A safety framework that looks complete in one state may be insufficient in another because disclosure, reporting, and accountability obligations differ. That means identity and access decisions around who can approve, who can attest, and who can respond are no longer universal defaults. Practitioners need governance patterns that survive regulatory variation without fragmenting operational trust.
AI governance cannot be separated from privileged access governance. The law may focus on safety frameworks and reporting, but the operating reality depends on access to prompts, logs, configuration, and incident evidence. Those assets are identity-controlled, and if access is loosely managed, the organisation cannot prove compliance even when the policy exists. The practical conclusion is that AI oversight must be built into the same control plane as privileged access.
Named concept: jurisdiction-aware governance drift. This is the gap that appears when one AI programme has to satisfy multiple state regimes with different disclosure and accountability rules. The drift is not only legal. It shows up in inconsistent ownership, inconsistent evidence, and inconsistent control enforcement across teams. Practitioners should treat that drift as a design flaw in the governance model, not an administrative inconvenience.
From our research library:
- 76% of organisations cite shadow AI as a definite or probable problem, up from 61% in 2025, according to HiddenLayer's 2026 AI Threat Landscape Report.
- Read next: Agentic AI Identity Risk Board Briefing
What this signals
Jurisdiction-aware governance drift: Enterprises will increasingly discover that one AI policy cannot satisfy every operating region. The operational challenge is not just complying with more rules, but proving that access, approvals, and incident evidence remain coherent when obligations diverge.
Teams should expect AI governance to move closer to privileged access management and evidence handling. As state rules multiply, the most fragile control is often the one that assumes a single approval path, a single reporting trigger, and a single compliance owner.
The strongest programmes will design for regulatory variation up front rather than retrofit controls after the fact. That means tying model operations, incident workflows, and access decisions to the jurisdictions where the system actually runs.
For practitioners
- Map AI deployments by jurisdiction Create a deployment register that ties each AI system to the states and countries where it operates, the obligations that apply, and the control owner responsible for each requirement.
- Separate approval paths for model changes and incident reporting Define who can approve safety framework updates, who can attest risk assessments, and who can trigger critical incident reporting so governance does not depend on ad hoc coordination.
- Harden privileged access to model artefacts Restrict access to prompts, logs, configuration, evaluation data, and safety documentation, because these artefacts become evidence during regulatory review and incident response.
- Build an evidence retention standard for AI governance Preserve risk assessments, approval records, and incident artefacts in a form that can be retrieved quickly when regulators or auditors ask for proof.
Key takeaways
- California SB 53 shows that AI governance is becoming an operational control problem, not just a policy debate.
- The immediate enterprise risk is fragmentation, because different states are already taking different positions on disclosure, duty of care, and reporting.
- Security and identity teams need jurisdiction-aware ownership, access discipline, and evidence retention before compliance expectations diverge further.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST AI RMF and NIST CSF 2.0 set the technical controls, and EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — AI Governance and Accountability | SB 53 turns AI governance into accountable operational oversight. |
| Recommendation — Establish governance ownership for AI safety frameworks, risk assessments, and incident reporting across jurisdictions. | ||
| EU AI Act | Art. 9 — Risk Management System | The article contrasts state-level AI rules with structured risk obligations under the EU model. |
| Recommendation — Align AI risk management processes to risk-tiered obligations and document controls per deployment. | ||
| ISO/IEC 42001:2023 | A.4 — Organization and its Context | Fragmented AI governance requires an AI management system that accounts for regulatory context. |
| Recommendation — Build an AI management system that maps legal context, ownership, and control evidence by jurisdiction. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The article is fundamentally about how enterprises should govern AI risk across changing rules. |
| Recommendation — Update risk management strategy to account for variable AI governance obligations across operating regions. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI governance depends on controlling who can change model artefacts and operational access. |
| Recommendation — Restrict privileged access to model operations and log artefacts to reduce identity abuse risk. | ||
Key terms
- Jurisdiction-aware governance: A governance approach that maps obligations, approvals, and evidence to the legal environment where a system operates. For AI programmes, it means controls are not treated as universal defaults but as rules that vary by state, country, sector, and deployment context.
- Safety Framework: A safety framework is the set of policies, filters, review processes, and monitoring controls used to prevent harmful AI outputs. In synthetic media contexts, it should cover content policy, abuse testing, escalation paths, and post generation enforcement. If the framework cannot keep pace with misuse, it becomes a weak control.
- Critical incident reporting: The process of formally escalating and documenting a serious AI-related event for regulators, leadership, or other oversight bodies. It depends on clear thresholds, assigned responsibilities, and preserved evidence so the organisation can explain what happened and what was done in response.
- Hybrid Governance Drift: The gradual mismatch between how access is approved and how access is actually used when people move between home, office, and shared environments. In identity programmes, it shows up as inconsistent policy enforcement, uneven session oversight, and lifecycle controls that no longer match the real work pattern.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org