Why CISA's Agentic AI Guidance Stops at the Design Phase — and What Your Security Design Review Needs to Cover Instead

On April 30, six government cybersecurity agencies — CISA and the NSA in the US, Australia's ACSC, Canada's Cyber Centre, New Zealand's NCSC, and the UK's NCSC — published Careful Adoption of Agentic AI Services, the first multi-nation guide to securing autonomous AI agents. Thirty pages. Five risk categories. Recommendations spanning design, development, deployment, and operations.

‍

Read it closely and a pattern shows up fast: almost every control that actually matters — verifying an agent's identity on every call, catching behavioral drift before it compounds, isolating a compromised agent before it poisons its peers — is something you can only confirm at runtime. Not at design time. Not in the one meeting where your security team signs off on an architecture diagram and moves on to the next review.

‍

That's the gap. Not that CISA ignored operations — it didn't. Its "Operating agents securely" section runs pages deep on monitoring, human-in-the-loop checkpoints, and continuous privilege verification. The gap is that the instrument most security teams use to gate an agentic system before it ships — the security design review — was built to answer a different question than the one agentic AI is asking.

Why runtime and agent-to-agent trust break traditional SDR assumptions

A traditional SDR checks a static system. Does this data flow encrypt in transit? Is there input validation at this boundary? Does this service run with the permissions it's supposed to have? You verify it once, at a point in time, against an architecture that isn't supposed to change its own behavior.

‍

Agentic systems break every one of those assumptions.

‍

CISA's own scenario examples make the case better than any outside critique could. In one, an organization grants a procurement agent broad access to financial systems and email, evaluates permissions once at deployment, and moves on. Other agents come to implicitly trust its outputs. When a malicious actor compromises a low-risk tool wired into that agent's workflow, they inherit its excessive privileges — and because the actions run under a trusted agent identity, the audit logs look legitimate. CISA names this the "confused deputy" pattern. In another, a support-ticket triage agent continues acting on a cached authorization decision from startup, even though the correct behavior would be to re-verify per request. The agent moves laterally into billing and refunds before anyone notices.

‍

Neither failure would show up in a design review that checks whether an access-control policy exists. Both only show up once the system is running, under conditions nobody designed for.

‍

The guidance says this almost in passing, in a sentence that should worry anyone who still treats a design review as a one-time gate: "Even when prompts appear identical, agents may generate different actions due to stochastic model behaviour, variations in context windows, or dynamic environmental inputs, further complicating reproducibility and assurance."

‍

Non-reproducibility isn't a footnote. It's the reason a sign-off on Tuesday tells you almost nothing about what the system will do on Friday.

‍

Meanwhile, the infrastructure most organizations would need to catch this in production doesn't exist yet. The Cloud Security Alliance's 2026 research — published alongside the CISA guidance — found that 82% of organizations have discovered AI agents in their environment they didn't know were there, 65% have had at least one agent security incident in the past year, and only 21% have a formal process for decommissioning an agent when it's retired. Only 18% of security leaders say they're highly confident their identity and access management can actually govern agents. Only 16% run continuous monitoring; 59% rely on periodic (daily or weekly) review, and more than two-thirds of organizations can't reliably distinguish an agent's actions from a human's in their own logs.

‍

Those aren't adoption numbers. They're the reason a design review that stops at "does this architecture look right on paper" isn't doing its job anymore.

A design review framework for agentic systems

The fix isn't a new checklist item. It's a shift in what the review is actually trying to verify — and, increasingly, a shift from a one-time gate to something closer to continuous threat modeling: not whether a control exists in a policy document, but whether the architecture makes that control checkable once the system is live, and stays checkable as it changes. Four areas carry most of the risk.

‍

Identity and permission inheritance. Is each agent a distinct, cryptographically anchored principal — its own keys, its own registry entry — or is it riding on a shared service account? CISA is blunt about this: static API keys and shared credentials are "explicitly inconsistent" with its guidance, yet they remain the dominant credential model in production deployments. The harder question for a design review: are permissions evaluated at every invocation, or cached once at startup? A stale "allow" decision is exactly what let CISA's support-ticket agent move laterally. If your architecture can't answer "what permissions does this agent have right now, and why," it fails this test regardless of what the access policy says on paper.

‍

Sandboxing and blast radius. When — not if — an agent misbehaves or gets compromised, what's the actual containment boundary? CISA recommends isolating high-risk agents into separate enclaves with no write access to shared logs, and rate-limiting or circuit-breaking components to stop a single degraded agent from consuming the resources of the whole system. A design review should ask for the blast-radius diagram the same way it asks for the data-flow diagram — and should treat "we haven't tested what happens if this agent is compromised" as a blocking finding, not a follow-up item.

‍

Sub-task delegation boundaries. Agentic systems don't just call tools — they spawn sub-agents and delegate work down chains that weren't fully specified at design time. CISA's recommendation is to codify separation of duties explicitly: distinct "Orchestrator," "Reader," and "Actuator" roles, consensus requirements scaled to the stakes of the action, and expiry timers on any delegated grant so a sub-agent's authority doesn't quietly outlive its task. The review question isn't "can this agent create sub-agents" — it's "what happens to the permissions of a sub-agent this agent creates, and who's accountable for what it does."

‍

Agent-to-agent trust. This one doesn't have a real precedent in traditional application security — or rather, it's an old problem wearing a new costume. Security teams have spent the last several years learning to make implicit trust explicit between microservices: stop assuming a service is safe just because it's internal, verify instead of trust by default. Agentic systems hand you the same problem one layer up — "agent assumes agent's output is true" instead of "service assumes service is safe" — at a layer almost nobody's auditing yet. CISA's structural-risk section describes exactly how it fails: agents that implicitly trust upstream outputs, a hallucinated result from one agent accepted as fact by the next, a compromised or malicious tool injecting instructions that propagate peer-to-peer. The guidance's answer is that trust should never be inherited transitively — every agent's claims should be verified, not assumed, and inter-agent calls should be authenticated with mutual TLS rather than implicit network trust. A design review needs to trace at least one full delegation chain end to end and ask, at each hop: what happens if the agent one step upstream is wrong, or lying?

What to ask in your next review

None of this requires waiting for tooling to mature. It requires asking different questions at the review you're already running.

‍

Ask whether each agent has its own identity, or whether it's sharing credentials with three other services and a human. Ask whether permissions are checked per action or cached at startup — and ask for evidence, not an assertion. Ask what the blast radius is if this specific agent is compromised today, and whether anyone has actually tested that scenario rather than just diagrammed it. Ask what happens to a sub-agent's permissions after its parent task completes — and whether there's an expiry timer or just an assumption that someone will clean it up. Ask which upstream agents this system trusts implicitly, and why. And ask the question CISA's own data implies most organizations can't yet answer: if this agent behaves differently tomorrow than it did in the review, how would you know, and how fast?

‍

CISA gave organizations a solid map of what secure agentic AI is supposed to look like in production. It didn't — and couldn't, in a static guidance document — give you a way to verify any of it before you ship. That's the design review's job now. Not checking whether the right words appear in an architecture doc, but checking whether the architecture makes its own runtime behavior verifiable at all.

‍

If it can't answer that, it's not ready for a production trust boundary. It doesn't matter how good the diagram looks.

‍