---
title: "What Regulators Now Expect From AI Agents"
description: "In early 2026 NIST, six national cyber agencies, and an ISO management standard converged on the same demands for AI agents: least privilege, a verified per-agent identity, a kill switch, and an audit trail. All four live at the gateway."
canonicalUrl: "https://zuplo.com/blog/2026/06/15/what-regulators-expect-ai-agents"
pageType: "blog"
date: "2026-06-15"
authors: "nate"
tags: "API Security, ai-agents"
image: "https://zuplo.com/og?text=What%20Regulators%20Now%20Expect%20From%20AI%20Agents"
---
In the span of a few months, the people who write the rules stopped treating AI
agents as a research curiosity. Three developments brought it to a head:
| When | Who | What |
| ------------ | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feb 2026 | NIST National Cybersecurity Center of Excellence | Opened the [Software and AI Agent Identity and Authorization](https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization) project and a [concept paper](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd) on applying identity standards to agents. |
| May 1, 2026 | Six national cyber agencies (Australia's ASD's ACSC, US CISA and NSA, Canada's Cyber Centre, NZ NCSC, UK NCSC) | Published [Careful Adoption of Agentic AI Services](https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services). |
| In force now | ISO/IEC 42001 | The [AI management-system standard](https://www.iso.org/standard/42001) now gives auditors a framework to ask about all of it. |
None of these is binding on most teams today. Together they signal what an
enterprise security review will expect by year's end, and the expectations are
surprisingly specific.
## The four controls every framework asks for
Read the agentic-AI guidance and the same four demands surface in each, under
different headings.
**Least privilege.** The joint guide is blunt: "Privilege risks are a key
concern for agentic AI and strict adherence to the principle of least privilege
is critical." It tells you to "limit entitlements to the exact resources,
operations and timeframes needed," and warns first against broad access to
sensitive data.
**A verified identity per agent.** The guide walks through a confused-deputy
scenario, where one component is tricked into misusing its authority: an
over-privileged agent executes actions under a trusted identity, so "the system
produces audit logs that appear legitimate and delay detection." Its fix is to
replace static, long-lived credentials and treat agent identity as first-class.
That is the gap NIST's project names directly: identity and authorization for
agents, not credentials inherited from a human.
**A kill switch.** When an agent misbehaves, you need to stop it now, not at the
next credential rotation. The guidance leans on isolation and on revoking access
so one agent's failure does not cascade.
**A reconstructable audit trail.** Every framework assumes you can answer, after
the fact, which agent did what, on whose behalf, and when. ISO/IEC 42001 is a
governance standard, not a technical control, but a 42001 audit still asks you
to evidence those answers, and the evidence has to come from somewhere.
## The enterprise gap is real and measured
Few organizations can do any of this today. A 2026 analysis from Kiteworks,
[lining its survey data up against the CISA guidance](https://www.kiteworks.com/cybersecurity-risk-management/cisa-agentic-ai-security-guidance/),
maps directly onto the controls the frameworks demand:
- **63%** cannot enforce purpose limitations on AI agents (least privilege).
- **60%** cannot quickly terminate a misbehaving agent (kill switch).
- **55%** cannot isolate AI systems from broader network access (containment).
These are Kiteworks's vendor figures, not government data, so weigh them as
such. But the shape matches what the agencies warn about: the controls the
frameworks now expect are the ones most teams have not built.
## None of this is a model problem
Least privilege, per-agent identity, a kill switch, and an audit trail are not
properties of a model. They live at the boundary where the agent reaches a tool,
an API, or an MCP (Model Context Protocol) server. A smarter model does not get
you scoped credentials. A better system prompt does not give you a token you can
revoke in one place. We made the same argument from the containment side after
Anthropic's writeup, that
[the deterministic boundary is where control lives](/blog/anthropic-made-the-case-for-mcp-gateways).
This is why "we governed it in a policy document" does not survive an audit. A
policy that says agents should use least privilege is an intention. An auditor,
or an incident responder at 2am, wants the enforcement point and the log. "The
gateway rejected the call because the token was not scoped for that tool, and
here is the line that proves it" is an answer. A paragraph in a Notion page is
not.
Writing an agentic-AI policy and stopping there. A document describes the
control. The audit asks where it is enforced and where it is logged. If the
answer to both is not a system, the policy is a plan, not a control.
## How a gateway maps to the four controls
Put an API gateway in front of the tools and APIs your agents touch and the four
demands stop being aspirations.
| Control | How the gateway enforces it |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Per-agent identity | Each agent authenticates with its own OAuth identity instead of sharing a human's credentials or a service account, and every call carries that identity into the log. |
| Least privilege | The gateway curates which tools an agent can reach and binds tokens to a specific audience, so a token minted for one virtual server (a scoped front door to a single upstream) is rejected at another, enforced per request. |
| Kill switch | Revoke the agent's token and the next call fails at the boundary immediately, without touching the upstream system or waiting on a rotation window. |
| Audit trail | Every request is logged with the agent identity, the tool called, and the result, and you can export those events to your own SIEM (security information and event management system) through OpenTelemetry or a log plugin. |
A gateway makes you ready for what these frameworks ask for. It does not make
you NIST-certified or ISO 42001-compliant: those are organizational outcomes
spanning governance, process, and people, and no single product confers them.
What the gateway gives you is the enforcement point and the evidence the
frameworks assume you have, the part most teams are missing. We run our own
agents through this boundary, and the audit trail it produces is the same one we
would hand a reviewer. We have pulled an agent's token mid-run and watched the
next call get rejected at the gateway, with the upstream none the wiser, which
is the difference between a kill switch you can prove and one you hope works.
For the MCP plane, this is the same boundary we use to give agents
[per-consumer analytics and a per-call event stream](/blog/introducing-agents-analytics),
so "which agent did what" is a query, not an archaeology project.
The regulatory wave of early 2026 did not ask for anything exotic: least
privilege, a verified identity, a way to stop an agent, and a record of what
happened. Decide where you enforce those four before the security review does it
for you, because the answer they will accept is a boundary, not a document.