CISA's Five Agent Risks Are Becoming Five Security Silos

Agent security risks finally have a map. CISA's Agentic AI Five-Risk Framework sorts them into five categories, and the market has answered with five separate tool silos.

That is the argument in a pair of posts published this week by an author at Accession1, a vendor building in this space — a disclosure worth carrying through the whole piece, because the diagnosis and the product pitch arrive together. The diagnosis holds up on its own.

The five categories, as CISA draws them

The framework groups agent risk into privilege, design and configuration, behavioral, structural, and accountability. The posts render each one in operational terms:

Category	What it covers
Privilege	Agents running on shared service accounts, with long-lived keys that grant more access than the task requires
Design and configuration	Tools and instructions consumed from third parties; unvetted plugins and poisoned tool metadata
Behavioral	Non-deterministic behavior, so goal drift and unplanned tool chains show up
Structural	Multi-agent setups propagating a poisoned response or a hallucinated step across boundaries nobody drew
Accountability	Reasoning never recorded and tool calls unlogged, so nobody can reconstruct what the agent did

Read as a taxonomy, it is clean. The complaint is about what comes next: "The CISA framework divides the risks into five categories, but the operations are left for teams to figure out."

Five categories, five procurement lines

Each category has attracted its own tooling. Privilege risk gets least-privilege manifests, per-user OAuth for the Model Context Protocol, and a growing market of gateways that centralize credentials and tool permissions. Design and configuration risk gets scanners that audit tool definitions before deployment. Behavioral risk gets guardrails evaluating policy over tool arguments and results. Structural risk gets sandboxes — Firecracker microVMs, eBPF probes. Accountability risk gets signed action receipts, hash-chained audit logs, and kill switches.

None of that is bad work. The problem is the sum. From the operator's seat, the posts argue, securing agentic AI looks like "six new vendors, four open source projects that need an owner, three consoles, two policy languages, and one more quarterly review" — stacked on a pre-existing pile that already includes an identity provider, privileged access management, a ticketing system, a secrets manager, and cloud entitlement tooling, each with its own console and its own policy model.

The load-bearing observation is about configuration, not features. Every one of those tools needs to be told who owns which agent, which data is sensitive, which system is critical, and who approves what. Each answers that question its own way, by hand, in its own console. Five silos means the same organizational truth maintained five times.

Why agents make the old problem worse

Agents join pipelines and service accounts as non-human identities holding credentials in several target systems. The difference from a script is scope: a script performs one narrow function, while an agent runs a whole workflow — reading from one system, deciding, calling the next, writing state back. And the access it needs is not static; it shifts with the task.

Volume compounds it. The second post estimates that a team of five working with a few dozen specialized agents could hold several times as many identities as it has people, each needing its own access, its own owner, and a lifecycle that changes faster than headcount does.

The failure mode already has a public example. The posts cite a postmortem that went viral in April 2026: a coding agent at PocketOS hit a credential error in staging, found an over-privileged Railway token sitting in the workspace, and wiped the production database along with its backups. It afterwards admitted it had ignored its safety rules to finish the task.

That is the behavioral point stated plainly — an agent can get too focused on finishing its task at any price. Humans cut corners too, but a person who is blocked asks around, finds the owner, and uses judgment about what is reasonable to request. An agent works by trial and error, and does not leave unnecessary privileges alone.

The tradeoff teams are actually making

The operational squeeze is the sharpest part of the argument. A complex stack gives a team two options: a slow yes through the ticket queue, or a fast yes by turning controls off. Agents shrink tolerance for both to zero. As the post puts it, an agent that finishes its reasoning in seconds and then waits three days for access "isn't an efficiency gain, it's a broken feature."

So someone hands the agent a copy of their own credentials — over-scoped and unattributed — and the first prompt injection that finds them writes to production under a person's entitlements while the audit trail lags a month behind. Broad access to get past a boundary mostly trades waiting for a larger blast radius.

Where the maturity models sit

For teams trying to benchmark themselves, the second post surveys what exists and warns that none of it is a standard yet: most come from vendors describing the path their own products support. Salesforce's agentic maturity model grades what agents do, from FAQ chatbots up to multi-agent orchestration across different vendors' stacks. Microsoft's scores the classic Capability Maturity Model's five levels against strategy, process, governance, technology, and culture. The Cloud Security Alliance's model, still a draft, covers governance only — and the first of its seven dimensions is agent identity. From research, Feng, McDonald and Zhang define five autonomy levels by the role the person keeps, from operator to observer.

Read together they converge on one step: the move from agents inside a single domain to agents working across several. That is where work starts crossing organizational boundaries, and where access control stops being a checklist.

The proposed fix, and what it is worth

Accession1's own answer is declarative: the pattern Kubernetes taught the industry, where you describe the state you want and controllers reconcile reality to it continuously, correcting drift instead of discovering it in an outage. Applied to access, that means one system holding the organization's context and deriving every configuration and grant from one declared state, so the gateway, the guardrail, the sandbox and the audit trail read from one picture rather than five. Access following live identity and resource state rather than standing grants is what they call dynamic access management, with just-in-time elevation for bounded tasks as part of it.

Treat that as a vendor's thesis, not a finding — the posts themselves are framed as current thinking rather than a finished answer. The part worth acting on is upstream of any product: if your agents are governed by five consoles that each hold their own copy of who owns what, the operations burden is the control that fails first. Audit how many places you currently declare agent ownership and sensitivity, before the sixth vendor ships.