On 5 February 2026, NIST's National Cybersecurity Center of Excellence published a concept paper and asked industry a set of questions about software agents. Four words carried most of the weight: the paper invited detailed feedback on the identification, authorization, auditing and non-repudiation of AI agents, alongside controls to prevent and mitigate prompt injection. The comment window closed on 2 April 2026.

The deadline was the least interesting part. The four words are the interesting part, because each one names an event rather than a document — and that distinction is where most agentic governance programmes quietly fail.

What the 2026 frameworks actually asked for

Three organisations set the terms of the agentic governance conversation this year, in separate publications.

Singapore moved first. On 22 January 2026, at the World Economic Forum in Davos, Minister for Digital Development and Information Josephine Teo launched the Model AI Governance Framework for Agentic AI, developed by the Infocomm Media Development Authority. IMDA built it on the governance foundations of its 2020 MGF for AI and structured it across four dimensions: assessing and bounding risks upfront by placing limits on agents' autonomy and their access to tools and data; making humans meaningfully accountable by defining significant checkpoints at which human approval is required; implementing technical controls and processes throughout the agent lifecycle, such as baseline testing and controlling access to whitelisted services; and enabling end-user responsibility through transparency and training. IMDA describes it as a living document and is separately developing guidelines for testing agentic AI applications.

NIST followed in February, twice. The NCCoE concept paper — authored by Harold Booth, William Fisher, Ryan Galluzzo and Joshua Roberts — framed the problem as one of applying appropriate identification and authorization controls to agents given access to diverse data sets, tools and applications. Twelve days later, on 17 February, the Center for AI Standards and Innovation announced the AI Agent Standards Initiative, organised around three pillars: industry-led standards development and US leadership in international bodies, community-led open source protocol development, and research in AI agent security and identity.

The OWASP Gen AI Security Project published version 2.01 of State of Agentic AI Security and Governance on 1 June 2026, positioning it as a practical guide to the frameworks, governance models and regulatory standards shaping agentic adoption.

Read together, these are not vague appeals to responsibility. They are unusually concrete. And that concreteness is what creates the problem.

Why all four controls are execution-path properties

Take non-repudiation. It means an agent — or the organisation operating it — cannot credibly deny having taken a particular action. Non-repudiation is not a policy. It is a property of a record that was created at the moment the action occurred, by something other than the actor, in a form that cannot be quietly revised afterwards. You cannot add non-repudiation to an agent retroactively, because the moment that would have produced the evidence has passed.

Authorization has the same shape. An authorization control is a decision rendered before a call proceeds, by a component that is not the agent. If the decision is made by the agent — because the constraint lives in its system prompt, or in an instruction its planner is free to reweight — then what exists is a preference, not an authorization. The word describes an interception, and an interception is an event in an execution path.

Identification is the ability to attribute an action to a specific agent rather than a shared service account, which requires the identity to be resolved at call time. Auditing is the systematic production of those attributed records. All four share a structure: each is a claim about something that either happened or did not happen at a specific point in an execution, and each is satisfied by machinery sitting in that path.

This is why agentic governance resists the compliance pattern that worked for earlier AI systems. A model risk programme could be substantially satisfied by documentation — model cards, validation reports, sign-off records — because the object under governance was an artifact that sat still. An agent does not sit still. It acts, and the governance question is whether the action was permitted, attributed and recorded at the instant it occurred. An organisation can write an excellent policy describing all four properties and have an auditor accept it while the running system produces none of them. The gap is architectural rather than procedural.

The practitioners arrived at the same place

Engineers building agents that take consequential actions reached this conclusion empirically, and earlier.

In an Ask HN thread from roughly six months ago, a developer building agents that issue refunds, write to databases and call APIs reported that prompt-level rules were not holding: instructions of the form "never do X" were being ignored when context grew long or users pushed hard. The responses converged on one architectural move. One commenter described separating what the agent wants to do from what it is allowed to do, with a deterministic check between proposal and execution, and observed that a refund is a deterministic business rule an LLM should not be adjudicating at all. Another reframed it as an execution boundary problem, describing the result as closer to a transaction firewall than a prompt guardrail — the model can reason however it likes, but anything that changes real state passes through a gate first.

These are individual practitioner accounts rather than survey findings, and should be read that way. But the pattern — propose, check outside the model, then execute — is the structure the frameworks specify in more formal language. IMDA's "significant checkpoints at which human approval is required" and a gate that refuses to commit until a deterministic condition is met are the same control, described from two altitudes.

The word that does the work is "required"

IMDA's phrasing repays close reading: defining significant checkpoints at which human approval is required. There are two verbs there, and they belong to different systems. Defining a checkpoint is a governance activity that produces a document. Requiring approval at that checkpoint is an enforcement activity that has to be implemented by something with the power to refuse.

A checkpoint that is defined but not enforced is a diagram. It appears in the architecture review, it satisfies the framework mapping, and it does nothing at three in the morning when an agent retries a payment loop. The distance between those two verbs is the distance between an agentic governance programme that works and one that reports.

