NIST's ten agent tenets: a guardrail is not a control, and a tired approver is not oversight

If your agent's limits live in its system prompt, NIST just told you they are not limits. Its new design tenets for agent identity say the part that decides what an agent is allowed to do must sit outside the part that reasons, and that "guardrails alone are insufficient"¹. Read the list as a test of your setup, not a reading assignment, because four of the ten you can pass or fail today.

NIST published the ten tenets on Tuesday 27 October, as the second post in a series on agent identity, authentication and authorization¹. They are proposals, not a standard. NIST calls them "an initial set" and says they "will be the guideposts" for agent demonstrations at its National Cybersecurity Center of Excellence (NCCoE)¹. Treat them as the questions your security reviewer will be asking about agents next.

/01The four you can check this week

07: what the agent wants is not what the agent may do. NIST's reasoning is short. A language model takes data and instructions "as a single stream of tokens through a single interface", so the separation has to come from architecture, so that injected or untrusted data "cannot manipulate credentials or expand the agent's actual permissions"¹. An invoice your agent reads can rewrite its plan. It must not be able to rewrite its limits. If "never pay a new bank account without review" is a sentence in the prompt, the invoice and the rule share one channel. NIST's own example is the confused deputy: an injection talks an agent with broad access into an action it would not otherwise take¹.

08: the yes or no is a rule, not a guess. Probabilistic signals can feed an access decision but are "not used as the primary mechanism"¹. A risk score from a second model can flag a payment. A written rule decides whether it goes.

05: escalation has to survive real volume. Each organization sets thresholds that send agent actions to a human, routes them "to the correct authority", and gives that person enough context to decide, which "may require context outside" what triggered the hold¹. Then the line most governance decks skip: escalation flows must be "cognizant of consent fatigue", where review comes so often "that agentic actions are approved habitually"¹. Picture a queue of a few hundred holds a week, each one a bare "approve?". That is not human oversight. It is a click-through with a name on it.

10: the record lives where the agent cannot reach. NIST asks for "append-only" evidence of the agent's identity, the intent it was given and what it did, kept in logging "independent of the agent"¹. The reason: if the agent can modify its logs, "a compromised agent could tamper with log files, deleting or changing its actions"¹.

/02The ones that need more than a config change

Tenets 01, 02 and 06 ask for cryptographically verifiable agent identities, links from each agent back to the person who started it, authority that shrinks as it passes to sub-agents, and signed "mandate statements" stating intended outcomes and constraints¹. NIST says plainly that not all tenets "will be immediately fulfilled by the current state of standards and technology"¹.

That should not stall the rest. The first post in the series names the habits that break tenets 01, 03 and 04 with tools you already have: handing agents your own credentials, long-lived API keys left "in-the-clear" in configuration files and logs, and running agents under a local user account so they "impersonate the user" with its full access². A separate login per agent, a token that expires when the task does, and an account scoped to one job are all available now.

/03What to change

1. /01

   Move every limit out of the prompt. Any rule that lives only in the agent's instructions is a wish. Put the money, the vendor list and the allowed actions in a layer the model cannot edit.

2. /02

   Measure your hold rate before you add holds. Count the actions a week that would reach a person, and the minutes each needs. If the answer is "most of the approver's day", raise the threshold or improve the evidence attached to each hold. Habitual approval is a failure NIST now names.

3. /03

   Send each hold with its reason and its documents. The approver should see the rule that fired, the original request and the record being changed, without opening three systems.

4. /04

   Check who can write to the log. If the agent's service account has write or delete rights on its own audit trail, fix that first. It is one permission change.

5. /05

   Write down the intent. You cannot sign mandates yet. You can record, per run, who started the agent, what they asked for and the limits it ran under. It is a first step toward tenet 06 without the cryptography, and the first thing you will want after an incident.

That is the layer Gatehouse runs. Each agent acts under its own identity and limits, the rules sit outside the agent, anything outside them waits for a named approver with the case attached, and every action lands on a record the agent cannot touch.

Start with one question for your busiest agent: if a document told it to raise its own limit, what would stop it?

Want the next one? News with a take, three times a week. Follow by RSS →