%201.svg)
HIPAA Compliance Checklist for 2025
TL;DR
- Every major AI governance framework was written to govern what a model produces. An agent is judged by what it does, and that difference is why the frameworks you already run do not cover the agents your teams are shipping.
- A 2026 survey of generative AI security found that frontier safety policies, the NIST AI RMF, ISO/IEC 42001 and the EU AI Act contain no references to agents or agentic systems at all.
- Singapore moved first. IMDA released the Model AI Governance Framework for Agentic AI on 22 January 2026 and published version 1.5 on 20 May 2026 after feedback from more than 60 organizations.
- The United States is early. NIST's Center for AI Standards and Innovation launched its AI Agent Standards Initiative on 17 February 2026, and finalized agent guidance is unlikely before 2027 while adoption accelerates through this year.
- The gap has a name your security team already understands. The NCCoE concept paper frames it directly: agents are commonly treated as generic service accounts, with no dedicated identity, authorization or accountability controls.
- Until the standards land, govern agents the way you govern any other login that is not a person. CloudEagle.ai discovers every AI app, agent and MCP server across your stack, attaches an owner and an expiry to the credentials behind them, and puts them in the same review cycle as your employees.
Pick up any AI governance framework in circulation today and you will find it asks a consistent question: is this model's output fair, accurate, explainable and safe. That question was the right one in 2023.
It is the wrong one for a system that books the refund, merges the pull request, or queries the customer database at three in the morning without anyone watching.
What Do Today's AI Governance Frameworks Actually Govern, and Where Do They Stop?
Today's frameworks govern models and the uses people put them to. They ask how a system was trained, what it outputs, who it might harm, and how a human reviews that output.
They stop at the point where the system stops answering and starts acting.
The Model and Use Assumption Behind NIST AI RMF, ISO 42001, and the EU AI Act
All three were built on the same picture of AI: a model produces something, a person decides what to do with it. Each is good at what it was drafted for, and none was drafted for a system that holds credentials and calls other systems on its own.
The Missing Vocabulary in Existing Framework Text
The clearest evidence is what the documents do not say. Search the text of the three frameworks most enterprises have standardized on and the word "agent" is absent.
That is not a drafting oversight, it is a timestamp. The frameworks predate the products:
- Anthropic launched Computer Use in October 2024
- OpenAI released Operator in January 2025
- Claude Code reached general availability in May 2025
- None of them shipped under a binding agent-specific governance standard
The practical consequence for you is narrow and specific. Your framework tells you how to assess a model you licensed.
It tells you nothing about the agent your engineering team built on top of that model last quarter, or the credential that agent is using right now.
Why Autonomous Agents Break the Assumptions Behind Existing AI Frameworks
Agents break four assumptions at once. Each one is load-bearing for how a model-era framework works, and each one fails differently when the system acts on its own.
Agents Take Actions in Live Systems, Not Just Produce Outputs
A model that writes a bad summary has produced a bad summary. An agent that misreads the same input sends the email, closes the ticket, or pushes the change.
Output-centered review has no equivalent checkpoint for the second case, because by the time anyone reads anything, the action has already happened.
Tool Access, Memory, and Multi-Step Plans as a New Risk Surface
Agents differ from models on properties that governance frameworks never had to account for:
- They act on external systems and reach tools dynamically, so the risk surface changes at runtime
- They execute multi-step plans, so a small early error compounds instead of stopping
- They carry persistent memory, which can be manipulated
- They hand work to other agents, which splits accountability across boundaries
That last one is what hurts during an incident. When three agents pass a task between them and something goes wrong, "which system did this" has no clean answer.
Agent Credentials Treated as Generic Service Accounts
This failure shows up in real environments long before any regulator gets involved. Agents get whatever credential was easiest to issue, which is usually a shared API key or a service account built for software that does not make its own decisions.
The mental model is already out of date. In most environments the majority of logins that are not people are now agents rather than service accounts, created in low-code platforms that never touched an IT provisioning workflow.
The federal standards work says so plainly:
- Enterprise deployments commonly rely on manually managed access lists, shared API keys and service account credentials designed for software systems rather than autonomous agents
- The result is an authorization chain that nobody can follow after the fact
- Agents end up without dedicated identity, authorization or accountability controls
Which points at the fix, and it is not a new framework. If the problem is that agents are unmanaged logins, manage them as logins: inventory them, give each one an owner, scope it, expire it, and review it on a cycle.
What Singapore Did About Autonomous Agents
Singapore wrote a framework for actors instead of outputs. The IMDA framework, unveiled in January 2026, is the first governance model in the world specific to agentic AI, and it covers organizations that build agents internally as well as those taking them from a third party.
The IMDA Model AI Governance Framework for Agentic AI and Its Four Dimensions
The framework is organized around four dimensions rather than model lifecycle stages. Read them against a model-era framework and the shift is obvious: these are questions about authority and scope, not about output quality.
What Version 1.5 Added on Multi-Agent Risk and Automation Bias
The January release was not the end of it. Version 1.5, published on 20 May 2026, kept the four-pillar structure and added guidance on multi-agent systemic risk, more granular technical controls, and case studies showing how organizations applied the framework in practice.
Two additions deserve your attention:
- The update addresses multi-agent systems, third-party agents and automation bias
- It raises what happens to your own team's competence when agents absorb entry-level work, including skill degradation and the loss of knowledge needed to run critical processes manually when agents fail or become unavailable
That second point is one almost nobody else in this conversation is making, and it is an operational risk, not an ethics footnote.
Agent Identity and Authorization Trails as a Stated Requirement
The part that matters most for security and IT is that Singapore made identity explicit.
The framework recommends that each agent have a unique identity tied to the supervising agent or user it acts for, so accountability can be traced, supported by an audit trail of which agent acted under whose authorization.
You can act on that this quarter without waiting for anyone to finalize anything.
The framework is voluntary, but the control it describes is concrete, and it reduces to three things: know which agents exist, know who each one answers to, and be able to reconstruct what each one did.
How NIST and the EU Are Catching Up to the Agent Gap
Both are moving, and neither has arrived. NIST has opened a dedicated standards workstream and named the identity problem precisely. The EU applies existing obligations to agents without treating them as a category of their own.
The NIST AI Agent Standards Initiative and the NCCoE Agent Identity Concept Paper
The initiative exists because the current stack was found wanting.
Community feedback held that NIST AI RMF, NIST SP 800-53 and ISO/IEC 42001 do not adequately address the risk surface created by agents taking autonomous, real-world actions.
Note what the NCCoE paper implies about the direction of travel.
The federal answer to agent governance is being built out of identity infrastructure, not out of model risk assessment, which is the same conclusion the previous section reached from the operational side.
EU AI Act Coverage of Agents Under Articles 14 and 15
Europe covers agents by extension rather than by design. The Act's definition of an AI system refers to varying levels of autonomy, which pulls agents in, and the high-risk obligations then apply.
Coverage is not the same as guidance:
- As of early 2026 the AI Office had published nothing specifically addressing AI agents, autonomous tool use or runtime behavioral change
- The AI Act Service Desk described regulatory considerations on agents as preliminary
- Harmonized technical standards for high-risk systems have been delayed to late 2026 and are not yet final
The Timing Gap Between Agent Deployment and Finalized Standards
Here is the number to plan around. Finalized NIST agent guidance is unlikely to arrive before 2027, while enterprise agent adoption accelerates substantially through 2026.
- Waiting for completed standards leaves you reactive, with real technical debt to unwind later
- Nothing stops you applying the controls the draft work already agrees on, and the recommended interim move is mapping current deployments to the AI RMF functions you already run
- The organizations that come out of this well treat the next eighteen months as a design window rather than a waiting room
How Do You Approach AI Agent Governance Before the Standards Are Final?
You govern agents as identities. Every draft that has looked hard at this problem, in Singapore and at NIST, arrives at the same place: an agent is an actor holding credentials, and the controls that work are the ones you already apply to accounts.
Four of them are available to you now.
Building an Inventory of Agents and the Credentials They Hold
Start with the count, because most organizations cannot produce one. The inventory has to cover more than the agents your platform team registered, and it has to be continuous rather than a quarterly audit, because agents appear between review cycles.
- Agents built in-house on Azure AI Foundry, Bedrock or an open framework, then exposed over an API
- Agents that arrived inside a SaaS tool you already pay for, switched on by a product team
- Third-party and vendor agents acting on your data under a contract nobody read for autonomy language
- MCP servers connecting agents to enterprise systems, along with who authorized each one and what it can reach
- The API keys, service accounts and tokens each of those holds, and what each key can reach
The last line is the one that matters. An agent inventory without the credential attached tells you what exists but not what it can do.
Assigning an Owner and an Expiry Date to Every Agent Identity
An agent with no named owner is an agent nobody will retire. Ownership is what converts an inventory into something you can act on, and expiry is what stops the inventory growing forever.
- Name a human accountable for each agent, matching the meaningful human accountability dimension Singapore set out
- Scope the credential to what the agent's job actually needs, not what was convenient at creation
- Set an expiry date at the moment of creation rather than promising a cleanup later
- Record what the agent is for, so the next reviewer is not guessing
Extending Access Reviews to Logins That Are Not People
Most access review programs certify employees and quietly skip everything else. That is the single largest gap between how mature your identity governance looks on paper and how much of your actual attack surface it covers.
Agents belong in the same cycle as your people: the same cadence, the same reviewer routing, the same evidence capture.
Reviewing employees quarterly while service accounts and agent tokens go unreviewed for years leaves you certifying the smaller half of the problem, and the mechanics of extending certification to logins that are not people are well understood at this point.
This is the part of AI agent governance CloudEagle.ai handles for you.
We discover the AI applications, agents and MCP servers running across your stack, surface the service accounts and API keys behind them with owner, scope and last activity attached.
Additionally bring them into continuous access reviews alongside your employees, with expiry dates applied at creation.
The result is a governance record you can hand to an auditor without a spreadsheet exercise.
Armorcode did exactly this with us, taking visibility across their logins that are not people from 40 percent to 95 percent, remediating 480 unmanaged accounts and scoping down more than 220 that carried more access than their function required.
See Every AI Agent and Credential in Your Stack
Where Visibility Ends and Enforcement Begins
Be honest with yourself about what this class of control does and does not do, because the distinction shapes what else you need.
Discovery, ownership, scoping, expiry and review govern what an agent is permitted to hold. They do not intercept an agent mid-action and stop a specific decision as it happens.
Runtime interception is a different control layer, usually a proxy or a gateway sitting in the traffic path.
Treat that as a sequencing principle rather than a disclaimer. You cannot enforce policy on an agent you cannot see, and most organizations are still short of the inventory.
Get the identity layer right first, then decide whether usage enforcement at the point of behavior or full runtime interception is worth what it costs you in latency and complexity.
What Should Security and IT Leaders Do About AI Governance Frameworks Now?
Do not start over. The framework you already run stays useful, it just has to be extended to cover actions and access rather than only outputs.
Mapping Existing Agent Deployments to a Framework You Already Run
If you have adopted the NIST AI RMF, the functions still hold. What changes is their scope.
The Singapore framework is worth reading alongside it even if you never adopt it formally. It is currently the most detailed public description of what bounding an agent actually involves.
Choosing an AI Governance Framework When Agents Are in Scope
If you are selecting an AI governance framework now rather than extending one, judge candidates on four questions rather than on certification value alone.
- Does it treat the AI system as something that acts, or only as something that outputs
- Does it require an identifiable owner for each autonomous system
- Does it say anything about agent identity, credentials and authorization trails
- Does it address what happens when agents delegate to other agents
Most frameworks in circulation answer the first question and stop.
Singapore's answers all four, which is why it is the reference point in this conversation even for organizations with no Singapore footprint. NIST is heading the same way, and the shape of what lands in 2027 is already visible in the NCCoE identity work.
Whichever framework you land on, the controls underneath it are the same set, and the practical challenges of governing autonomous agents are worth working through before you commit to a certification path.
The organizations that will pass that audit comfortably are the ones that spent the interim building the agent inventory, not the ones that spent it reading drafts.
Close the Gap While the Standards Catch Up
.avif)
.avif)
.avif)
.png)
