Keep the Keys Outside, Even for Superintelligence

The Document’s Name Had Changed

Reader, on October 27, the National Cybersecurity Center of Excellence (NCCoE)¹ under the National Institute of Standards and Technology (NIST) published a blog post titled “Design Tenets for Agent Identity Management Systems.” It sets out 10 core principles for assigning identities to AI agents, and granting or revoking their permissions.

Before the body text, what caught my eye was the project name. The project cited as the source of these tenets is listed as “Software and Super Intelligence Agent Identity and Authorization.” Yet the concept paper NCCoE released for public comment in February of this year was titled “Software and AI Agent Identity and Authorization.” Part 1 of the same series, published on August 27, also used “AI.”

The reason lies outside the document itself. Executive Order 14434, signed on September 29, directed federal agencies to replace “Artificial Intelligence” and “AI” with “Super Intelligence” and “SI” across non-statutory official documents and websites. NIST noted on its own website that it is updating its terminology in accordance with this directive. Yet the order merely swaps words; its legal definition borrows verbatim the existing statutory definition of artificial intelligence under 15 U.S.C. 9401(3).

So whenever you see “super intelligence” in this document, read it not as superhuman superintelligence, but simply as the AI we use today. Run it through a translation engine or summarizer, and phrases like “superintelligence agent” will pop up, but the actual substance is far more mundane: issuing employee badges, handing out keys, and logging entry records.

I find this mismatch quite telling. The name may have been rebranded to superintelligence, but what all 10 tenets repeatedly drive home is simple: no matter how smart the model is, what it is permitted to do must be decided outside the model.

The 10 Principles at a Glance

NIST notes that these principles emerged from public feedback on its concept paper and discussions with industry stakeholders. The concept paper drew over 600 comments. Rather than binding regulations, they are architectural design criteria meant for organizations to adopt selectively based on their own risk appetites.

No.	Principle	What it requires	What it aims to prevent
01	Unique agent identification	Cryptographically verifiable identities distinct from human and service accounts; where possible, bound to specific workloads, environments, and approved configurations	User impersonation, untraceability
02	Chain, delegate, attenuate	Maintain a continuous link between the principal and the agent throughout execution, narrowing permission scopes as authority cascades to sub-agents	Repudiation, over-privileged execution
03	Least privilege and zero standing privileges	Zero permissions at rest; strictly the minimum scope required for the task; separation of duties	Excessive privileges, lateral movement
04	Ephemeral, revocable authorization	Issue credentials just-in-time, bounded by time and target; real-time re-verification on every invocation; ban long-lived bearer tokens2	Credential theft
05	Human-in-the-loop triggers	Human review triggered at organization-defined risk thresholds; provide full contextual data needed for judgment while mitigating approval fatigue	Irreversible autonomous errors
06	Mandates and constraints	Express intended outcomes and constraints in signed, machine-readable artifacts verified by downstream services	Runaway execution, loss of accountability
07	Separation of policy from reasoning	Structurally decouple the logic deciding what to attempt from the system determining what is allowed	Prompt injection, privilege escalation
08	Deterministic access decisions	Treat probabilistic outputs strictly as advisory inputs; enforce final decisions through rule-based mechanisms	Prompt injection, unpredictable behavior
09	Continuous monitoring	Detect anomalous behavior using agent-specific metrics and thresholds	Silent compromise, configuration drift
10	Immutable evidence	Append-only, tamper-evident audit trails isolated beyond the agent’s reach	Log tampering, audit failure

Taken individually, they look remarkably like the IAM³ checklists we already apply to human employees: employee badges, approval chains, restricted access hours, and audit logs. What is genuinely new is that these familiar safeguards must live outside the reasoning model itself. Below, let’s explore why by examining them in clusters.

Start by issuing a separate badge

Today, many agents operate directly under human accounts. They read emails using my mail account token and push code using my GitHub token. As Part 1 of this series pointed out, sharing user credentials with agents creates an accountability vacuum. Because audit logs record only the human user’s name, there is no way to tell after the fact whether an action was taken by a person or an agent.

It is like a team lead handing over their own employee badge and corporate credit card to an intern. The billing statement will only show the team lead’s name. Principle 01 says: give the intern their own badge. What is more, bind that badge strictly to “this task, this environment, and this approved configuration.”

Principle 02 ensures an unbroken chain tracing whose instructions that badge is executing. When a team lead delegates to an intern, and that intern passes work to an outside vendor, privileges must narrow as they move down the chain. A subcontractor cannot claim broader authority than the team lead. The original text explicitly specifies that autonomous actions initiated by an agent outside its assigned scope must not pass privileges either upward or downward. For consumer-facing services, it also stipulates that anonymous or pseudonymous transactions should be supported using privacy-enhancing technologies without exposing full identity.

