Your Agent Has Credentials. Now What?

There is a particular kind of security conversation happening right now that I want to push back on. It goes: AI agents are a new threat, we need new tools. The first half is half-true. The second half is mostly wrong, and it is expensive.

An agent with tool access is not a new category of adversary. It is a confused deputy with a shell — a component that holds real authority and takes instructions from data it reads. We have had confused deputies since the 1980s. What is new is not the vulnerability class. What is new is the blast radius: for the first time, the confused deputy can plan, retry, chain a dozen operations together, and do all of it at three in the morning without getting bored.

So the work is not novel. It is the work you already deferred, now with a deadline.

OWASP's own revision makes the point better than I can. The 2026 Top 10 for Agentic Applications (ASI01–ASI10, published December 2025) did not invent ten new vulnerability classes — its top entry, ASI01 Agent Goal Hijack, is a merge of what used to be two separate LLM risks: LLM01 Prompt Injection and LLM06 Excessive Agency. The taxonomy consolidated because in an agentic system those two stopped being distinct problems. Injection without agency is a curiosity; agency without injection is a footgun. Together they are the whole threat, and the multi-step autonomous execution is what turns a single bad response into a chain of real actions.

Here is what I would actually do, in the order I would do it.

1. Write down what your agents can reach. Then be shocked by the list.

Frameworks: CIS Controls v8.1 — Control 1/2 (Inventory of Enterprise & Software Assets) · NIST CSF 2.0 — ID.AM · NIST AI RMF — MAP

Nobody has this list. Start it anyway.

For each agent or assistant with tool access, write down: which credentials it holds, which hosts it can reach on which ports, which APIs it can call, and what it can do that cannot be undone. Not what it is supposed to do — what it can do.

The gap between those two is your actual exposure. In my own homelab I found that the agentic VLAN could SSH to seven hosts when it needed three, and that the "read-only" integration had write scope on a vault it never touched. Neither of those was a mistake anybody made. They were both defaults that nobody had revisited.

Do this before buying anything. It is free, it takes an afternoon, and it will reorder the rest of your list.

2. Give every agent its own identity.

Frameworks: OWASP ASI03 (Identity & Privilege Abuse) · CIS v8.1 Control 5/6 · NIST CSF 2.0 — PR.AA

One shared service account across four automations is one blast radius across four automations, and it makes your logs useless — you cannot answer "which thing did that?" because every request looks identical.

Per-agent identity is the cheapest security control that exists. It costs you a few minutes per agent and it buys you attribution, independent revocation, and per-identity scoping. When something goes wrong you kill one credential instead of taking down every automation you run.

I do this per host, not just per agent, for the same reason: a compromised key should describe a small, specific hole, not a general one.

3. Scope credentials down until something breaks, then back off one notch.

Frameworks: OWASP **LLM06 — excessive permissions · OWASP ASI03 · CIS v8.1 Control 6 (least privilege; IG1 is enough here) · NIST CSF 2.0 — PR.AA**

Least privilege is a tired phrase because it is usually said and rarely done. Concretely:

• Read-only unless writing is the entire point of the job.
• One vault, one namespace, one bucket — not "all".
• Prefer a credential that expires to one that does not.

The test is not "does this feel restrictive." The test is: cut the scope, run the workload, see what fails. Anything that did not fail was scope you were not using. That is the whole method, and it works because the failures are loud and immediate.

4. Put the irreversible things behind a human.

Frameworks: OWASP **LLM06 — excessive autonomy, whose stated mitigation is literally human-in-the-loop · NIST AI RMF — MANAGE**

This is the one that matters most and gets skipped most.

Sort your agent's capabilities into reversible and irreversible. Deleting data, rotating or revoking credentials, changing access control, sending external email, moving money, publishing anything public — these do not get to be autonomous, no matter how good the model is. Not because the model is dumb, but because the cost asymmetry is absurd: the upside of automating an irreversible action is that it happens forty seconds sooner, and the downside is unbounded.

Reversible things can run unattended. That is where the actual leverage is, and there is plenty of it.

5. Treat every input the agent reads as attacker-controlled.

Frameworks: OWASP ASI01 (Agent Goal Hijack) · OWASP ASI06 (Memory & Context Poisoning)

Prompt injection is not solved. I want to be blunt about this, because a lot of vendor material implies otherwise: there is no filter, no classifier, and no system prompt that reliably prevents a sufficiently motivated instruction hidden in content your agent reads.

So stop trying to win at the parsing layer and win at the authority layer instead. If an agent reads a web page, a PDF, a ticket, a code comment, or an email, assume that content is trying to give it instructions. Then make sure that even if it succeeds, the agent cannot do anything that matters — because of items 3 and 4, not because the injection was caught.

Defence that depends on detecting the attack fails when the attack is novel. Defence that depends on the attacker having no useful privileges does not.

6. Log the tool calls, not just the conversation.

Frameworks: OWASP ASI02 (Tool Misuse & Exploitation) · CIS v8.1 Control 8 (Audit Log Management) · NIST CSF 2.0 — DE.CM

Most teams logging "AI usage" are logging prompts and completions. That is the least useful artifact in an incident.

What you need is the action log: which tool, which arguments, which identity, against which target, with what result. That is the thing that answers "what happened" at 2am. Prompts tell you what someone asked for. Tool calls tell you what actually occurred, which is frequently different.

Ship those to wherever your other logs go. They are the same shape as any other audit trail and they should live in the same place.

7. Alert on the agent behaving unlike itself.

Frameworks: OWASP ASI10 (Rogue Agents) · CIS v8.1 Control 13 · NIST CSF 2.0 — DE.AE

Agents are wonderfully predictable. A given automation touches the same handful of hosts, at the same times, in the same order, most days. That makes anomaly detection unusually tractable compared to human behaviour, which is noisy by nature.

