Notifications
Clear all
Topic starter
14/08/2026 6:37 pm
TL;DR: Most organisations have more than 800 risky AI agents operating without security oversight, and agents can inherit user permissions, be shared across lower-privilege teams, or keep running after owners leave, according to Obsidian Security. Existing governance built for deterministic systems no longer matches how agents behave after deployment, making continuous discovery and runtime enforcement necessary.
NHIMG editorial — based on content published by Obsidian Security: 800+ risky agents per organization. Here are three steps to secure them
By the numbers:
- Most organizations have 800+ risky agents operating without security oversight.
- agents granted an average of 43 permissions but actively using 4.
Questions worth separating out
Q: How should security teams govern AI tools that inherit user permissions on endpoints?
A: Treat each OAuth-connected assistant, plug-in, or local model as a non-human identity with delegated authority.
Q: Why do AI agents create a larger security risk than ordinary web applications?
A: AI agents can act with delegated authority, chain tool calls, and reach internal APIs without human pacing.
Q: What breaks when AI risk reviews are done only at deployment time?
A: You miss the behaviour that appears after launch.
Practitioner guidance
- Implement live agent inventory controls Track every agent at the moment it appears, with owner, access scope, connected tools, and publishing state.
- Reconcile effective access against intended access Compare each agent's granted permissions with what it actually uses, especially where the article's pattern shows 43 permissions but only 4 are actively used.
- Tie agent ownership to lifecycle events Remove or revalidate agent access when the human owner changes role, leaves the organisation, or loses the account used to create the agent.
What's in the full article
Obsidian Security's full blog covers the operational detail this post intentionally leaves for the source:
- The full agent inventory and risk scoring approach behind the 800+ risky agents finding.
- Operational examples of continuous discovery fields such as ownership, scope, and integration context.
- Runtime enforcement guidance for moving from observation mode to targeted blocking.
- The article's breach context and the Salesforce exposure discussion referenced in the post.
👉 Read Obsidian Security's analysis of risky AI agents and governance gaps →
800+ risky agents per organization: are your controls keeping up?
Explore further
14/08/2026 6:43 pm
Agent access becomes an NHI governance problem the moment it outlives the creator. The article shows that AI agents inherit a human's permissions, then continue operating after those permissions should have been reconsidered. That places them inside the NHI governance model, not outside it, because the control question becomes who owns the access state once the human actor is no longer in the loop. Practitioners should treat the agent as a governed identity with a lifecycle, not as a feature attached to an application.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable when an AI agent retains access after a project ends?
A: The accountable party should be the current human sponsor who can explain why the agent still exists and approve its continued access. Creator history is useful, but it is not sufficient once teams change, projects end, or identities are reused. Accountability has to follow operational ownership, not historical creation metadata.
👉 Read our full editorial: AI agent sprawl exposes governance gaps in enterprise access