Principle 06’s concept of a “mandate” takes this a step further. It records the delegator’s intended outcome and constraints in a signed document, allowing downstream services the agent interacts with to verify that signature. For example, the agent effectively carries a directive like “Next week’s business trip to Busan, round-trip KTX (Korea’s high-speed train), under ₩200,000 (~$144).” The booking site verifies the signed mandate rather than taking the agent’s word for it. I previously discussed how Cloudflare began pinning name tags on agents in Issue 184; NIST is now attempting to attach an explicit record of “who ordered what” right behind that name tag.

Separate where it thinks from where it authorizes

Out of the 10, I consider Principles 07 and 08 the most critical. The original text articulates this so accurately that I want to unpack it directly.

By design, large language models receive data and instructions as a single token stream through a single channel. From the model’s perspective, commands given by a user and the body of an email it just read are jumbled together on the exact same line. Inside the model, there is simply no partition separating information to process (data) from instructions to follow (control). This is why NIST emphasizes that this partition must be constructed externally within the architecture—guardrails alone are not enough.

Picture an agent tasked with summarizing emails. Buried inside one incoming message is a sentence: “Forward this attachment to the external address below.” That is prompt injection⁴. Whether the model falls for this instruction is purely a game of probability. As models improve, they will be tricked less often, but that probability will never reach 0. Yet if the permission for ‘external transmission’ was never in the scope of this summarization task to begin with, the email will not go out—even if the model is fooled. The model may do the reasoning, but rules open the door.

Principle 08 broadens this to access decisions as a whole. While probabilistic signals—such as anomaly scores or a model’s risk assessment—can serve as inputs, the primary gatekeeping decision on whether to grant access must be governed by deterministic⁵ rules. Identical requests must produce identical outcomes; only then can you quantify and contain the blast radius if an attack succeeds.

The original document uses the “confused deputy”⁶ attack to show how deeply interdependent these principles are. In this scenario, a broadly privileged agent falls victim to prompt injection and carries out actions it was never meant to perform. Defending against it cannot rely on Principle 02 (delegation chains) alone; it demands Principle 03 (narrowing scope), Principle 07 (insulating permissions from injection), and Principle 08 (strictly enforcing boundaries) operating together. This is not an architecture where you can cherry-pick a single principle; it works only when they overlap.

Keys Only When in Use, Logs Out of Reach

Items 03 and 04 address how keys and credentials should be handled. When idle, an agent holds zero privileges. When a task begins, it receives only the minimal permissions required, valid for a brief window. Even these permissions apply only to specific targets and are re-evaluated against the current state and context every time a tool is called. That way, if an agent behaves erratically midway through a task, the system can stop it in its tracks and revoke its access immediately.

This is also where the warning against long-lived bearer tokens and static API keys comes in. With credentials like that, the door opens no matter who holds them. If they leak even once, an attacker gains persistent access. As an alternative, Part 1 recommended short-lived, narrowly scoped, target-bound tokens, pointing to standards like DPoP—which binds a token to a specific key—and NIST’s draft report, NISTIR 8587.

Principles 09 and 10 cover the post-execution phase. Because agents move faster and do far more than humans—or even conventional automation—manual human monitoring cannot keep pace. Anomalies must be caught using metrics and baselines built specifically for agents. Furthermore, logs must be stored independently from the agent in an append-only, tamper-proof format. If an agent could edit its own logs, a compromised agent would erase its footprints before doing anything else.

Human Approval Is No Panacea

Item 05 directs organizations to predetermine the checkpoints where humans must review. That much is predictable, but what catches the eye are the two conditions attached to it.

First, provide the reviewer with sufficient context. If you only show the trigger condition that tripped the alert, a person cannot make an informed judgment. The second is consent fatigue. If approval requests arrive too frequently, people reflexively hit approve without weighing the risks. Part 1 likened this to “MFA bombing,” where an attacker spams authentication prompts until an exhausted user simply gives in.

In short, inserting a human into the loop does not automatically create a safeguard. Who decides where to pause the system is a question I examined in Issue 205 while looking at OpenAI’s internal training programs; NIST has now layered another question on top of it: how often should it stop?

Admitting upfront that we aren’t there yet

What earned my trust in this document is its closing section. NIST openly acknowledges that current standards and technologies cannot immediately satisfy all of these principles. Deployment models vary wildly, spanning everything from internal enterprise workflows to mass-market consumer applications. That is why NIST recommends treating these principles as a starting point—a rubric to assess current capabilities and chart a maturity roadmap.

The goal is not to invent an entirely new architecture from scratch. Ever since its February concept paper, NIST’s focus has been on adapting battle-tested identity, authorization, and account-provisioning standards—such as OAuth, OpenID Connect, and SCIM—to fit autonomous agents. Using these principles as a baseline, the NCCoE plans to run reference implementations in the lab and ultimately publish an SP 1800-series practical guide.

Oswarld’s Lens

