Notifications
Clear all
Topic starter
02/08/2026 11:38 am
TL;DR: AI agents in IDEs, endpoints, SaaS, and MCP-connected systems inherit user permissions and can read files, query databases, call APIs, and chain actions without continuous human oversight, according to Cyberhaven. The governance problem is no longer prompt safety alone: security teams need inventory, observability, and runtime controls that can track agent behaviour across the full execution lifecycle.
NHIMG editorial — based on content published by Cyberhaven: Agentic AI Security: Visibility and Control for AI Agents at Work
By the numbers:
- 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%).
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents increase risk in SaaS environments?
A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change.
Q: What breaks when existing DLP and EDR tools are used to monitor AI agents?
A: Those tools break at the point where agent behaviour becomes sequential and contextual rather than single-event based.
Practitioner guidance
- Inventory every agent as a delegated identity Maintain a continuous inventory of local agents, IDE assistants, SaaS-linked agents, and MCP-connected workflows.
- Instrument agent execution with lineage and sequence context Capture the full tool-call chain, source data, and destination systems for each agent session.
- Apply runtime guardrails to high-risk actions Block, warn, or redact when agents attempt to move sensitive data across unapproved endpoints or access data outside the expected workflow.
What's in the full article
Cyberhaven's full blog post covers the operational detail this post intentionally leaves for the source:
- How the visibility layer classifies sanctioned and unsanctioned agents across endpoints, SaaS, and MCP-connected systems
- How observability reconstructs multi-turn agent sessions into a complete execution lifecycle for investigation
- How runtime controls can block, warn, or redact sensitive actions without relying on generic alerting
- How the data lineage foundation links source data, classification, and destination systems across the workflow
👉 Read Cyberhaven's analysis of agentic AI security visibility and controls →
AI agents at work: what visibility and control gaps teams miss?
Explore further
02/08/2026 12:51 pm
Delegated agent identity is now a first-class governance object. The article makes clear that AI agents inherit permissions from the user who deploys them, but they exercise those permissions in a different behavioural pattern from either humans or conventional service accounts. That means the control question is no longer just who authenticated, but what delegated actor executed which tool calls against which data sources. IAM and IGA programmes that do not model agents as a distinct governed identity type will miss the actual access path.
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.
- Only 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, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who should be accountable for AI agent security incidents?
A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.
👉 Read our full editorial: Agentic AI security exposes the visibility gap in enterprise IAM
