Your security team reviewed an AI assistant, approved its use, and established policies for employees. Then the provider updated the product. The familiar chat window now launches agentic tasks, executes code, or reaches into connected systems. How much of that original approval still applies?

Claude’s latest update brings this problem into focus. As providers combine chat, tools, browsers, and autonomous workflows, enterprises can inherit risks their original review never considered. Yesterday’s security review can become today’s blind spot, even when employees use an approved service.

When chat becomes execution

Anthropic’s unified Claude experience combines Chat and Cowork. Conversations can move into an Anthropic-managed cloud sandbox when tasks require code execution or file work, without users switching modes. Eligible Enterprise organizations that have not made an explicit choice face automatic enablement. Existing admin choices remain effective, and prerequisites and configuration exclusions apply.

The security implications extend beyond the interface. Anthropic documents that endpoint EDR does not cover its cloud sandbox. Scheduled tasks can also continue after the originating conversation is deleted. Security teams must reassess where work runs, what remains active, and which evidence they can collect.

A trust boundary defines where access, authority, or security assumptions change. Moving work from an employee’s laptop to a provider’s cloud changes that boundary. Giving an assistant permission to modify records changes it again. Each transition deserves an explicit decision by the enterprise.

The pattern extends beyond Claude

OpenAI’s ChatGPT agent system card describes the combination of research, a remote browser, terminal execution, and connectors to external applications. That evolution expands the questions security teams must ask about an assistant’s authority and exposure to untrusted content.

Microsoft’s documentation on Anthropic models illustrates another boundary: who processes enterprise data. Claude models are enabled by default for most commercial-cloud customers outside EU/EFTA and the UK. Microsoft documents regional exclusions and processing commitments that administrators need to understand. The application name alone no longer tells the whole story about the underlying service.

Providers have reasons to add these capabilities. Customers want useful automation, broader model choice, and fewer interruptions. Enterprises, however, cannot assume that provider defaults will preserve the boundaries they previously accepted. Product convenience and an organization’s risk tolerance are different considerations.

Approval must account for change

A vendor assessment captures a product at a point in time. Its value diminishes when execution environments, permissions, integrations, or defaults change without a corresponding review. Security teams need to identify material changes and respond before those changes become routine business practice.

Start with four questions for every AI capability:

• What can it read, including files, messages, credentials, and connected data?
• What can it do, including running code, changing records, or sending information?
• Where does it run, and which controls and logs cover that environment?
• What persists, including permissions, memory, scheduled tasks, and linked devices?

Assign an owner to the answers. Revisit them when providers add capabilities or alter relevant settings. A new write permission or unattended execution path should trigger a review, even if procurement sees no new purchase.

Build controls that survive the next update

Enterprises must own and set the boundaries of AI adoption. Provider controls are a necessary starting point, but security teams also need consistent policies and reliable backstops across services, applications, and agents.

Prioritize a few practical steps:

• Maintain an inventory of AI services, agents, connectors, and owners, including personal accounts used for work.
• Limit permissions to each task. Separate read access from consequential actions such as sending, deleting, or publishing.
• Monitor runtime activity against approved intent. Look for unexpected destinations, privilege changes, repeated failures, and expanding scope.
• Require human approval for high-impact actions, with enough context for reviewers to make a useful decision.
• Test intervention procedures. Confirm that teams can stop tasks, revoke access, and preserve evidence when something goes wrong.

A kill switch needs a defined scope and an accountable operator. Stopping one agent may leave scheduled tasks or delegated access active elsewhere. Exercise those scenarios before an incident, and document which controls cover each execution environment.

How PointGuard AI can help

PointGuard AI helps enterprises establish visibility, policy, and runtime protection across employee AI usage, applications, and agents. Discovery and endpoint controls help identify AI tools and agent activity. Agent Mission Control brings together agent inventory, identity, observability, guardrails, and behavioral intervention, while MCP Security Gateway governs access to tools and resources.

Together, these capabilities help organizations define and enforce their own boundaries. For instrumented agents, runtime controls can detect goal drift and out-of-scope activity, apply human approvals, and intervene through circuit breakers or kill switches. Coverage must match how and where each agent operates.

Join our upcoming webinar to lear more: Claude Cowork Is Now on by Default. Is Your Security Ready? on November 19 @ 8:00 AM PDT