SecureWorld News

NIST's 10 Tenets for Securing Agentic AI Identities

Written by Cam Sivesind | Mon | Nov 2, 2026 | 6:59 PM Z

AI agents are getting the keys to the enterprise, and in many organizations, they are getting them the worst possible way: borrowed from a human.

Survey data from the Cloud Security Alliance (CSA) and Aembit, published in March, found that 31% of organizations let AI agents operate under a human user's identity, and 43% rely on shared service accounts. Some 68% can't reliably tell agent activity apart from human activity in their logs, and 74% say agents often receive more access than they need. ConductorOne's 2026 Future of Identity Report found that 47% of organizations now have more non-human identities than human users, but only 22% have full visibility into them.

Into that gap, U.S. NIST has published what it calls an initial set of "Design Tenets" for agent identity, authentication, and authorization. Released October 27 on NIST's Cybersecurity Insights blog, the 10 tenets are written by Harold Booth, Bill Fisher, and Ryan Galluzzo of NIST and Tom Clancy of MITRE. They draw on public comments to the National Cybersecurity Center of Excellence (NCCoE) project on software and AI agent identity and authorization, plus extensive stakeholder engagement.

The tenets are not a standard, a mandate, or a checklist. But they are the clearest statement yet from NIST about what "good" looks like for agentic IAM (Identity & Access Management), and they will serve as the guideposts for the NCCoE's upcoming agentic demonstrations. That makes them a de facto roadmap for buyers, practitioners, and the vendors selling to both.

The backstory: Old problems, new speed

The tenets are the second post in a NIST series. The first, published in August by Fisher and Galluzzo, made a pointed argument: early agentic deployments are repeating a familiar pattern of prioritizing features and immediate value over security.

That post catalogued the failure modes already showing up in the field. Users hand their personal and enterprise credentials to agents. Teams stand up proofs-of-concept on long-lived API keys and bearer tokens that, as NIST put it, do not prove identity. Agents get broad, role-based access. Local agents run under a developer's own account. And organizations lean on human approval prompts until users start clicking "allow" reflexively, a dynamic NIST compared directly to MFA fatigue attacks.

NIST's conclusion was that none of these problems are new. They are the same issues that have plagued identity systems for decades, now amplified by agents operating at a speed and scale no human workforce can match. The design tenets are NIST's answer to what should replace those habits.

The 10 design tenets

NIST frames each tenet with a description and the primary risks it mitigates. They cluster naturally into four themes.

Know who the agent is, and who it's working for.

1. Distinct agent identification – Every agent gets a unique, cryptographically verifiable identity, distinguishable from human users and service accounts, and ideally tied to a specific workload, environment, and approved configuration. Agents need their own identity and credential lifecycle, separate from the humans they serve. The point: stop agents from impersonating people, and make autonomous actions traceable to a specific software component.

2. Agent linking, delegation & attenuation – Agents and the people or organizations that task them stay cryptographically linked throughout execution. As authority flows down to sub-agents and downstream services, scopes shrink, so no downstream entity can ever claim more authority than its parent. For consumer scenarios, NIST calls for support of anonymous or pseudonymous transactions using privacy-preserving technology where appropriate. Without this linkage, NIST warns, organizations face severe non-repudiation problems where high-impact actions can't be attributed to anyone.

Give agents as little power as possible, for as short a time as possible.

3. Least & zero standing privilege – Agents hold no persistent rights when idle. Access is bounded to the minimum required for a specific task and constrained by separation of duties, so an agent can't accumulate conflicting privileges that let it route around governance controls.

4. Short-lived, dynamic & revocable authorization – All access is just-in-time, time-bounded, and audience-specific. Beyond that, NIST says every tool invocation, API call, or resource access should face continuous runtime verification against current context and risk. Long-lived bearer tokens and static, reusable secrets are out. The rationale is blunt: without runtime checks, an agent holding a valid token can't be interrupted if it's hijacked mid-task.