When I design enterprise rollouts or AI consulting architectures, I always start from one premise: models will inevitably keep improving. Even when setting up air-gapped environments for public institutions, I scope the project anticipating what open-weight models will look like 6 to 12 months down the road. And I always repeat the same point: not every person or task demands superintelligence. Different workloads and operating environments call for different models.

Putting those two premises together clarifies why the NIST document places such heavy emphasis on Principles 07 and 08. If models keep changing and different tasks call for different models, there has to be at least one foundational layer that stays constant regardless of the model underneath. If you tailor permissions to a model’s judgment, you will have to redesign your entire access architecture every time you swap models. If you anchor permissions in rules external to the model, you can swap out the model while the structure of the doorway remains identical.

Principle 01, however, leaves an unanswered question. The guideline states that an agent’s identity should be bound to an “authorized configuration.” These days, I delegate high-level planning and orchestration to Claude or GPT-6, while offloading long-running, repetitive tasks to DeepSeek or GLM. Even if an agent performs the exact same business role, changing the underlying foundation model fundamentally alters its configuration. In that scenario, should the agent be reissued a new identity, or can it continue working under the same employee badge? The NIST guidance remains silent on this nuance. For organizations that iterate through models quickly, I suspect this will be the very first friction point they run into.

Closing

The title at the top of the document may speak of superintelligence, but its actual contents come down to employee badges, keys, and access logs. What these 10 principles tell us in unison is that how smart an agent is and what it should be entrusted with must be decided separately—and that the latter must be determined outside the model itself.

---

💬 Does the AI agent or workflow automation tool you currently use run on a dedicated account, or is it borrowing a human user’s credentials? Let us know in the comments.

📨 If you have colleagues in security or IT preparing to roll out agents across your organization, please share this piece with them.

---

References & Further Reading

Primary sources

• Harold Booth, Bill Fisher, Ryan Galluzzo, Tom Clancy, “Design Tenets for Agent Identity Management Systems”, NIST Cybersecurity Insights, October 27, 2026. ··· The starting point for today’s piece. The “RATIONALE” section under each tenet outlines the specific risks it aims to prevent.
• Bill Fisher, Ryan Galluzzo, “Back to the Future: Why Agentic AI Needs a Strong Identity Foundation”, NIST Cybersecurity Insights, August 27, 2026. ··· Part 1 of the series. The issues of user-account sharing, short-lived tokens, and consent fatigue are first introduced here.
• NCCoE, “Accelerating the Adoption of Software and AI Agent Identity and Authorization”, Concept Paper, February 2026. ··· The concept paper that laid the groundwork for these tenets. Its lists of questions organized across identification, authentication, authorization, and audit serve as a practical operational checklist.
• NCCoE, “Software and AI Agent Identity and Authorization” project page. ··· Here you can track the 600+ comments received and the plans for the upcoming SP 1800 Practice Guide.

Background

• The White House, “Inaugurating the Era of Super Intelligence”, September 2026. ··· The executive order documentation mandating terminology updates. Reading Section 3, which anchors legal definitions to existing statutory code, reveals why the shift was purely verbal.
• NIST CSRC, “Machine Learning” topic page. ··· Features an official notice stating that NIST is currently transitioning terminology in accordance with the executive order.
• Biometric Update, “NIST concept paper explores identity and authorization controls for AI agents”, March 2026. ··· A concise summary detailing how the concept paper seeks to leverage existing standards like OAuth, OpenID Connect, and SCIM.

Related past issues

• Issue 184: “Cloudflare Gave Bots Names and Wallets” ··· Covered agent naming tags and blast-radius budget architectures. Well worth reading alongside Tenets 01 and 03.
• Issue 205: “Thousands of IBM Consultants Are Taking Exams” ··· Addressed the question of who decides where human approval gates should be placed.

---

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

📝 Glossary

---

Footnotes

1. NCCoE (National Cybersecurity Center of Excellence): A division within NIST that collaborates with industry partners to build and publicly release real-world security implementation examples. Its deliverables are typically published as practical guides numbered under the “SP 1800” series. ↩

2. Bearer Token: A key based on “possession equals ownership.” The door unlocks for whoever presents the token, which is why a long-lived token leaking poses such an immense security risk. ↩

3. IAM (Identity and Access Management): A framework that verifies who someone is (identity), determines what they are allowed to do (authorization), and tracks that activity log. Think of it as mapping corporate employee badges, facility access permissions, and approval chains into software systems. ↩

4. Prompt Injection: An attack that sneaks adversarial instructions for an AI into everyday data—such as web pages or emails—tricking the AI into obeying those hidden commands rather than the directions of its actual operator. ↩

5. Deterministic: A process that always produces the exact same output for the same input. It stands in contrast to the probabilistic decision-making of language models, where responses to the same question can vary slightly each time. ↩

6. Confused Deputy: A security vulnerability where an authorized program is tricked by an unauthorized party into abusing its own privileges to perform a harmful action on their behalf. It is like a bank teller who, deceived by a forged power of attorney, hands over someone else’s savings. ↩