The security risks of autonomous AI agents have a map now.
The CISA Agentic AI Five-Risk Framework sorts them into five categories: privilege, design and configuration, behavioral, structural, and accountability.
It's a good map, but the market's answer is turning into a second problem, a fast-growing collection of agent-specific security tools, one silo per risk category, each managed on its own, and nobody connecting them.
The five categories are the challenge to tackle, and the five silos are what IT and security teams will have to live with.
Our feeling, from talking to the teams who run these stacks, is that operating one can be overwhelming, and just adding more tools isn't helping.
What IT and security teams manage today, and what vendors propose to secure agents
None of this starts from a blank page.
Ask an IT and security team at a mid-sized company what they operate today and the list runs long: an identity provider for authentication, privileged access management for credentials, a ticketing system for access requests, a secrets manager, cloud entitlement tooling, maybe identity threat detection as well.
Each tool solves a real problem, but each is managed individually, with its own console, its own policy model, and its own idea of who the organization is.
The integration between them is mostly a few runbooks and an informal split of who owns what across IT and security.
What agents pile on
Agentic AI increases the pain from the existing problems because it clashes with any manual process and then it adds some more.
Agents join pipelines and service accounts as non-human identities, each holding credentials in several target systems.
But unlike traditional non-human identities, the access an agent needs is not static, it shifts with the task it's on.
Where a script performs one narrow function, an agent executes a whole workflow, reading from one system, deciding, calling the next, and writing state back.
A hallucination or an injected instruction can cause more severe damage than a bug in a cron job ever did.
This is where the CISA framework provides a useful way to group and map risks:
- Privilege risk: agents may run on shared service accounts, with long-lived keys that grant more access than the task at hand requires.
- Design and configuration risk: they may consume tools and instructions from third parties, and unvetted plugins and poisoned tool metadata can open the door.
- Behavioral risk: their behavior is non-deterministic, so goal drift and tool chains nobody planned for can show up.
- Structural risk: multi-agent setups can propagate a poisoned response or a hallucinated step across boundaries nobody drew on a diagram.
- Accountability risk: the reasoning may never be recorded and the tool calls may go unlogged, so nobody can reconstruct what the agent did or why.
Vendors respond with more tools
We build for these teams ourselves, so we see the pattern up close, and it holds across all five silos.
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, and behavioral risk gets guardrails that evaluate policy over tool arguments and results.
Structural risk gets sandboxes, from Firecracker microVMs to eBPF probes, and accountability risk gets signed action receipts, hash-chained audit logs, and kill switches.
Individually, much of this is good work, some of it excellent.
But put yourself in the seat of the team that has to operate all of it.
From that seat, 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 top of tools that were already held together by runbooks and quiet heroics.
Every one of those tools needs configuration, and the configuration is where the truth about the organization lives: who owns which agent, which data is sensitive, which system is critical, who approves what.
Each tool answers that question its own way, by hand, in its own console.
The CISA framework divides the risks into five categories, but the operations are left for teams to figure out.
This is not hypothetical
This challenge used to be one for bigger companies, but with agents, much smaller ones face it too now.
An agent doesn't reason more carefully just because it runs in a startup, as the postmortem that went viral in April 2026 shows, when it even made the mainstream news.
A coding agent at PocketOS hit a credential error in staging, found an over-privileged Railway token in the workspace, and wiped the production database and its backups.
Afterwards, it admitted it had ignored its safety rules to finish the task.
People commonly hold far more privileges than they need, because the existing stack is already too complex to manage, and reviewing standing access by hand across that many consoles doesn't happen.
Unlike humans, agents don't ignore the over-privileged permissions they don't need, because an agent works by trial and error.
Sooner or later, one of those errors turns catastrophic.
Slow and secure, or fast and insecure
Securing agents doesn't shrink the stack, it grows it, and the harder the system is to manage, the slower the ticket queue gets.
A team that needs access to do its job files a ticket, waits, waits longer, and eventually finds a way around the process.
That's shadow IT, and it isn't born of malice, it's born of urgency and a desire to get things done.
The teams we talk to want to be enablers, but their complex stack gives them two options: a slow yes through the ticket queue to keep things secure, or a fast yes by turning all controls off.
Agents shrink the tolerance for both to zero.
An agent that finishes its reasoning in seconds and then waits three days for the access it needs isn't an efficiency gain, it's a broken feature, and the team behind it won't tolerate the wait.
So someone hands the agent a copy of their own credentials, over-scoped and unattributed.
The agent then runs wild with all the permissions that person most likely didn't even know they had.
The first prompt injection that finds them writes to production under a person's entitlements, at machine speed and the audit lags a month behind.
The question we're working on
Our sense is that the operations burden, more than any single missing control, decides how this goes.
The five risk categories look to us like five views of one question: what should this identity, human or non-human, be able to do right now, and how do all these systems stay true to that answer as it changes?
The pattern we keep reaching for is the one Kubernetes taught the industry: describe the state you want, and controllers reconcile reality to it, continuously, correcting drift instead of discovering it in an outage.
It's the pattern that turned bespoke DevOps into platform engineering, and it's what the five silos are missing, because every one of them is configured by hand.
Whether it extends to configuration and access management is the open question we're exploring at Accession1: one system that holds the organization's context and derives every configuration and grant from one declared state, so the gateway, the guardrail, the sandbox, and the audit trail read from one picture of the organization rather than five hand-maintained ones.
Access that follows live identity and resource state, rather than standing grants, is what we call dynamic access management.
Just-in-time elevation for bounded tasks is part of the same idea: credentials that exist only when needed.
Reconciliation covers the tool side, but the ticket queue is the other half of the problem.
Self-service provisioning within administrator-set boundaries is what we're exploring for that half.
The outcome we care about is an IT and security team that can enable and secure the business at the pace the business actually runs, including the part that now runs through agents.
What we'd take from this
If you run IT or security, our recommendation is to not fall for the trap of just adding more tools.
The controls in the five categories all matter, and you'll probably end up running several of them, so ask how to make what you have, and what you have to add, more maintainable.
The place to start is what holds them together: where does the answer to who or what may do what live, who maintains it, and how fast does it stay true as agents and systems change.
If the answer is five consoles and a runbook, the agentic transformation of your business will cause more pain than gain.
Top comments (0)