Useful signals: a source IP that has never appeared before, a tool the agent has never called, a volume spike, activity outside its normal window, a target outside its normal set. None of this is sophisticated. All of it works, precisely because the baseline is so tight.

One caveat from painful experience: a detection you cannot read is not a detection.

I recently audited my own alert channel and found it producing roughly four false positives a minute. A "possible active attack" alert at the highest severity my rules could emit was firing repeatedly because a tablet on a guest network kept retrying media-discovery against a device on another VLAN, and the firewall kept correctly dropping it. That same day, two genuinely interesting alerts — a connection to a block-listed source, and a probe for a recent web-application CVE — were sitting in the same channel, buried under fourteen hundred events nobody was reading.

Two narrowly scoped tuning rules took my high-severity alert count from 104 in thirty minutes to zero, and the two real ones became visible immediately. Nothing was disabled; the noisy events still land in the dashboard at low severity where they belong.

That is the whole lesson: an unread channel is not monitoring, it is a number that goes up. Tune it or turn it off, but do not count it as coverage.

8. Segment the network the agent lives on.

Frameworks: CIS v8.1 Control 12 · NIST CSF 2.0 — PR.IR · CISA Zero Trust Maturity Model

Put agentic workloads on their own segment with explicit egress rules, and route administrative access through a single chokepoint rather than allowing host-to-host connections everywhere.

Two things fall out of this for free. First, the obvious containment. Second — and this is the part people miss — a chokepoint turns "normal" into something you can define. Once all legitimate administrative traffic arrives from one address, anything arriving from somewhere else is, by construction, worth looking at. You have converted a hard detection problem into a trivial one.

You do not need to enforce it on day one. Deploy the routing, watch it in detect-only mode for a week or two, confirm the only things firing are the ones you expect, then enforce. Enforcing before you have the baseline is how you lock yourself out.

9. Practice revocation before you need it.

Frameworks: OWASP ASI03 · CIS v8.1 Control 5 · NIST CSF 2.0 — RS.MI

Can you kill an agent's access right now? Not "is there a documented process" — can you do it, in under a minute, without asking anyone?

Find out on a calm Tuesday. Every rotation I have done has surfaced at least one consumer nobody had written down. That discovery is cheap during a drill and expensive during an incident.

And know where the rotation actually completes. Installing a new credential is not rotation. The step that matters is deleting the old one — until then you have two working credentials and one of them is the one you were worried about.

10. Decide what you will not automate. Write it down.

Frameworks: NIST CSF 2.0 — GOVERN (GV.PO / GV.RM), the function added in 2.0 · NIST AI RMF — GOVERN · NIST AI 600-1 (Generative AI Profile)

Not a technical control. Probably the most durable one on this list.

Every organisation is going to drift toward automating more, because automation feels like progress and each individual expansion is defensible. The only thing that reliably stops the drift is a boundary written down in advance, while nobody is under pressure, by people who will have to live with it.

Mine is short: anything irreversible, anything that touches money, anything public-facing, and anything that changes who can access what. Yours will differ. The specific contents matter less than the fact that the list exists before you need it, rather than being negotiated in the middle of an outage by someone who wants the outage to end.

One more reason to start now

If you want a forcing function beyond good sense: NIST is currently building COSAiS — SP 800-53 Control Overlays for Securing AI Systems, and two of its five planned overlays are deploying single-agent AI systems and deploying multi-agent systems.

Two things about that are worth noticing. First, COSAiS extends the existing SP 800-53 catalog rather than inventing a parallel AI control set — so if you already run an 800-53 program, agent controls land inside the structure you have instead of beside it. Second, these overlays are a plausible basis for future FedRAMP AI requirements, which means the inventory-and-scope work above is not speculative diligence. It is the same work, done before someone asks for evidence of it.

Caveat, because it matters: COSAiS is not finished. As of early 2026 the only released artifact is an annotated outline for the predictive-AI use case. Do not cite it as a standard you comply with. Cite it as the direction of travel — which is exactly what makes item 1 worth doing this month rather than next year.

The short version

Agentic AI has not invented a new vulnerability class. It has industrialised an old one and removed the natural rate limit that human attention used to impose.

The defences are correspondingly old: know your assets, scope your credentials, separate identities, gate the irreversible, log the actions, watch for drift, segment the network, rehearse revocation. None of it is exciting. All of it works.

The one genuinely new discipline is item 5 — assume the input is hostile and make it not matter. Everything else on this list is something you already knew you should have done, and now have a better reason to actually do.

Frameworks referenced

Verified live on 2026-07-31 before publication — re-check before republishing, these move.

• OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) — announced 2025-12-09.

https://genai.owasp.org/initiatives/agentic-security-initiative/ Supersedes the Feb-2025 "Agentic AI — Threats and Mitigations" T1–T15 taxonomy. Do not cite T1–T15.

• OWASP Top 10 for LLM Applications 2025 — LLM06 Excessive Agency and its three root causes

(excessive functionality / permissions / autonomy). https://genai.owasp.org/

• NIST Cybersecurity Framework 2.0 — https://www.nist.gov/cyberframework
• NIST AI Risk Management Framework 1.0 — https://www.nist.gov/itl/ai-risk-management-framework
• NIST AI 600-1, Generative AI Profile (2024-07-26) — twelve GenAI risk categories mapped onto the

RMF functions. https://airc.nist.gov

• NIST COSAiS — SP 800-53 Control Overlays for Securing AI Systems — https://csrc.nist.gov/projects/cosais

In development; not a finalized standard. Verify status before citing.

• CIS Critical Security Controls v8.1 — https://www.cisecurity.org/controls
• CISA Zero Trust Maturity Model — https://www.cisa.gov/zero-trust-maturity-model