What each is for, where Prisma AIRS is strong, and how the two differ, capability by capability.
Palo Alto Networks · Based on the vendor's public documentation, last reviewed .
Prisma AIRS
Palo Alto Networks' AI security platform: an AI gateway for model, MCP and agent-to-agent traffic, runtime inspection, agent identity, model supply-chain scanning, red teaming and inventory, with on-device enforcement for coding agents through Cortex AES.
Managed from Strata Cloud Manager. The AI Gateway runs as SaaS, or hybrid with its data plane in your own Kubernetes cluster; the documentation lists the Americas region. Runtime Security also inspects traffic through an API, network intercept and Istio. Coding-agent protection needs a Cortex AES subscription.
Vekri
Runtime authorization for AI agents. Vekri Gateway checks every tool call against a verified identity, a task scope and Cedar policy; privileged writes wait for a person's approval of the exact operation; a broker executes with credentials the agent never sees.
In Vekri's cloud, or self-hosted in your Kubernetes cluster with no connection to Vekri.
Side by side
| Capability | What it means | Vekri | Prisma AIRS |
|---|---|---|---|
| Decides each tool call inline | Every agent tool call is allowed or denied before it reaches the protected system. | Yes Vekri Gateway decides every MCP tool call sent through it before the broker executes it; a denied call never reaches the system. It is a boundary only when it is the only path to that system. | Documented The AI Gateway sits inline for model, MCP and A2A traffic, and Agent Identity Security restricts which MCP tools a user-agent pair can run. On coding agents, AIRS hooks check external MCP tool calls before they execute. [3] [4] [6] [8] |
| Verified workload identity | An agent running as a workload proves who it is with a credential the platform issued, not a shared key. | Yes Kubernetes projected service-account tokens, verified with TokenReview before Vekri issues a short-lived token for the run; every call is then authenticated. SPIFFE X.509-SVIDs from a configured trust bundle (no Workload API yet). | Partly Agent Identity Security gives each registered agent a system-generated Agent ID and OAuth 2.1 client credentials. Attesting an agent's identity from its runtime, for example with Kubernetes or SPIFFE, is not described. [4] |
| Employee agents use company SSO | Agents that employees run sign in as that employee, through the company identity provider. | Yes Vekri is the MCP authorization server for Claude Code and federates to your OpenID Connect provider. SAML sign-in is not available yet. | Partly Cloud Identity Engine connects the AI Gateway to the company identity provider, and audit logs record both the agent and the delegating user. How an employee's agent signs in is not described. [4] |
| Task-scoped permissions from the server | What an agent may do is set per task by the server, not by the agent or its prompt. | Yes A run scope for workloads, or a protected access assignment for employees. The effective permission is always an intersection, never a widening. | Not in public docs Policies restrict MCP tools per user-agent pair, and Palo Alto Networks describes just-in-time, least-privilege access for agents. A permission scope issued by the server for each task is not described. [3] [4] |
| Policy as code, deny by default | Decisions come from versioned policy, and anything not allowed is refused. | Yes Cedar over typed operations. Unknown operations and evaluation errors are denied, and a revision can be simulated before it is published. | Partly Security profiles in Strata Cloud Manager set an allow or block action per detection, and workspace and Agent Identity policies govern models and MCP tools. A published policy language and deny-by-default behavior are not described. [4] [7] [8] |
| Approval of the exact operation | A person approves one specific operation, and the approval cannot be reused for another. | Yes Privileged writes wait for another person to approve that operation, bound to its digest, short-lived and single use, with separation of duties. | Not in public docs Approval of a specific operation by another person is not described in the public documentation. With Cortex AES, a developer whose action was blocked can request an exception. [9] |
| Agent never holds backend credentials | Secrets for the protected system stay out of the agent's reach. | Yes A broker executes with narrowly scoped Kubernetes or GitHub App credentials. Incoming tokens are never forwarded. | Partly The AI Gateway stores LLM provider credentials and authenticates to providers itself, so applications use gateway keys instead of raw provider keys. Brokering credentials for MCP servers or other backends is not described. [2] [8] [10] |
| Audit evidence of decision and outcome | Each call leaves a durable record of what was decided and what happened. | Yes Intent is recorded durably before execution and the outcome after; an uncertain outcome is never retried blindly. | Documented The gateway records who asked what, the response and the cost; Agent Identity Security keeps dual-attribution logs of the agent and delegating user; Cortex AES records each verdict by device, agent, session and policy. [2] [4] [6] |
| AI agents on workstations | Finds AI coding agents and other AI applications on employee devices, and watches or controls what they do there. | Partly Vekri Endpoint discovers coding agents, desktop and IDE AI apps, local models and their MCP servers on macOS and Linux, and its local MCP gateway decides each MCP tool call sent through it (Claude Code verified connecting; tool calls verified with an MCP client library). On macOS, a network gateway mediates MCP requests to approved remote servers, and agent control stops AI agents the organization has not allowed. Hooks observe built-in tools without blocking them; Windows is not supported. | Documented Cortex AES deploys AIRS hooks for Claude Code, Cursor, Codex, GitHub Copilot and Antigravity, checks prompts, MCP tool calls and web requests, and enforces the verdict on the device. It requires a Cortex AES subscription. [6] [9] |
| Prompt and output inspection | Detects prompt injection or sensitive data in what models read and write. | Partly Tool results on Vekri Gateway and the local MCP gateway are inspected for prompt injection before the agent reads them; sensitive-data categories are detected on the device, off by default. Browsers and file uploads are not inspected. | Documented Prisma AIRS detects prompt injection, sensitive data and credential leakage, malicious URLs and toxic content, masks sensitive data in responses, and inspects streamed responses chunk by chunk. [4] [6] |
| Systems covered | Which systems, platforms or agents the product works with. | Kubernetes and GitHub, with GitLab, PostgreSQL, MySQL, MongoDB, Slack, Jira, Linear, Asana, ClickUp, monday.com, HubSpot, Pipedrive, Zendesk, Freshdesk and custom OpenAPI connectors in preview. | More than 1,600 models from over 50 providers through the AI Gateway, MCP servers and A2A agents, AI workloads on EKS, GKE and AKS through Istio, and Claude Code, Cursor, Codex, GitHub Copilot and Antigravity through Cortex AES. |
| Deployment | How the product is delivered. | In Vekri's cloud, or self-hosted in your Kubernetes cluster with no connection to Vekri. | Managed from Strata Cloud Manager. The AI Gateway runs as SaaS, or hybrid with its data plane in your own Kubernetes cluster; the documentation lists the Americas region. Runtime Security also inspects traffic through an API, network intercept and Istio. Coding-agent protection needs a Cortex AES subscription. |
Every agent tool call is allowed or denied before it reaches the protected system.
An agent running as a workload proves who it is with a credential the platform issued, not a shared key.
Agents that employees run sign in as that employee, through the company identity provider.
What an agent may do is set per task by the server, not by the agent or its prompt.
Decisions come from versioned policy, and anything not allowed is refused.
A person approves one specific operation, and the approval cannot be reused for another.
Secrets for the protected system stay out of the agent's reach.
Each call leaves a durable record of what was decided and what happened.
Finds AI coding agents and other AI applications on employee devices, and watches or controls what they do there.
Detects prompt injection or sensitive data in what models read and write.
Which systems, platforms or agents the product works with.
How the product is delivered.
More comparisons
Check Point Software Technologies
Lakera, part of Check Point since October 2025, screens prompts, model output and agent tool calls for prompt attacks, data leakage and risky actions. Applications send content to its Guard API and act on the result.
Lasso Security
Lasso discovers AI agents and applications, red-teams them and enforces policy at runtime through a proxy, an AI or MCP gateway, or coding-agent hooks, with prompt-injection detection, data masking and checks on agent intent.
Noma Security
Noma Security covers SaaS, cloud and endpoint agents with posture management, red teaming, runtime detection and response, and access control, enforced through the gateways, agent hooks, SDKs and APIs a company already runs.
Pillar Security
Pillar covers AI discovery, posture, red teaming, runtime guardrails and governance. Its Agentic Endpoint writes hooks into coding agents on developers' machines and can block an action before it runs.
SentinelOne
Prompt Security, part of SentinelOne, governs employee use of AI tools, protects homegrown AI applications with a runtime firewall, and discovers and risk-scores agents and MCP servers, with an MCP Gateway that can allow, block, filter or redact.
Zenity
Zenity secures AI agents on SaaS platforms, cloud agent services and employee devices, with an agent inventory, posture checks, detection and response, and Runtime Boundaries that allow or block agent actions.
Contact Sales
Talk to us about the AI your organization uses, the systems agents reach and how you deploy: in Vekri's cloud, or inside your own Kubernetes cluster.