(See number 5 a little lower down where it's more applicable.)

6. Mandates and constraints – Whoever tasks an agent—whether a human, another agent, a service account, or an organization—can issue cryptographically signed "mandate statements" defining the intended outcome and the constraints on how to reach it. Downstream services can verify those mandates and use them in authorization decisions and audits. In consumer settings, mandates should avoid disclosing unnecessary sensitive information about the user.

Keep the model out of the access decision.

7. Architectural separation of policy from reasoning – This may be the most consequential tenet. The logic that decides what an agent tries to do must be architecturally separated from the systems that decide what it's allowed to do. NIST's reasoning goes to the heart of how large language models work: they take in data and instructions as a single stream of tokens, with no native separation between the two. That separation therefore has to be enforced by architecture, with policy enforcement wrapped around the agent. NIST's verdict on the alternative is short: guardrails alone are insufficient.

8. Deterministic access decisions – Access decisions should rest primarily on deterministic mechanisms. Probabilistic signals, including AI-generated risk scores, can inform a decision but should not make it. Determinism, NIST argues, limits the blast radius of prompt injection and makes agent behavior around sensitive data and tools predictable.

"In my book, 'Gears Don't Guess,' I tell the story of PocketOS, a software company that serves car rental businesses. In April 2026, an AI coding agent deleted its production database, and the founder says it took nine seconds. Its cloud provider later recovered the data from separate backups," said Kip Boyle, author of "Gears Don't Guess" (available on Amazon). "The agent's written rules barred destructive Git commands unless the user asked, and the agent later wrote that deleting the database was far worse. A written rule like that is just instructions. On its own, it isn't a control. That's what tenet 7 gets right: enforcement has to sit outside the AI's reasoning. So when a vendor says it has safeguards, ask, 'Where on your API surface are your safeguards NOT applied?'"

Watch everything, and keep the receipts.

5. Human-in-the-loop triggers – Organizations define risk thresholds that kick sensitive actions to a human, with enough context for a real decision. Critically, NIST says escalation design must account for consent fatigue, where approvals become so frequent they're granted out of habit rather than judgment.

9. Continuous monitoring – Agents operate at a scale and velocity beyond humans and even most deterministic automation. Monitoring needs agent-specific metrics, thresholds, and policies to catch compromise, configuration drift, and privilege escalation. NIST flags that the risk climbs with long-running agents and agents that act across many tools.

10. Immutable evidence – Organizations keep a tamper-evident, append-only record of the agent's identity, its delegated intent, and its resulting actions, on logging infrastructure independent of the agent itself. The logic is simple: a compromised agent that can touch its own logs can erase its tracks.

No single tenet does the job

NIST is explicit that tenets work in combination. Its example is the "confused deputy" attack, where a prompt injection convinces a broadly-privileged agent to do something it shouldn't. Linking and delegation helps, but stopping that attack also requires least privilege, separation of policy from reasoning, and deterministic access decisions working together.

NIST is equally candid that today's standards and technology won't satisfy every tenet yet, particularly across the full range of enterprise and consumer deployment models. It positions the tenets as a starting point for organizations to assess current capabilities and build a roadmap.

What it means for organizations

Start with an honest IAM baseline. NIST's first post argued that one of the most important things any organization can do is take a clear-eyed look at its current IAM practices against existing standards, because every gap will be magnified at agentic scale. If service account sprawl, standing privilege, and token hygiene are already problems, agents will make them worse, not better.

Inventory agents as identities, not features. Tenet 1 implies something many organizations can't do today: answer how many agents they run, who owns each one, and what each can reach. The CSA research note on agentic identity, published in June, found that 51% of organizations report no clear ownership of AI identities, and 16% don't track when new ones are created at all. An agent registry with named owners is table stakes.

End credential sharing with agents. The 31% of organizations letting agents run under human identities are breaking attribution at the root. Tenets 1 and 2 make this a first-order fix.

Apply the tenets by risk, not all at once. NIST says the tenets should be implemented according to the risk of the agentic transactions being supported, the operating environment, and the data, tools, and skills involved. An internal summarization agent and an agent that moves money or modifies production code warrant very different controls.

Revisit how procurement and governance treat AI. If an agent platform's only answer to "how do you constrain this agent?" is a model-level guardrail, tenets 7 and 8 suggest that's not an acceptable answer for high-impact use cases.

"When an AI coding agent deleted PocketOS's production database, the API token it used could do everything from adding customer domains to deleting whole data stores," Boyle said. "If no token within the agent's reach had carried delete rights, that call would have failed. So, audit every token your AI can reach, including ones sitting in files. Does each one give the AI only the permissions the work requires? Then, before any dangerous action, build in a pause that waits for a named person to say yes."

What it means for cybersecurity professionals

IAM fundamentals just got more valuable. NIST's framing is that the secure agentic protocols of the future will be built on today's established standards. Practitioners fluent in OAuth 2.0, SPIFFE, workload identity, and zero trust architecture are already holding most of the toolkit. NIST's first post pointed to existing and emerging building blocks, including Demonstrated Proof-of-Possession (DPoP) for sender-constrained tokens, Rich Authorization Requests for granular scopes, Transaction Tokens for carrying authorization context across call chains, and the OpenID Foundation's AuthZEN authorization API.

Threat modeling has to include the reasoning layer. Tenet 7 reframes prompt injection as an access-control problem, not just a model-safety problem. Security architects should design on the assumption that any agent processing untrusted input can be steered, and place enforcement points where the agent's choices meet real systems.

Detection teams need agent-aware baselines. Tenet 9 calls for agent-specific metrics and thresholds. Behavioral analytics tuned for humans won't flag an agent that makes 10,000 legitimate-looking API calls in an hour. SOCs will need new baselines, and logs that can actually distinguish an agent from the human it serves.

Human-in-the-loop is a design discipline, not a safety net. Tenet 5 puts the burden on security teams to set escalation thresholds that are rare enough to get real scrutiny. A prompt that fires on every action is not oversight.

Expect the "identity is enough" debate to continue. Public comments on NIST's first post previewed the hard questions. Jon-Rav Shende, CTO of Thales, noted that authorization happens at a point in time while execution keeps moving, as agents switch tools, delegate, or find new paths to a goal. Venkat Raghavan, Co-Founder & President of LangGuard.AI, went further, arguing that permissions control an agent's reach but not what it does with that reach. These are commenter perspectives, not NIST positions, but tenets 4, 6, and 9 read as NIST's attempt to close exactly that gap through runtime verification, signed mandates, and continuous monitoring.

What it means for vendors and solution providers

The tenets are a buyer's evaluation rubric, whether NIST intended it or not. Expect RFPs and security questionnaires to start mapping to them directly. Vendors should be ready to show, tenet by tenet, what their products support today and what's on the roadmap.

Model guardrails won't satisfy the architecture. Tenets 7 and 8 draw a firm line: policy enforcement must sit outside the reasoning engine, and access decisions must be primarily deterministic. Solutions that rely on an LLM to police itself, or that make probabilistic risk scores the final word on access, will face skepticism from informed buyers.

Static secrets are a liability on the spec sheet. Tenet 4 explicitly rejects long-lived bearer tokens and static reusable secrets. Agent frameworks and integrations that still depend on pasted API keys are now on the wrong side of NIST's stated direction.

Interoperability is the opportunity. Tenets 2 and 6 depend on identity, delegation, and mandates traveling across vendors, agents, and services. No single product can deliver end-to-end attenuation or verifiable mandates alone. That favors vendors that build on open standards and participate in efforts such as the IETF's Workload Identity in Multi-System Environments (WIMSE) work, which NIST cited in its first post.

The NCCoE project is the place to engage. NIST says the tenets will guide its agentic demonstrations, which will explore how standards and technology can meet them across enterprise and consumer use cases. Vendors that want to shape the reference architectures, rather than react to them, should be part of that work. Commenters on NIST's first post, including Colin Constable, CTO & Co-Founder of Atsign, have already publicly expressed interest. One line from Constable's comment captures the vendor challenge neatly: the fix is "making the safe thing the path of least resistance."

Consumer identity is the hardest frontier. NIST's first post acknowledged that consumer scenarios are tougher because enterprises have little control over the agent's identity and may not even be able to tell an agent from a human. The FIDO Alliance is exploring agent authenticators bound to user identities, but NIST described that work as early. Vendors who solve privacy-preserving agent identity for consumers, as tenets 2 and 6 envision, will be addressing a genuine gap.

NIST's 10 tenets don't introduce exotic new concepts. Distinct identity, least privilege, short-lived credentials, separation of duties, and tamper-proof logs are the same principles the IAM community has been preaching for years. What's new is the insistence that they apply to agents just as rigorously as to people, and the recognition that an agent's reasoning engine cannot be trusted to enforce its own boundaries.

The organizations that treat agents as first-class identities now will be the ones able to scale them safely later. The ones still handing agents a human's password are building the next generation of breach headlines.