NIST Just Named Five AI Agent Identity Problems.

When the National Institute of Standards and Technology publishes a warning about enterprise AI agent security, CISOs pay attention. When that warning reads like a description of every governance gap we identified when we started building aizome, it is worth pausing to explain why.

NIST’s National Cybersecurity Center of Excellence published a blog post this week titled “Back to the Future: Why Agentic AI Needs a Strong Identity Foundation.” It names five specific identity and authorization practices that present substantial security challenges for agentic AI systems. It also announces a new NCCoE project specifically focused on software and AI agent identity and authorization.

I am not going to claim that NIST endorses aizome. What I am going to do is walk through each of the five problems NIST names and show you the architecture we built to address them. Because the architecture NIST says enterprises need is the architecture aizome already built.

Problem 1: Credential Sharing

NIST is direct: individuals giving their personal and enterprise credentials to agents has quickly become a common pattern. Credential sharing creates accountability gaps. It violates the core IAM tenet of accountability by verifying only the identity of the entity completing a transaction, not its permissions.

The aizome answer: every AI agent gets its own governed identity, separate from the human who built it. aizome’s identity broker assigns each agent a unique identity scoped to its declared purpose, not the permissions of the person who deployed it. The agent never operates on the human’s credentials. It operates on credentials specifically issued for the agent’s authorized function, within the boundaries of what the agent was built to do.

Problem 2: Static and Long-Lived Credentials

NIST identifies static API keys and long-lived access tokens as a persistent root cause of security incidents, made more dangerous by agentic AI. API keys provide broad, unscoped access. Long-lived tokens carry no cryptographic proof of possession. Any entity that gains access to the key can call the API.

The aizome answer: aizome’s MCP gateway operates as a vault. The AI agent never holds the credential directly. It holds a short-lived token to aizome’s system, which handles the authenticated connection to downstream applications on behalf of the agent, within its governed scope. The number of credentials the agent can expose is zero, because there is nothing to expose. This is not better credential management. It is a credential abstraction at the architecture layer.

Problem 3: Broadly Scoped Access

NIST identifies broad, role-based entitlements as a challenge that agents are set to exacerbate. Agents driven by high-level instructions can unpredictably seek, probe, and execute multiple paths to achieve their goals. Given broad access, they may use unexpected tools or data, leading to unintended damage.

The aizome answer: organizational intent capture. Every AI agent’s access is scoped not to the full range of what it is technically permitted to do, but to the specific purpose it was built to serve. The delta between what an agent is technically permitted to do and what it was built to do is the attack surface that most governance programs leave open. aizome closes it by defining organizational intent at provisioning and enforcing it at runtime, on every tool call, before the call executes.

Problem 4: Deploying Agents with Local User Accounts

NIST identifies local agent deployments running with local user credentials as a meaningful security challenge. Giving agents local account access allows them to impersonate the user and act with broad access. Local deployments make centrally managed agentic identity repositories difficult to implement and encourage poor practices, such as storing static credentials in local files.

The aizome answer: aizome’s light endpoint client extends centralized identity governance to local AI tool usage. Every agent operating on an employee’s workstation, through Claude Desktop, Claude Cowork, or any other local AI tool, is captured in the same agent inventory, governed by the same organizational intent framework, and subject to the same behavioral monitoring as agents deployed in cloud environments. The governance follows the agent, not the deployment model.

Problem 5: Relying on Human-in-the-Loop

NIST describes the consent fatigue problem precisely: overly chatty agents condition users to reflexively click “allow” just to keep their automated workflow moving. When users become habituated to approving access requests without review, the human-in-the-loop accountability it was meant to provide is undermined.

The aizome answer: continuous behavioral governance that makes human escalation targeted rather than universal. Instead of asking humans to review every agent action, aizome evaluates every action against the agent’s organizational intent baseline at the moment of execution. Human escalation is triggered only when the governance layer detects a deviation that requires judgment: actions outside the agent’s declared scope, behavioral drift from established patterns, or tool call sequences inconsistent with the agent’s defined purpose. Humans are in the loop for decisions that require human judgment. The infrastructure handles everything else.

The Market Signal: NCCoE Is Formalizing This

Beyond the five problems, what matters about this NIST post is the announcement at the end.

The NCCoE is launching a formal project on software and AI agent identity and authorization. It will produce blog posts, an online resource hub, and NIST publications to support adoption of IAM standards and best practices for software and AI agents.

This is the federal government formalizing what the market has been debating for two years. When NIST formalizes a problem space, three things follow: regulatory frameworks reference it, procurement requirements include it, and audit standards evolve to cover it.

The enterprises that have already built governance infrastructure around agent identity, runtime behavioral controls, and intent-based access will be the ones who can demonstrate compliance when those frameworks arrive. Those waiting for the standards to be finalized before building will be remediating under regulatory pressure.

NIST described the problems. SACR named the category for the infrastructure that solves them: ARISE, Agentic Runtime Identity Security Enforcement. aizome is the platform built to address all five NIST-identified challenges, deployed in production, available today.

The architecture NIST says enterprises need is not theoretical. It is running.

Come see it in action at aizome.ai

Amir Ofek is CEO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform and a founding player in the ARISE - Agentic Runtime Identity Security Enforcement - category.