How Waxell handles this

Waxell Runtime is the execution environment for workflows where being wrong is expensive — financial automation, healthcare, infrastructure operations. Policies gate what an agent is allowed to do before each step runs, rather than being evaluated after the fact, and the same 50+ policy categories available in Waxell Observe are enforced natively. That is the interception the word "authorization" describes, positioned where the framework language implies it has to be.

Runtime also implements the checkpoint verb directly. Workflows checkpoint automatically at every step, and a policy trigger that requires human input pauses execution and waits, then resumes from the exact point it stopped rather than from the beginning. A required approval is therefore a state the workflow is actually in, not a step someone is supposed to remember. Kill switches operate at the agent, workflow and session level — stopping any agent, any workflow, any session immediately, with no graceful shutdown. That is the enforcement counterpart to IMDA's dimension on bounding an agent's powers.

The identification and auditing half of NIST's list lands differently for the third-party agents your team runs but did not build — Claude Code, Cursor, Copilot and similar tools. Waxell Connect is the coordination and governance surface for exactly those agents, and it maintains the audit record: every handoff, every file version, every agent action is logged, so it is possible to establish what ran, what changed, and which agent or person did it — with no SDK and no code changes to the external agent. For an organisation answering NIST's identification and non-repudiation questions about agents it licenses rather than writes, that record is where the answer comes from.

Two notes on scope, because agentic governance claims are easy to overstate. Runtime governs agents built with the Waxell SDK; it is not a universal drop-in enforcement layer for arbitrary agents. And Connect's audit record covers the agents registered into it — coverage is configured, not automatic.

FAQ

What is agentic AI governance?

Agentic AI governance is the set of controls determining what an AI agent is authorized to do, how its actions are attributed and recorded, and how it can be stopped. It differs from model governance because the object being governed takes actions rather than producing outputs. The 2026 framework publications from IMDA, NIST and OWASP converge on controls that operate during execution rather than on documentation produced beforehand.

What four controls does the NIST concept paper name?

The NCCoE concept paper, published 5 February 2026, invited detailed feedback on the identification, authorization, auditing and non-repudiation of AI agents, along with controls to prevent and mitigate prompt injection techniques. The paper frames the underlying problem as applying appropriate identification and authorization controls to agents given access to diverse data sets, tools and applications. Public comment closed on 2 April 2026.

What does Singapore's Model AI Governance Framework for Agentic AI require?

The MGF for Agentic AI, launched by IMDA on 22 January 2026, offers guidance across four dimensions: bounding risks upfront by limiting agents' autonomy and their access to tools and data; making humans meaningfully accountable by defining significant checkpoints at which human approval is required; implementing technical controls throughout the agent lifecycle, including controlling access to whitelisted services; and enabling end-user responsibility through transparency and training. IMDA emphasises that humans remain ultimately accountable and treats the framework as a living document.

Why aren't prompt instructions enough to govern an agent?

Because an instruction inside the model's context is evaluated by the same system it is meant to constrain. Practitioners building agents that take consequential actions report that rules of the form "never do X" degrade when context grows long or when a user pushes. An enforced constraint requires a component outside the model that evaluates the proposed action and can refuse it. That is an architectural property, not a prompt-engineering problem.

Can an organisation pass a framework assessment and still be ungoverned?

Yes, and this is the practical risk. Identification, authorization, auditing and non-repudiation are inexpensive to describe in a policy and expensive to implement in an execution path. A documentation-based assessment inspects the description. Establishing whether the running system produces the four properties means looking at the execution itself — whether an action was intercepted, attributed and recorded at the moment it occurred.

Where should a team start?

Pick one agent that takes a consequential action and trace a single execution. Ask whether the authorization decision was made by something other than the agent, whether the resulting record identifies which agent acted, and whether that record could be quietly altered afterwards. Those answers locate the gap faster than a framework mapping, because they test the execution rather than the intention.

Sources

• NIST Computer Security Resource Center (Booth, Fisher, Galluzzo, Roberts), "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization" — Concept Paper, 5 February 2026

• NIST, "Announcing the 'AI Agent Standards Initiative' for Interoperable and Secure Innovation", 17 February 2026

• Infocomm Media Development Authority, "Singapore Launches New Model AI Governance Framework for Agentic AI", 22 January 2026

• OWASP Gen AI Security Project, "State of Agentic AI Security and Governance 2.01", 1 June 2026

• Hacker News, "Ask HN: How are you controlling AI agents that take real actions?"

The frameworks have done their part. Identification, authorization, auditing and non-repudiation are now written down by a national standards body, a national regulator and an open security project, in language specific enough to build against. What remains is deciding where in your stack those four properties are actually produced.

If the answer today is "in a document," see how Waxell Runtime gates each step of a governed workflow before it executes, and how Waxell Connect keeps the audit record for the third-party agents on your team, at waxell.dev/signup.