Claude approval is only the first security decision

Claude approval creates a second security decision

A developer’s approved use of Claude can give an AI agent permission to read private code, access credentials, change files, and execute commands. Those permissions create a second security decision: how to govern the agent’s delegated authority, including the resources it can access and the actions it can perform. An agent can stay within its permissions while exposing data or damaging systems, so application approval leaves important questions about its behavior unresolved.

Palo Alto Networks ties this security question to its Anthropic partnership, internal Claude use, and proposed security approach in “Securing the AI Systems of Tomorrow.” The company sells the security products it recommends and benefits commercially when enterprises adopt those controls. It says 95% of the Fortune 500 rely on it for business protection, a measure of its corporate reach. Its recommendations address how enterprises control the dependencies, inputs, and actions of agents working inside their systems.

Permissions leave decisions about agent behavior open

The need for those controls grows as AI assistance becomes execution. Palo Alto Networks describes developers using Claude to understand complex codebases, produce software, and solve problems faster, while knowledge workers use it to draw conclusions from information. When agents perform sequences of tasks across applications and systems, their actions affect enterprise resources. Security teams therefore need to examine what happens after the model recommends a step.

Claude Code shows how those actions can use access a developer has already granted. On the developer’s endpoint, or local machine, an agent may inspect private repositories, retrieve secrets and credentials, edit files, and run commands. It can also reach tools through Model Context Protocol, or MCP, which connects agents to tools and data. Because these actions can stay within existing permissions, harmful behavior can occur without bypassing access controls.

The risk then depends partly on what influences the agent’s choices. A developer may authorize repository work, but the agent can encounter malicious instructions in the material it reads and use its legitimate access to carry them out. Prompt injection is this attempt to redirect an agent through malicious input. For an agent able to act on enterprise resources, that redirection can change its tool use, file edits, or command execution.

Reusable agent skills, packages of instructions and resources for particular tasks, introduce a related risk before a task starts. Teams adopt these skills to give agents repeatable ways to work, but a compromised skill could steer permitted actions toward an unsafe result. Palo Alto Networks identifies malicious code and backdoors, hidden ways to gain access or alter behavior, in models or agent skills as reasons to inspect them before deployment. A dependency’s integrity therefore affects how safely an agent uses its authority.

Even trustworthy components need controls over data handling and access. An agent may legitimately read sensitive information while still needing restrictions on which interactions may contain it. Exposed credentials create another route to harm, while excessive permissions increase the resources an unsafe action can reach. Weaknesses in the AI application or its workflow create further opportunities for exploitation, so teams need to examine the application, its inputs, its dependencies, and its authority.

Those checks become harder when each developer uses a different combination of tools and connections. Palo Alto Networks extends its developer scenario across “thousands of developers, endpoints, skills, and integrations,” illustrating how many combinations an enterprise may need to oversee. A central approval record for Claude reveals little about those combinations unless security teams can inspect where the work takes place. Discovery must therefore reach the environments where agents operate.

Those environments extend beyond coding tools. Employees can work through Claude.ai and Claude Desktop, while development teams can build agents and applications through the Claude API, an application programming interface that lets software exchange requests and responses with Claude. Palo Alto Networks also describes growing reliance on reusable skills, open-source models, and third-party integrations. Activity is therefore spread across repositories, endpoints, applications, and connected systems whose dependencies can change independently.

Greater model capability also changes the defensive work performed in those environments. Through Anthropic’s Project Glasswing, Palo Alto Networks reports that its teams used frontier Claude models, models at the leading edge of current capability, to find software vulnerabilities earlier models had missed. The company links that work to earlier discovery and faster defensive response, and says the time between vulnerability disclosure and exploitation is shrinking. That pressure gives defenders a reason to use advanced models proactively.

Yet defensive use and agent governance answer separate questions. Project Glasswing concerns finding software weaknesses; the Claude Code scenario concerns controlling what an agent can do with enterprise access. Palo Alto Networks’ partnership with Anthropic combines that internal defensive use, a commercial purpose, and a shared security responsibility. Its vulnerability-discovery experience helps explain the partnership, while its proposed enterprise controls address the risks introduced by deployed agents.

Find agents and assess what shapes their behavior

To address those risks, Palo Alto Networks organizes its proposal into four stages: discover, assess, protect, and govern. The company applies that sequence to AI-assisted coding, employee knowledge work, and autonomous agents across development, deployment, and operation. It says the aim is to retain the development speed Claude enables while placing controls where risks arise. Discovery comes first because an organization must know where an agent operates before it can apply policy there.

Finding that activity requires looking inside developer environments as well as employee applications. Claude can operate in terminals, integrated development environments, the applications developers use to write and work with code, local desktop software, MCP connections, and enterprise APIs. Palo Alto Networks positions Cortex Agentic Endpoint Security as a way to identify coding agents, extensions, and MCP servers, which provide tools or data through MCP. The company says this helps expose Shadow AI: AI use outside established organizational visibility or oversight.

Employee-facing use needs visibility at its own points of access. Palo Alto Networks proposes Prisma Browser and Prisma SASE for access and data protection in those workflows. SASE, short for secure access service edge, combines network access and security functions delivered through cloud services. These controls complement endpoint discovery by covering the browser and network environments through which employees use AI services.

Once teams locate the agents and their connections, they can assess the components those agents depend on. Approval of an application does not establish the behavior of every reusable skill, open-source model, or third-party integration it uses. Palo Alto Networks says Prisma AIRS AI Supply Chain Security scans models and agent skills for malicious code, backdoors, and other risks before deployment. This puts a security check before a component can influence an operational task.

