Table of Contents
NIST’s new tenets treat agent security as an identity problem. Here’s what they ask for, why they only work as a set, and how to put them into practice, one agent action at a time.
NIST just published its initial set of 10 design tenets for agent identity. If you’re responsible for securing AI agents, it’s worth a careful read. It’s also good news.
Much of the agent security conversation so far has focused on the model: what it might say, what it might hallucinate, how to fence it in with better prompts. NIST starts somewhere else. It treats agents as identities, and asks for the same discipline you’d expect of any identity: credentials of their own, access scoped to the job, a human in the loop when it counts, and a record of what they did.
“Guardrails alone are insufficient.”NIST, Design Tenets for Agent Identity Management Systems
NIST isn’t alone here. In May, six national cyber agencies, including CISA, the NSA and the UK’s NCSC, published joint guidance on adopting agentic AI that lands in the same place: give every agent its own identity, and swap static secrets for short-lived ones. When that many security agencies point the same way, it’s worth paying attention.
NIST is upfront that this is a starting point. The tenets grew out of public feedback on its NCCoE agent identity project and build on the first post in its agentic identity series. NIST also says plainly that today’s standards won’t cover every tenet in every deployment. So the useful question is how to put them into practice, and where to start.
The Tenets Only Work Together
It’s tempting to read ten tenets as ten projects. NIST’s own example shows why that doesn’t hold up.
Take a confused deputy attack, where a prompt injection talks an agent with broad access into doing something it shouldn’t. NIST notes that stopping it takes four tenets working at once: linking the agent to whoever tasked it (02), least privilege to limit what it can reach (03), policy kept outside the model (07), and deterministic decisions to enforce the scope (08). Drop any one of them, and the attack has a way around the other three.
There’s a practical lesson in that. When identity, access, approvals and logging each live in a separate tool, every hand-off is a chance to lose context: which agent, acting for whom, under which policy. The ten tenets read best as one connected chain, so that’s how this guide treats them.
To keep it concrete, we’ll follow one request all the way through: an EMEA sales analyst asks an agent to pull regional figures from the data warehouse and update a record in the CRM. Simple on the surface. Along the way, it touches every one of the ten tenets.
One Agent Action, Four Checkpoints
Follow the analyst’s request from start to finish and it passes the same four checkpoints, in the same order. Every one of NIST’s tenets lands on one of them.
1
Identify the Agent
- 01Distinct agent identification
- 02Linking, delegation & attenuation
2
Decide Access
- 03Least & zero standing privilege
- 04Short-lived, dynamic & revocable authorization
- 08Deterministic access decisions
3
Enforce Policy
- 05Human-in-the-loop triggers
- 07Separation of policy from reasoning
4
Watch and Record
- 06Mandates and constraints
- 09Continuous monitoring
- 10Immutable evidence
1Identify the Agent and Whose Authority It Carries
What NIST proposes
Every agent gets its own verifiable identity, separate from people and service accounts, and ideally tied to a specific workload and configuration. It stays linked to whoever gave it the task, and its authority can only shrink as work passes to sub-agents and downstream services.
The challenge
Most agents don’t start life with an identity of their own. They borrow one: a developer’s API key, a shared service account, a token pasted into a config file. From there, every call looks the same, and “which agent did this, and for whom?” has no clean answer.
Joint guidance from CISA, NSA, NCSC-UK and partners · May 2026
Six national cyber agencies advise building “each agent as a distinct principal” and keeping a trusted registry of every agent. They also warn that actions taken under a trusted agent identity can look legitimate in the logs.
How to do it
Inventory your agents and the identities behind them, not just the apps they show up in: owners, MCP connections, service accounts, credentials, and what each one can reach. Then, for every task, pin down whose authority the agent is using. The same sales agent might serve the EMEA analyst in the morning and a finance lead with much broader access in the afternoon. If both requests run on one shared credential, what the agent can do has little to do with who’s asking.
Where Hush fits
- An identity and an owner for every agent. Hush finds agents across your environment and registers each one to an accountable human owner.
- Access that follows the user. The Hush Security Identity Gateway ties every action to the user the agent is acting for. The agent’s entitlements come from that user’s.
- Permissions scoped per user, per app. Agents don’t inherit their user’s broad permissions. Role-based, delegated and on-behalf-of controls keep every action scoped to the task, enforced in real time.
- Chains you can follow. Surface agent-to-agent connections, so you can trace any action back to the human who started it.
2Decide What It Can Touch, at Runtime
What NIST proposes
Idle agents hold no standing privileges, and active ones get only the scope the task needs. Access is granted just in time, expires on its own and is aimed at one specific target. No long-lived bearer tokens, no reusable secrets. And the access decision stays rule-based: AI-driven signals can inform it, but they don’t make the call.
The challenge
Standing access is the default for a simple reason: scoping it per task by hand doesn’t scale. So long-lived keys pile up in dotfiles, IDE configs and agent memory. And since rotating a shared key breaks every agent that depends on it, nobody’s in a hurry to rotate it.
Datadog, State of Cloud Security 2025 · Oct 2025
59% of AWS IAM users have an active access key that’s more than a year old.
Joint guidance from CISA, NSA, NCSC-UK and partners · May 2026
Recommends replacing static, long-lived secrets with ephemeral credentials, and requiring just-in-time credentials for privileged actions.
How to do it
Make the access decision when the agent acts, not when it logs in. Authenticating an agent at the start of a session doesn’t authorize everything it does after. Weigh the agent, the person it’s acting for, the target and the operation, then grant the narrowest access that fits, make it temporary, and keep the ability to revoke it. The sales agent may be able to query the entire warehouse. Acting for the EMEA analyst, it should only see EMEA data. And short-lived doesn’t mean safe. An ephemeral credential with too many permissions is still overprivileged.
Where Hush fits
- Least Agency. Access is scoped to the task and granted just in time, not handed out up front.
- No static secrets. Hush brokers short-lived credentials at runtime, scoped to the action.
- Three rule-based checks on every call. Is this user assigned to this app? Is this tool allowed, held for consent, or blocked? Is this agent type permitted? Reads default to Allow, writes to Consent and destructive actions to Block, and you can tune each tool.
- No silent gaps. A tool that hasn’t been catalogued inherits its app’s default policy instead of slipping through.
- Policy as code. Manage gateway apps, consent methods and the MCP catalog with the Hush Terraform provider. Write Access Manager policies as Kubernetes or Terraform manifests.
3Enforce Policy Outside the Model
What NIST proposes
Risky actions go to the right person for review, with enough context to make a real decision, and not so often that people approve on autopilot. What an agent tries to do is decided separately from what it’s allowed to do.
The challenge
An LLM reads data and instructions through the same channel, so a prompt injection can steer an agent from inside its own context. Any control that lives in the prompt lives inside the thing being attacked. Approvals have their own weak spot, too: ask too often, and people stop reading before they click yes.
UK NCSC · Dec 2025
Warns that prompt injection may never be fully mitigated, and advises limiting its impact with deterministic, non-LLM controls on what a system can do.
OWASP Top 10 for LLM Applications · 2025
Ranks prompt injection as the number one risk.
Anthropic · Mar 2026
Reports that users accept 93% of Claude Code’s permission prompts, a pattern it calls approval fatigue.
How to do it
Instructions in the prompt help, but the same model that reads them also reads untrusted content. A prompt injection may change what the agent tries to do. It must not change what it’s allowed to do. So enforce access outside the model, and decide up front which operations run freely, which need a person to approve, and which are off the table. For the sales agent: reading an account record just runs, updating it asks the analyst first, and a bulk delete is blocked. Save approvals for the actions that matter, so people keep reading them.
Where Hush fits
- Enforcement outside the agent. The gateway checks every tool call against policy before it reaches the app, with no changes to the agent or the MCP server. It runs independently of both.
- Approvals where they count. By default, reads flow, writes ask first and destructive actions are blocked. If you move a destructive tool to consent, the consent screen flags it, so the reviewer knows what they’re approving.
4Keep Watch and Keep the Evidence
What NIST proposes
Agent activity is monitored continuously, with signals built to catch anomalies, drift and privilege escalation. Whoever tasks an agent can issue a signed mandate that sets its intended outcome and limits, and downstream services can verify it. Alongside that sits an unbroken, tamper-evident record of who the agent is, what it was asked to do and what it actually did, kept apart from the agent so a compromised one can’t rewrite its own history.
The challenge
A typical system log tells you an API was called. It rarely tells you which user’s agent called it, under which policy, or whether it should have been allowed. And logs that live where the agent runs are logs the agent can reach.
Joint guidance from CISA, NSA, NCSC-UK and partners · May 2026
Lists rogue agents altering logs among the risks, and recommends isolating agents so they have no write access to logs.
NIST NCCoE concept paper · Feb 2026
Names tamper-proof, verifiable logging of agent actions and intent as an open question for the field.
How to do it
By the end of the task, the agent has pulled figures, changed a CRM record and maybe called other services along the way. Could you explain exactly what happened? Keep the thread that connects who asked, which agent acted, what it tried, which policy applied and what the result was. Watch agent activity as it happens, not only after the fact. And keep the record somewhere the agent can’t touch.
Where Hush fits
- Runtime Intelligence. Hush shows what agents are connecting to now, what they’ve been doing and which access is actually used versus just granted.
- Limits set before the agent acts. Every governed app carries assignment rules, per-tool permissions and an agent allowlist, so what any agent may do there is defined up front and checked on every call.
- A record of every call and its policy decision. The Activity log captures the user the agent acted for, the agent, the app, the tool, the outcome and the time.
- Any session, reconstructed. Request IDs and session IDs let investigators audit exactly what an agent did in a given interaction.
- Kept outside the agent. The gateway produces the record, independent of the agent and the app.
Where to Start
Skip the ten-column spreadsheet. Start by following one real agent action, ideally one that already touches important systems, from the person who asked to the data it reached. At each checkpoint, ask: Do we know which agent this is, and whose authority it carries? Does its access match that authority at every step? Is the decision enforced outside the model? Could we reconstruct it afterward?
The gaps show up fast. Maybe the agent is known, but its service account is overprivileged. Maybe approval happens once at the start of a session and never again. Maybe the log shows an API call with no user attached.
NIST frames the tenets as a roadmap, not a checklist, so close those gaps in the order that fits you. Two paths work well, and both end up in the same place: all ten working together.
Path A
Fastest Wins
Quick progress, without rewriting your agents.
- Find every agent and its owner. Know what’s running before you govern it.01
- Set per-tool rules. Allow reads, require consent for writes, block destructive actions.05 · 08
- Record every call. Who, which agent, what tool, what outcome.09 · 10
Path B
Biggest Risk Reduction
Goes after the highest-impact risks first, even if it takes longer.
- Retire static secrets. Swap long-lived keys for short-lived, task-scoped access.03 · 04
- Tie every action to a person. Make sure every agent call is logged against the user it acted for.02
- Move policy out of the model. Enforce what agents may do outside the prompt, tool by tool.07 · 08
These aren’t ten unrelated problems. They’re breaks in one chain of trust.
See Where Your Agents Stand
Hush finds your agents, governs their access at runtime and records every action, all from one place.
Book a DemoNIST’s design tenets are an initial proposal and will keep evolving as the NCCoE project moves forward. Read the original: Design Tenets for Agent Identity Management Systems.