Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

NIST has published no AI agent authorization standard, and nothing in its February 2026 draft gives an auditor a control to test. What the NCCoE did publish is more useful to a CISO with an audit on the calendar: five areas of interest that read like an assessor’s question list. Together they ask which agent acted, on whose behalf, under what authority, and with what record. A Kubernetes cluster has a primitive it can point to for each area.

The board wants to know which AI agent risk to fund first, and a likelihood score cannot answer it. No incident survey gives base rates for agents on your architecture, and an agent can take a different path on the same input. What a CISO can estimate is what each risk would cost to recover from: the work to detect it, scope it, revoke the authority it used, and prove what happened. Ranked on that cost, unexpected code execution drops toward the bottom.

The agent that worries you is authorized. It holds a service account you provisioned, calls tools you approved, and reaches destinations someone signed off on. Zero trust asks two questions at every decision point, who is this and what are they allowed to do, and an agent redirected by trusted input answers both correctly every time. For a person those questions fire at a session boundary, where context gets re-checked. An agent on Kubernetes has no such boundary.

An agent’s logs are written by the agent. Every framework log, trace span and tool-call record that an agentic AI security platform ingests comes from the process being watched, or from a gateway that sees only what that process routes through it. When a trusted prompt coerces an agent into misusing a permission it already holds, the record shows a normal tool call, because from inside the process it was one. Running more analysis on that record returns the same answer faster.

Identity governance cannot tell you which AI agent did something. It records which identity is allowed what. In a cluster, one service account often serves several workloads, and every pod is replaced at the next rollout. As a result, the permission record and the behavior record point at different objects. Detection and investigation need a unit of attribution. The Deployment is the right one. It stays stable across restarts and replicas and changes only when someone ships a rollout.

Two of the three layers of agentic AI security already have an owner in your organization, and the third has none. Identity falls to IAM and interaction falls to AppSec, because the controls at both layers extend products those teams already run. The behaviour layer covers what the agent does on the infrastructure once it is running, and it sits between a platform team with no security mandate and a SOC with no sense of what normal looks like for an agent. That gap is where a coerced agent works.

A browser agent in your cluster opens a supplier portal, screenshots it, and clicks somewhere the task never called for. The page looks exactly like the page the supplier serves, and to the person who checks it later, it still does. The classifier in front of the agent returned nothing, because the instruction that produced the click does not exist.

The blast radius of a prompt injection against your coding assistant was set weeks ago, by whoever built the dev environment image. Same assistant, same model, same injected sentence: on a laptop it collects every repository, SSH key and cloud login the developer holds; on a provisioned dev box it collects an organization token plus whatever the image left behind; on a CI runner it collects a deployment credential and a network path to production. Three environments, three incidents, one payload.

Every action in your agent-incident runbook operates on the agent. The payload of a RAG prompt injection sits in the index. You can kill the pod, rotate the credential and revoke the session, and each of those stops this workload from doing that thing again. None of them touch the chunk that caused it.

Tool output is untrusted because your own systems produce it. That is the part of the OWASP guidance that never makes it into a deployment. The label goes on web pages and email bodies, where an outsider obviously wrote the text. It never goes on the ticket store, the CRM, or the repo, because those are yours. The attacker does not care whose system it is. He cares which field takes free text: the ticket body, the opportunity note, the PR description.

Your coding agents run overnight on cloud dev boxes, with auto-approve on and an organization token in the environment, and the only thing standing between a public repository and that token is whatever the repository’s README tells the agent to do.