SentinelOne Launches Enterprise AI Agent Security and Protection Layer

When an AI agent is granted access to read emails, call APIs, access CRMs, or execute multi-step workflows, it is no longer just an experimental tool. It functions like a digital employee with an identity, permissions, and the ability to act on behalf of the enterprise. And like any employee, it can make mistakes.

That is why the news that SentinelOne has launched Singularity Agentic Detection and Response (ADR) is worth pausing on for a few minutes by security teams and technology leaders. Announced at OneCon 2026 in early access, the product targets an increasingly clear gap: controlling the behavior of AI agents while they run in enterprise environments.

What is noteworthy about SentinelOne's ADR launch?

The key point to grasp is that ADR is not positioned merely as a vulnerability scanner or a basic access blocking layer. Built on the Singularity Platform, it extends endpoint, cloud workload, and identity security capabilities to AI agents. In other words, SentinelOne wants to place agents on the same map that security teams use to monitor, investigate, and respond.

The product combines three functions: agent discovery, policy enforcement, and behavioral detection and response. This approach reflects an uncomfortable reality: agents can be attacked, but they can also make mistakes on their own. An agent tasked with summarizing documents could accidentally leak sensitive data if its access permissions are too broad. Another agent might call the wrong tool due to a misunderstanding of context. These errors do not require malicious actors to happen.

• Creates a catalog of AI agents, tools, connectors, and MCP servers along with associated permissions and users.
• Supports agents built on Salesforce Agentforce, Microsoft Copilot Studio, OpenAI ChatGPT workspace agents, and Anthropic Claude managed agents.
• Monitors activity via event traces, linking AI actions to underlying system processes.
• Detects discrepancies between assigned tasks and actual behavior.
• Blocks prompt injection and credential exfiltration before actions occur; isolates an individual agent without halting the entire workflow.

It is worth noting that ADR follows up on the Prompt AI Agent Security capabilities introduced by SentinelOne in March, bringing agent operations into Singularity's existing investigation and response workflows. For security teams, this is a much more practical approach than having to build a separate monitoring system for every type of agent.

The biggest risk may come from authorized agents

Speaking about the product, Chris Corde, Chief Product Officer at SentinelOne, framed the issue much more directly than typical discussions on safe AI:

Protecting AI agents does not stop at blocking intentional attackers. An equally significant, and perhaps more prominent, risk comes from the unintended behavior of authorized agents that have already been granted permissions.

This statement hits close to home on an unspoken concern. Enterprises typically focus on scenarios involving external attacks. However, once an agent is inside the system, holds valid permissions, and is trusted by users, aberrant behavior can be much harder to detect. It does not break down the door. It walks right through the front entrance.

Imagine a customer service agent authorized to look up orders and draft responses. If someone alters the objective in the prompt, or if the agent misunderstands the request, it could send incorrect information to a customer. If the agent also has permission to invoke payment tools, the consequences could be far more severe. The issue is not whether the agent is good or bad. The issue is that the agent possesses too many privileges relative to its assigned task.

Therefore, the value of AI agent security does not lie in slapping a label on a new product. It lies in the ability to answer three operational questions: Who is this agent? What is it permitted to do? And if it makes a mistake, who detects it first?

What problem does ADR solve for security teams?

ADR can be visualized across four layers, moving from visibility to control. First is visibility: cataloging agents, tools, connectors, MCP servers, permissions, and associated users. Second is monitoring: recording agent activity and linking AI actions to underlying system processes. Third is limitation: deciding which agents can run and what resources they can access. Fourth is remediation: blocking hazards before actions execute, or isolating the affected agent independently.

1. Know what you have: prevent agents from existing as unmanaged black boxes.
2. Know what agents are doing: monitor event traces instead of relying solely on initial descriptions.
3. Set boundaries: compel agents to use only the necessary tools and resources.
4. Localize handling: halt a faulty agent without crashing the entire active workflow.

The fourth point is highly relevant for enterprises. Many security systems tend to block entire pipelines when anomalies are detected. While safe, this approach can paralyze critical processes. If the specific malfunctioning agent can be isolated, operations teams gain time to investigate without having to apologize to customers for hours of downtime.

AI agents are becoming a new identity in the enterprise

One of the biggest shifts brought about by AI agents is not the conversational interface, but access permissions. Agents can use credentials, call connected tools, and execute multi-step task sequences with minimal human oversight. This makes agents closer to a non-human identity than a standard software feature.

Once classified as an identity, an agent requires identity management: an owner, least privilege access, an expiration timeframe, logs, and a revocation process. Many enterprises manage user accounts effectively while remaining lax with agents due to pressures for rapid experimentation. An agent created for a pilot project may persist long after the project ends, with its access permissions unrevoked.

• Who is accountable when an agent acts incorrectly?
• What privileges does the agent hold, and are those privileges actually necessary for its current task?
• When are privileges revoked—upon changing objectives or when the agent is retired?

Answering these questions before scaling will save considerable time later. Tools can assist in detection and blocking, but they cannot establish principles on behalf of the enterprise.

Points to verify before placing trust

Because ADR is in early access, launch information should be approached with appropriate caution. This signals that the product is still being refined, not that all AI agent risks have been resolved. SentinelOne has announced capabilities, support scopes, and integration methods, but independent evaluation results were not included in the source material.

Enterprises should ask specific questions before testing on live systems:

• What is the actual coverage for internal agents versus third-party agents?
• How large is the volume of data generated by event tracing, and who will review it daily?
• Can the prompt injection blocking mechanism generate false positives, and how do operations teams handle them?
• Do the costs, latency, and integration requirements align with current scale?

A good security product should not be viewed as a standalone shield. It delivers value only when embedded in a process with accountable owners, risk classifications, and clear incident response scenarios.

If deploying AI agents, where should you start?

There is no need to wait for a complete platform to start implementing security. Enterprises can begin with small actions that yield real impact. Choose a specific workflow, inventory participating agents, log granted permissions, and assign an owner. Expansion can follow gradually.

1. Agent inventory: list agents, tools, connectors, permissions, and associated users.
2. Assign ownership: every agent must have an individual or group responsible for it.
3. Apply least privilege: grant only the permissions necessary for the current task; avoid permanent access.
4. Enable logging: record sufficient action traces to investigate incidents.
5. Controlled trial runs: begin with low-risk workflows that feature monitoring and individual agent kill switches.

A modest yet effective approach is to select an internal agent, grant it narrow permissions, monitor it for a few weeks, and only then decide to expand. Experience from technology projects shows that errors typically surface during operations when agents encounter situations outside test scenarios. Preparing for those situations beforehand is far better than fixing issues post-incident.

SentinelOne ADR is a notable signal: the security market is beginning to treat AI agents as real operational entities rather than theoretical concerns. However, tools are only part of the equation. The larger question still rests with the enterprise: What permissions are you granting your AI agents, and do you know what they are doing with those permissions?

If you have ever witnessed an agent fail without triggering system alarms, share your experience. Alternatively, if you believe overly strict permission controls strip AI agents of their flexibility, that is also a debatable perspective. Which side do you lean toward? Leave a comment to discuss further, and if this article is helpful, feel free to share it with colleagues preparing to grant permissions to AI agents.