TL;DR: New York’s RAISE Act creates the first U.S. state-level framework focused on frontier AI safety, requiring large model developers to disclose risks, incidents, and safeguards and exposing them to civil penalties of up to 30 million dollars, according to ActiveFence. The law shifts AI governance from voluntary reporting to auditable accountability, which will reshape how enterprises evidence observability, red teaming, and incident handling.
At a glance
What this is: New York’s RAISE Act is a frontier AI safety law that makes transparency, incident disclosure, and safeguards reporting a compliance obligation for the largest model developers.
Why it matters: It matters because AI, IAM, and security teams now have a clearer regulatory signal that model behaviour, logging, and oversight must be governable and provable, not just documented.
By the numbers:
- The RAISE Act focuses on frontier AI models trained with over 100 million dollars in compute resources.
- If a company fails to comply, New York’s attorney general can impose civil penalties up to 30 million dollars.
👉 Read ActiveFence's analysis of New York’s RAISE Act and frontier AI transparency
Context
Frontier AI regulation is moving from abstract debate to enforceable governance, and the RAISE Act is a clear marker of that shift. The law focuses on the highest-impact model developers, requiring evidence of risk management, reporting, and operational safeguards rather than informal assurances.
For security and identity practitioners, the important change is that AI systems are being treated as governed assets with accountability, auditability, and incident obligations. That intersects with identity programmes wherever model access, administrative control, logging, and delegated action need to be provable, especially as AI agents and AI-enabled workflows become part of production environments.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.
Q: Why do frontier AI systems require more than model cards and policy statements?
A: Because model cards describe intent, but regulators and auditors need evidence of testing, monitoring, and incident handling. Frontier systems can behave unpredictably in production, so organisations must prove how risks are detected, escalated, and documented. A written policy without runtime visibility leaves a compliance gap that becomes visible only after an incident.
Q: How do teams know if AI observability is actually working?
A: It is working when teams can show which change caused a quality shift, which dataset surfaced the issue, and whether the regression was contained before users were affected. If the team cannot trace behaviour across versions, observability is producing logs, not governance evidence.
Q: Who is accountable when an AI agent causes a security incident?
A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.
Technical breakdown
How frontier AI transparency becomes a control surface
The RAISE Act treats transparency as a measurable security control rather than a communications exercise. That means developers need documented safety reports, incident records, and evidence that model behaviour has been evaluated before and during deployment. In practice, this pushes AI governance toward continuous observability, traceability of harmful outputs, and structured escalation paths when model behaviour crosses policy thresholds. For enterprises, the implication is that model oversight must be measurable enough to survive regulatory scrutiny.
Practical implication: align model logging, safety review, and incident workflows so they produce audit evidence, not just internal notes.
Why red teaming and observability now sit inside compliance
Red teaming in this context is adversarial testing that tries to provoke unsafe, misleading, or policy-breaking model behaviour before users do. Observability is the runtime visibility needed to detect that behaviour once models are in production. The regulatory logic is simple: if you cannot show how a model was tested, monitored, and escalated, you cannot credibly claim safety governance. That matters for AI agents as well, because delegated actions can turn model failures into operational incidents.
Practical implication: make red teaming and runtime monitoring part of the formal control set, not a one-off pre-launch activity.
AI agents inherit the governance burden of the models they rely on
AI agents are software entities that can choose actions, tools, and timing at runtime, so their risk is not just model output but model-directed action. When a frontier model powers an agentic workflow, safety obligations extend into tool permissions, delegation boundaries, and monitoring of autonomous behaviour. That creates a new identity problem: the agent may not be human, but it still needs controlled access, traceable decisions, and accountability for what it does.
Practical implication: govern AI agents with the same seriousness you apply to privileged identities and high-risk automation.
Threat narrative
Attacker objective: The objective is to exploit or trigger unsafe model behaviour in a way that creates real-world harm, compliance failure, or downstream abuse of AI-enabled systems.
- Entry occurs when a frontier model or AI agent is deployed without sufficient pre-release safety testing or runtime monitoring, leaving unsafe behaviour undiscovered until production use.
- Escalation happens when the model or agent is able to produce harmful outputs, expose sensitive information, or drive automated actions beyond intended policy boundaries.
- Impact follows when those behaviours create regulatory exposure, safety incidents, or operational harm that must be reported and defended with evidence.
NHI Mgmt Group analysis
Transparency is becoming the new security boundary for frontier AI. The RAISE Act makes disclosure, incident reporting, and safety evidence part of the control plane, not a postscript to model release. That is a material shift for AI governance because it forces organisations to prove how they test and monitor models, rather than simply claim responsible behaviour. Practitioners should assume that governance will increasingly be judged by logs, reports, and escalation records.
AI governance debt is now a regulatory risk, not just an operational one. Teams that postponed structured oversight now face a compliance model that expects observability, red teaming, and incident handling to be embedded early. This is especially relevant where AI agents act on behalf of users or systems, because the governance burden extends to delegated actions and tool use. Practitioners should treat missing controls as a future audit finding, not a theoretical gap.
AI agents create an identity problem inside a safety law. When software can select actions and tools at runtime, the key question becomes who or what is authorised to act, under what constraints, and with what evidence trail. That intersects directly with IAM, PAM, and NHI governance because privileged machine action needs lifecycle control, not just model-level review. Practitioners should fold agent identity and privilege into AI governance from the start.
Named concept: model observability gap. This is the difference between having a model and being able to prove how it behaved, what it accessed, and when it crossed policy boundaries. The RAISE Act effectively penalises that gap by demanding evidence that can stand up to scrutiny. Practitioners should close it by connecting runtime telemetry, safety testing, and accountable ownership.
What this signals
Model observability debt will increasingly surface as a governance failure. As frontier AI systems move into regulated environments, teams will need evidence that can be reconstructed across prompts, tool calls, and downstream decisions. That makes runtime telemetry part of the control architecture, not just an engineering convenience.
Identity teams should expect AI agent governance to converge with privileged access management patterns, especially where tools, credentials, and delegated actions intersect. The practical challenge is no longer whether the model is capable, but whether its authority is bounded and reviewable in production.
For practitioners, the immediate signal is that AI governance programmes need tighter links to incident response, audit readiness, and account ownership. The organisations that will cope best are the ones that can prove who authorised the agent, what it accessed, and how quickly they can withdraw that access.
For practitioners
- Map AI systems to formal control ownership Assign named owners for model risk, incident escalation, and evidence retention so every frontier AI deployment has a clear accountability chain.
- Embed red teaming into release gates Require adversarial testing before production release and after major model changes, with test cases that probe unsafe outputs, policy bypass, and misuse paths.
- Instrument runtime observability for model behaviour Capture prompts, tool calls, policy decisions, and exception events so AI behaviour can be reviewed during investigations and regulatory reporting.
- Extend IAM and PAM controls to AI agents Treat agentic workflows as privileged actors by constraining tool access, narrowing delegation, and reviewing access lifecycles as part of identity governance.
- Build incident-ready reporting workflows Predefine the evidence set needed for regulator notification, internal triage, and executive review when unsafe model behaviour or model theft is detected.
Key takeaways
- The RAISE Act turns frontier AI transparency into a regulatory obligation, making evidence and accountability central to governance.
- AI observability, red teaming, and incident reporting now function as control requirements, not optional maturity markers.
- Identity and privilege controls must extend to AI agents if organisations want their governance model to hold under scrutiny.
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 address the attack surface, NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN | The article is about AI governance, accountability, and transparency obligations. |
| OWASP Agentic AI Top 10 | The post touches agentic AI misuse, observability, and tool-risk exposure. | |
| NIST CSF 2.0 | GV.RR-01 | The law drives accountability and risk reporting for AI systems. |
| NIST AI 600-1 | The article discusses transparency and safety requirements for GenAI systems. | |
| EU AI Act | Art. 9 | The transparency and safety posture parallels regulated AI risk management expectations. |
Assign clear governance ownership for frontier AI, evidence retention, and incident escalation.
Key terms
- Frontier AI model: A frontier AI model is a high-capability system near the cutting edge of what the market can deploy. In governance terms, it requires stronger assurance because its behaviour, misuse potential, and downstream impact can exceed the assumptions used for ordinary software release.
- AI observability: AI observability is the ability to see how AI systems are being used, what information they process, and what actions they trigger. In security programmes, it extends beyond uptime or model quality to runtime visibility, policy enforcement, and audit evidence across human and agent-driven use cases.
- Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
- AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
What's in the full article
ActiveFence's full article covers the regulatory detail this post intentionally leaves for the source:
- The exact scope test for frontier AI models, including the compute threshold used to define coverage.
- The reporting obligations for incidents, unsafe model behaviour, and model-weight theft under the act.
- The civil penalty exposure and enforcement authority assigned to New York’s attorney general.
- The practical compliance framing ActiveFence uses for developers, enterprises, and AI governance teams.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It helps security and identity practitioners build the control model needed for modern access and accountability.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org