Component inspection still leaves the behavior of the assembled workflow to examine. Palo Alto Networks describes AI Red Teaming as testing AI applications and agent workflows for weaknesses an attacker could exploit. A scan examines a model or skill, while workflow testing examines how connected parts behave together. Both support predeployment assessment because interactions between individually reviewed components can create additional risks.

Place controls before model processing and during execution

Predeployment assessment addresses what enters the system, but live requests can introduce new instructions or sensitive data. Through Claude Enterprise’s native inference hooks, connection points before the model processes a request, Palo Alto Networks says Prisma AIRS inspects prompts covered by those controls. The company identifies sensitive information leaving its permitted context and malicious inputs reaching the model as concerns. Inspection here allows policy to address a request before it influences the model’s response.

A checked prompt can still lead to several later interactions, so execution needs its own coverage. For Claude Code on developer endpoints, Palo Alto Networks says Prisma AIRS integrates with Cortex Agentic Endpoint Security to inspect prompts, responses, MCP tool calls, and supported network interactions. Teams evaluating that coverage need to map it to the interactions their own agents perform, including which network interactions the integration supports.

Inspection becomes enforcement when policy can affect the work taking place on the machine. Palo Alto Networks says the same integration applies endpoint security policies to agent workflows. A request check examines what the model is asked to process, while endpoint rules address activity where the resulting actions occur. These controls serve different decisions because one permitted task may produce several tool calls, file changes, and commands.

Custom applications place those decisions at different integration points. For software built with the Claude API, Palo Alto Networks says Prisma AIRS provides protection during execution through AI Gateway or direct API integration. Teams building such services need controls where the application sends requests and receives responses. Coverage on a developer’s endpoint does not automatically extend to every service that developer builds.

The application’s connection points leave a separate question about the agent’s authority. Palo Alto Networks describes Agent Identity Security as providing verifiable agent identities and just-in-time, least-privilege access to enterprise resources. In practice, an agent receives access when needed, limited to the resources and actions required for its task. The aim is to reduce dependence on standing credentials that remain available between tasks.

Limited access reduces potential harm, but it cannot determine whether an instruction is safe. Identity controls establish which agent is acting and what authority it receives; content inspection examines unsafe material; execution policies govern activity in the operating environment. An agent with narrow permissions can still encounter malicious instructions, and an inspected prompt can still lead to a later action requiring a separate decision. Coordinating these controls lets each address the part of the workflow it can actually govern.

Govern shared traffic and consumption

As those workflows cross shared services, governance must also determine which connections are allowed and how much activity they may generate. Palo Alto Networks says Prisma AIRS AI Gateway centralizes policy for large language model, or LLM, traffic, alongside MCP and A2A traffic. A2A means agent-to-agent communication, through which agents exchange information or coordinate work. The company describes controls for routing, access, quotas, and rate limits, giving teams ways to set permitted destinations and usage boundaries.

Those boundaries need ongoing observation because patterns of use can change after deployment. Palo Alto Networks describes analytics showing where and how AI is consumed and the associated costs. Security and engineering teams can use that view to examine consumption alongside access and traffic rules. Cost visibility then becomes part of operating shared AI services, connected to the policies that determine who can use them and at what volume.

Test coordination across security systems

Applying those policies requires cooperation among systems that already protect enterprise users. An agent can run on a managed endpoint, connect to an enterprise application, use an identity, and exchange data over network services. Each security domain sees a different portion of the task. Reviewing them separately can leave teams unable to reconstruct what the agent accessed, created, or did.

Palo Alto Networks proposes connecting AI security with network protection, browser protection, identity controls, and Cortex security operations. In its approach, browser and network controls address their respective interactions, identity controls constrain access, and security operations provide a place to manage activity across the environment. These systems already serve people using the same resources. The additional work is to connect their decisions and observations to agent behavior.

The company calls this “platformization for the AI era,” presenting its portfolio as the way to coordinate that work. Palo Alto Networks benefits if enterprises meet that requirement through its products, so the operating principle and the purchasing decision deserve separate evaluation. Cross-system workflows require cooperating controls; choosing a single-vendor platform requires examining how that cooperation works in the enterprise’s environment. A broad product portfolio describes intended coverage, while a workflow test shows how its parts operate together.

That test can follow an approved agent through a real task, starting with discovery of its environment and connections. Before execution, evaluators can identify which checks assessed its dependencies and complete workflow; during execution, they can trace decisions about inputs, tool interactions, commands, and delegated access. They can then locate the policies governing traffic, consumption, and costs, and establish which system records each decision. Acceptance depends on demonstrating that the relevant controls operate at the required points in the task.

Key executive takeaways

• Approval opens a second security decision: Claude agents can access private code, credentials, and commands within granted permissions. Security owners need explicit policies for the resources agents may access and the actions they may perform.
• Map agent access and dependencies: Developer endpoints, reusable skills, MCP connections, and third-party integrations shape agent behavior. Endpoint and application owners need an inventory of those connections to identify exposure and assign controls.
• Assess components and workflows: Security teams need predeployment checks for malicious code and backdoors in models and skills, alongside tests of complete agent workflows. Connected components can introduce risks through their interactions.
• Control live requests and execution: Application and endpoint owners need checks at prompts, responses, tool calls, and command execution. Verifiable agent identities and task-limited access reduce reliance on standing credentials.
• Govern traffic and consumption: Platform owners need policies for permitted destinations, access, quotas, and rate limits across model, tool, and agent communications. Usage and cost analytics help them adjust those boundaries as adoption grows.
• Validate coordination through real tasks: Security and engineering teams can trace an approved agent through a representative workflow to verify enforcement and decision records. Evaluate Palo Alto Networks’ proposed platform against demonstrated coverage in the enterprise’s own environment.