Notifications
Clear all
Topic starter
11/08/2026 3:14 pm
TL;DR: AI agents now operate across apps, endpoints, identities, and cloud workloads, creating a single attack chain that starts with manipulated prompts and ends with executed actions, according to SentinelOne. The governance problem is that traditional controls still treat those surfaces separately, while agent behaviour, privilege, and runtime execution need to be managed as one security model.
NHIMG editorial — based on content published by SentinelOne: AI agents have made their way into virtually every layer of your environment
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
Questions worth separating out
Q: How should security teams govern AI agent tool calls without exposing credentials?
A: Security teams should place credentials in a separate execution layer, not in the model context, and bind every tool call to a distinct agent identity.
Q: Why do AI agents complicate existing IAM and PAM controls?
A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed.
Q: What breaks when AI prompts are changed without evaluation?
A: The system may appear to work in a demo while silently degrading in production.
Practitioner guidance
- Inventory every AI agent and MCP connection Build a live register of all agents, copilots, browser assistants, IDE extensions, and MCP servers that can reach enterprise systems.
- Replace standing access with task-scoped controls Limit each agent to the minimum permissions required for a specific workflow and prefer short-lived credentials over reusable secrets.
- Correlate tool calls with identity and host activity Make tool invocation logs, endpoint telemetry, and identity events searchable in the same investigation path so a suspicious prompt can be traced to execution, credential use, and downstream impact without manual stitching.
What's in the full article
SentinelOne's full article covers the operational detail this post intentionally leaves for the source:
- How its platform maps agent activity across apps, endpoints, identities, and cloud workloads in a single telemetry flow.
- The specific runtime enforcement and kill-switch behaviours it describes for blocking unsafe tool calls and revoking access.
- Examples of endpoint detections it cites, including AI-linked malware and supply chain abuse scenarios.
- The vendor's explanation of how its AI telemetry is correlated with existing endpoint data for investigation and response.
👉 Read SentinelOne's analysis of AI agent security across endpoints, identities, and cloud →
AI agent security across endpoints and identities: what changes now?
Explore further
11/08/2026 3:27 pm
AI agent security is now an identity governance problem, not just an application security problem. Once an agent can hold credentials, call tools, and act without a human approving every step, it behaves like a non-human identity with runtime privilege. That means IAM and PAM teams need to think in terms of scope, revocation, and task-bound access rather than just login and session control. The governance question is no longer whether the model is safe to query. It is whether the agent can be trusted as a principal in the environment.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
- Also from our research: 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?
A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.
👉 Read our full editorial: AI agent security spans apps, endpoints, identities, and cloud
