Notifications
Clear all
Topic starter
24/07/2026 4:09 pm
TL;DR: Many teams can now list the AI agents in their environment, but that inventory does not show reachable identities, action scope, or accountable owners, according to Clutch Security. The real control problem is governing the identities agents can use and the approvals they can bypass, especially when auto-accept turns a helper into an unsupervised actor.
NHIMG editorial — based on content published by Clutch Security: Your AI Agent Inventory Is Not a Security Program
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams implement AI agent credential management?
A: Security teams should issue short-lived, task-scoped credentials tied to the specific agent, tool, and resource involved, rather than sharing human sessions or static API keys.
Q: Why do flat AI asset inventories miss the real security risk?
A: Because the risk usually sits in the connection between components, not in the component name itself.
Q: What breaks when auto-accept is enabled for coding agents?
A: The human approval boundary disappears, so the agent can move from suggestion to execution in the same session.
Practitioner guidance
- Map every agent to its borrowed identities Record which API keys, service accounts, OAuth grants, SSH keys, and human sessions each agent can use.
- Separate read access from execution rights Classify whether an agent only observes data or can also modify systems, run code, or trigger workflows.
- Remove auto-accept from high-risk workflows Disable approval bypass where agents can reach production secrets, cloud consoles, databases, or pipelines.
What's in the full article
Clutch Security's full blog post covers the operational detail this post intentionally leaves for the source:
- A practical framework for sorting AI agents by deployment model, execution capability, and identity exposure.
- The four-question review model for mapping what each agent can reach, what it can do, who owns it, and whether actions are logged.
- Examples of coding-agent risk on developer endpoints, including inherited cloud sessions and local secrets.
- Guidance on separating inventory from governance so teams can turn a list into an execution plan.
👉 Read Clutch Security's analysis of why AI agent inventory is not enough →
AI agent inventory: what it means for IAM and NHI teams?
Explore further
24/07/2026 4:12 pm
Inventory without entitlement mapping is a visibility exercise, not a security programme. A list of agents only becomes useful when it is tied to the identities those agents can assume and the systems those identities can reach. That is the same discipline IAM teams already apply to NHIs, but agentic environments make the gap more obvious because the actor and the identity are separate. The practitioner conclusion is straightforward: inventory is the first mile, not the last mile, of control.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when an AI agent uses delegated access incorrectly?
A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.
👉 Read our full editorial: AI agent inventory is not a security program
