California SB 53 signals a fragmented future for AI governance

At a glance

What this is: This is an analysis of California SB 53 and the wider state-level AI governance patchwork, with the key finding that enterprises now face overlapping AI obligations across jurisdictions.

Why it matters: It matters because IAM, IGA, and security teams will increasingly need to align access, oversight, and incident processes to regulatory requirements that differ by state and by AI use case.

👉 Read Lasso Security's analysis of California SB 53 and state AI governance

Context

AI governance is moving from principles to enforceable obligations, but the rules are not arriving in one coherent package. California’s SB 53 is part of a broader wave of state AI laws that create overlapping requirements for disclosure, safety documentation, and incident reporting.

For identity and access practitioners, the practical challenge is that compliance can no longer sit outside security operations. Governance now has to cover who can deploy AI systems, who can approve model use, who can access sensitive data through those systems, and how evidence is retained when regulators ask for it.

Key questions

Q: How should organisations govern AI systems when state laws differ by jurisdiction?

A: Organisations should treat AI governance as a jurisdiction-mapping exercise, not a single policy. Define which laws apply to each deployment, then tie approvals, disclosures, logging, and retention to those requirements. The key is to make access and evidence controls location-aware so the same AI system can satisfy different obligations without relying on manual interpretation.

Q: Why do AI governance rules increase the importance of identity and access management?

A: Because AI rules depend on proving who approved use, who can change the system, and who can access the data it touches. IAM and IGA provide the audit trail for those questions. Without identity-linked ownership and entitlement control, organisations cannot demonstrate accountability when regulators request evidence of decisions or incidents.

Q: What do security teams get wrong about AI compliance programmes?

A: They often treat compliance as documentation after deployment rather than as a control system built into access, logging, and incident response. That approach fails when laws require timely disclosure or proof of oversight. A usable programme connects model approval, privileged access, and retained evidence from the start.

Q: Who is accountable when an AI system causes a reportable incident?

A: Accountability should sit with the business owner of the AI use case, the security or risk function overseeing controls, and the technical identities that administered the system. If those roles are not explicit, incident reporting becomes ambiguous and slow. A regulator will expect a named chain of responsibility, not a vague reference to the platform team.

Technical breakdown

What SB 53 changes for AI governance controls

SB 53 pushes AI governance into a more auditable form. Requirements to publish safety frameworks, disclose risk assessments, and report critical incidents create a documented control surface around frontier models. That matters because many organisations still treat AI governance as policy language rather than an operational system with evidence, ownership, and escalation paths. Once disclosure and reporting become mandatory, the question is no longer whether a model is allowed in the business. The question is whether the organisation can prove how the model was assessed, who approved its use, and what happened when risk changed.

Practical implication: build approval, assessment, and incident evidence flows that can survive regulatory review.

Why a patchwork of state AI laws complicates identity governance

A fragmented legal landscape creates a governance mapping problem. Different states may define disclosure, transparency, duty of care, or consumer notification in different ways, which means the same AI system can trigger different controls depending on where it is deployed or used. Identity programmes are affected because access governance is one of the few places where policy, systems, and accountability meet. If deployment rights, data access rights, and model administration rights are not tied to jurisdiction-aware controls, organisations will struggle to show consistent compliance across operating regions.

Practical implication: map AI entitlements and operational approvals to jurisdiction-specific policy requirements before rollout.

How frontier AI governance connects to human, NHI, and agentic access

AI governance is not just about the model itself. It also covers the people, service identities, and agentic systems that build, call, monitor, and modify it. Human developers approve changes, non-human identities move data and invoke services, and autonomous systems can expand the speed and scope of execution. Each layer changes the audit trail and the accountability chain. That is why AI governance and identity governance are converging. The organisation needs to know which actor used which credential, under which policy, against which model, and with what downstream data exposure.

Practical implication: treat AI governance as an identity problem as much as a model-risk problem.

NHI Mgmt Group analysis

