Three jobs under one portfolio

“AI firewall” is too vague for an architecture diagram. It can refer to at least three control points:

  1. governing employees who use public or enterprise generative-AI applications;
  2. inspecting prompts, responses, data, and tool calls in an AI application you operate; and
  3. scanning model artifacts and testing models before deployment.

Palo Alto Networks markets several capabilities across AI Access Security and Prisma AIRS. “Precision AI” is also used as an umbrella description for the company’s combination of machine learning and other AI techniques. It should not be treated as a separate enforcement product in a bill of materials. Map the requirement to the specific product, license, deployment mode, and policy action.

AI Access Security

AI Access Security is aimed at workforce use of generative-AI applications. Current documentation describes visibility into GenAI applications and users, classifications such as sanctioned or unsanctioned, and policy controls delivered through supported NGFW and Prisma Access deployments.

This control point is useful for questions such as:

  • Which AI applications are being used?
  • Which users are allowed or blocked?
  • Can a business-approved enterprise account be allowed while a public account is restricted?
  • Can uploads or particular application functions be controlled?

It does not automatically secure the internals of an AI service. Seeing that a user opened a sanctioned chatbot is different from validating every prompt, response, retrieval source, and tool call inside an application your developers built.

Evaluation should use the actual browsers, clients, identity sources, and network paths in scope. Test encrypted-traffic handling, unmanaged devices, custom AI applications, browser extensions, enterprise and personal accounts, and what happens when an application changes domains or transport behavior. Confirm whether visibility depends on decryption and how privacy exceptions are handled.

Prisma AIRS runtime protection

Prisma AIRS AI Runtime provides controls for AI applications. The API Intercept workflow lets an application send prompts or model responses to a scanning service and receive a threat assessment and recommended action. Palo Alto Networks documents protections for model, application, data, and agent risks, including prompt injection and sensitive-data exposure.

That integration choice matters. An API call in the application path gives developers explicit control over what is scanned and what to do with a verdict, but it also adds a dependency. The application needs defined timeout behavior, regional routing, authentication, logging, and a decision on whether a scan failure blocks or allows the request.

The current API documentation lists concrete constraints, including one API key per deployment profile, regional limits on keys, and payload-size and batch limits. Those limits can change, but their existence is the point: a runtime control must be tested with the largest prompts, responses, files, and request rates the application will produce.

Network-intercept and AI Runtime Firewall options place enforcement differently. Confirm which protocols, cloud environments, traffic paths, and deployment modes are supported for the proposal. “No code change” and “complete visibility” are claims to verify in the target architecture, not assume from the category name.

Models and agents

Prisma AIRS Model Security scans model artifacts and metadata. Palo Alto Networks documents checks for deserialization threats, backdoors, runtime threats, file formats, model location, and license metadata. Its installation guidance describes CLI and SDK options for scanning internal and external models.

This is a supply-chain control. It can help identify a risky artifact before it reaches a serving environment. It does not establish that a model is accurate, unbiased, suitable for a business decision, or legally usable in every jurisdiction. Those require separate governance and testing.

Agent protection adds another boundary. An agent may call tools, retrieve data, and modify systems, so inspecting natural-language content alone is not enough. Current Prisma AIRS documentation describes detection for attempts to expose function schemas, invoke tools directly, or manipulate memory, as well as an MCP security service for validating tool invocations.

For an agent, record the complete authorization chain: user identity, agent identity, model, tool, target resource, requested action, policy decision, and result. Limit each tool’s credentials independently. A detection product should complement those controls, not become the only thing standing between a prompt and a privileged action.

Build a useful evaluation

Start with an inventory. List workforce AI applications, internally developed AI services, model repositories, retrieval data, agents, and tools. Assign an owner and data classification to each. Then select the control point that matches the risk.

Use a test set drawn from the real application, with sensitive data removed or synthesized. Include ordinary requests, multilingual content, long context, code, files, indirect prompt injection in retrieved documents, sensitive-data leakage, malformed input, and benign content that resembles an attack. Measure false positives, false negatives, added latency, timeout behavior, and analyst workload.

Keep vendor claims and your results separate. A vendor’s detection taxonomy explains what the product is designed to find. Your test shows how the proposed configuration behaves on your traffic. Both are useful; they answer different questions.

Sources

Source note: Product documentation describes intended functions and published limits. Test detection quality, latency, privacy handling, supported deployment modes, and failure behavior in the target environment.