SB 53 is a signal that AI governance is becoming an identity governance problem. Once lawmakers require safety frameworks, risk assessments, and incident reporting, the organisation must prove who approved access, who operated the system, and who owns the evidence trail. That pulls IAM, IGA, and security operations into the same control plane. The implication is that AI governance can no longer be managed as a policy appendix to a model programme.

A fragmented state-level regime creates jurisdiction-aware access risk, not just compliance overhead. The same AI system may need different disclosures, approvals, or retention practices depending on where it is used or exposed. That makes static, one-size-fits-all governance models brittle. Practitioners should expect access and approval logic to become location-sensitive, because the audit question will increasingly be whether the right actor had the right rights in the right jurisdiction.

Identity blast radius: is the real AI governance metric when regulations multiply. The issue is not only whether a model is safe in isolation. It is how far sensitive data, privileged actions, and unreviewed changes can spread through the people and non-human identities connected to it. As frontier AI enters regulated operations, governance has to account for the full delegation chain. Practitioners should measure how far one approval can propagate across systems and jurisdictions.

The emerging control gap is not model intelligence, but evidence integrity. Regulations like SB 53 and the EU AI Act both push organisations toward documented accountability, yet many enterprises still cannot consistently tie access, model use, and incident handling into one reviewable record. That makes auditability the limiting factor, not technical capability. Practitioners should assume regulators will ask for proof of decision-making, not just policy intent.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• For practitioners building evidence-led governance, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next step for aligning access reviews, rotation, and offboarding.

What this signals

AI governance programmes will increasingly be judged on whether they can prove control ownership across human approvers and the non-human identities that execute tasks. In practice, that means jurisdiction-aware approvals, evidence retention, and access reviews must be designed together rather than managed in separate teams.

Identity blast radius: is becoming a useful operating concept for AI governance because regulations are forcing organisations to ask how far one approval can propagate through connected systems. If the blast radius is not measurable, the audit trail will be too thin to support rapid reporting or defensible oversight.

For practitioners

• Create a jurisdiction-to-control map for AI systems List where each AI use case operates, which laws apply, what evidence each regime expects, and which internal teams own approval and reporting. Tie that map to access control, retention, and incident workflows so governance does not vary by memory or local interpretation.
• Bind AI approvals to named human and non-human identities Require every significant AI deployment or model change to have a named owner, an approving human role, and the service identities that can modify or call the system. That makes the audit trail defensible when regulators ask who did what and under which policy.
• Review data access paths feeding model operations Inventory which identities can read training data, prompt data, logs, and exported outputs. Restrict those paths to the minimum set needed for operations, then verify that access revocation and recertification are actually enforced when projects, vendors, or use cases change.
• Align incident evidence capture to reporting obligations Define what constitutes a critical AI incident, what logs must be retained, and which teams can reconstruct the sequence quickly enough for regulatory reporting. If evidence lives in separate tooling, establish a single retrieval process before an incident forces the issue.

Key takeaways

• SB 53 shows that AI governance is becoming operational, evidence-driven, and tied to identity control.
• State-level fragmentation means the same AI system can trigger different access, disclosure, and reporting obligations.
• Organisations need jurisdiction-aware approvals, identity-linked ownership, and auditable incident evidence before regulators demand them.

Key terms

• AI governance: AI governance is the set of policies, controls, and accountability mechanisms used to manage how AI systems are approved, deployed, monitored, and retired. In practice, it combines risk management, legal compliance, security oversight, and evidence retention so organisations can prove responsible operation.
• Jurisdiction-aware control: A jurisdiction-aware control changes depending on where a system is deployed, accessed, or regulated. For AI programmes, that means approvals, logging, disclosure, and retention may need to vary by state or country rather than following one global rule set.
• Identity-linked accountability: Identity-linked accountability is the ability to tie an action, decision, or system change to a specific human or non-human identity. It matters because AI governance depends on proving who approved, who operated, and who can be held responsible when something goes wrong.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Lasso Security: Navigating the Patchwork, What California’s SB 53 Signals for AI Governance. Read the original.