Protect AI's public category is AI/ML security posture management (AI-SPM): scanning models, training data, and notebooks for embedded threats before they enter production, and maintaining an inventory of AI/ML assets across the pipeline. Teams researching alternatives are usually trying to answer one of two different questions — "is our AI supply chain safe" or "is our deployed agent's runtime behavior safe" — and those two questions point toward different categories of tooling.
What Protect AI is built for
Protect AI's public materials describe a platform built around securing the machine learning development lifecycle: scanning model files for embedded malicious code, checking training notebooks and pipelines for security issues, and giving security teams visibility into what models and datasets exist across an organization's AI estate. The open-source tool ModelScan, which the company publishes, is a well-known example of the underlying technique — model serialization formats like pickle can execute arbitrary code on load, and a scanner that inspects the artifact before it is loaded closes a real and well-documented supply-chain gap.
The vendor's portfolio is broader than artifact scanning alone. Recon adds automated red-teaming against deployed models and applications, and Layer extends coverage into runtime LLM monitoring — so "Protect AI" as a shortlist entry can mean anything from a pre-deployment scan step to a runtime-observability product, depending on which part of the portfolio is actually being priced.
This is a genuinely useful and distinct security discipline. Data science teams routinely pull pre-trained models from public hubs, and without a scanning step, "download and load a model" is functionally similar to "run an unreviewed binary." Palo Alto Networks' acquisition of Protect AI was publicly announced in 2025, which places the technology inside a much larger enterprise security portfolio — a pattern that has repeated across the AI-security space as established security vendors acquire AI-native point products.
The question AI-SPM answers, and the one it doesn't
AI-SPM tooling answers a pre-deployment question: is this artifact — a model file, a notebook, a dataset — safe to bring into our environment. That question is answered once, at the point the artifact enters the pipeline (or on a recurring scan cadence), and the answer is about the artifact itself, not about what happens after it is running.
A separate and equally real question only appears once an agent is live: is this specific agent, right now, authorized to call this tool, read this data, or spend this budget, and can we prove afterward exactly what it did. That is a runtime authorization and audit question, not an artifact-scanning question, and it is not what AI-SPM tooling is designed to answer. The distinction matters because a perfectly clean, fully scanned model can still be wired into an agent that is over-privileged, has no rate limits, and produces no forensic trail — the artifact was safe; the deployment wasn't governed. Our AI agent runtime security post covers what that governance layer needs to do, and the difference is laid out directly in runtime security vs. security posture.
The evaluation lenses that actually separate this category
- Artifact vs. behavior. Does the tool inspect things before they run (files, weights, code) or things while they run (tool calls, API requests, spend)? Most vendors are strong on one side; ask directly which side yours covers.
- Point-in-time vs. continuous. A scan at ingestion catches a known-bad artifact once. Continuous monitoring catches a model or agent that starts behaving differently after it has already passed the initial check — see continuous authorization for why a one-time check is not the same guarantee as an ongoing one.
- Supply chain scope. Does coverage extend only to model files, or also to the surrounding pipeline — notebooks, third-party MCP servers, and the tools an agent is permitted to call? Securing the agent supply chain covers the wider surface.
- Where findings go. A scanner that produces a report is different from a control plane that blocks the deployment or the action outright. Ask whether a finding results in an enforced gate or an item on a dashboard someone has to act on manually.
Comparing approaches, not vendor checkboxes
| Question you're asking | Approach to evaluate | What it verifies |
|---|---|---|
| "Is this model file safe to load?" | Artifact scanning (AI-SPM) | The artifact itself, at the point it enters the pipeline |
| "Do we know every model and dataset we have?" | AI/ML asset inventory | Coverage and shadow-asset discovery, not runtime behavior |
| "Is our production agent doing only what it's allowed to do?" | Runtime governance / agent security | Live tool calls, credential use, and actions, continuously |
| "Can we prove what an agent did after the fact?" | Audit and identity layer | Attribution and tamper-evident evidence, independent of the artifact's cleanliness |
When a different category is the right answer
If your open question is "we pull models from public hubs and have no idea what's in them," AI-SPM scanning is exactly the right tool, and Protect AI's public category is a reasonable place to start evaluating. If your open question is "our agents are already in production, calling tools and making decisions, and we can't say with confidence what any one of them did last week," that is a runtime governance question — it needs per-agent identity, in-line policy enforcement on tool calls, and an audit trail, which is a different layer than artifact scanning. Praesidia is one option in that runtime layer, covering agent identity, guardrails, and audit evidence as an enforced control plane rather than a pre-deployment scan. Many mature programs run both: a supply-chain scanning step before anything is deployed, and a runtime governance layer for everything after. Our AI agent security guide maps the fuller category set, and platform-bundled vs. pure-play AI agent security covers how these categories tend to bundle or stay separate in vendor offerings.
Evaluation checklist
Before shortlisting an AI-SPM alternative, or deciding you need a different category entirely, get clear answers on:
- Coverage boundary — does scanning extend to notebooks and pipelines, or only packaged model files?
- Trigger point — does a scan run once at ingestion, on every deployment, or on a recurring schedule?
- Enforcement vs. reporting — does a finding block the deployment, or does it produce a report someone has to act on?
- Deal scope, not vendor capability — Protect AI's portfolio spans model scanning, automated red-teaming, and runtime LLM monitoring, and the technology now sits inside Palo Alto Networks' Prisma AIRS. The useful question isn't whether the vendor covers runtime at all; it's which of those layers are actually included in the deal you're pricing, and whether the runtime coverage you're buying extends to agent tool-call authorization or stops at model inference.
- Inventory freshness — how does the tool discover new models and agents that appear outside a formal deployment pipeline, since shadow AI assets are common in fast-moving teams? Building an AI agent inventory covers the discovery problem directly.
Operating model considerations
AI-SPM tools are typically adopted by a platform, MLOps, or data-science-security team, and integrated into an existing CI/CD or model-registry workflow — the scan becomes a gate in a pipeline that already exists. That integration point matters when comparing options: a scanner that plugs cleanly into your existing model registry and deployment gate will get used consistently; one that requires a parallel workflow tends to get skipped under deadline pressure, which quietly reintroduces the exact risk the tool was bought to close. Ask any vendor for a concrete description of how the scan step fits into a deployment pipeline you already run, not just a description of what the scan detects.
The same question applies on the runtime side: an agent-governance layer that requires wiring every tool call through a new proxy or SDK gets adopted unevenly across teams, while one that can be applied at the point agents already connect to tools and MCP servers tends to get full coverage faster. Registering and governing MCP servers covers what that connection point looks like in practice for agentic estates specifically.
Common questions
What is Protect AI known for? Per its public materials: AI/ML security posture management — scanning models, notebooks, and training pipelines for embedded threats, and maintaining visibility into an organization's AI/ML asset inventory. The open-source ModelScan tool reflects its core scanning approach.
Is AI-SPM the same thing as agent runtime security? No. AI-SPM answers whether an artifact is safe to bring into the environment, evaluated before or at deployment. Runtime agent security answers whether a live agent's actions — tool calls, data access, spend — are authorized and auditable, evaluated continuously after deployment. Both are legitimate, and most mature programs need both.
Does a clean AI-SPM scan mean an agent is safe to run unsupervised? No — a clean scan tells you the artifact itself (model file, notebook) had no detected embedded threats at the time it was checked. It says nothing about whether the agent built on that artifact has appropriate tool scopes, spend limits, or an audit trail once it is live.
What changed with the Palo Alto Networks acquisition? Palo Alto Networks' acquisition of Protect AI was publicly announced in 2025. As with other consolidations in this space, buyers evaluating the technology should confirm current roadmap and support commitments directly with the vendor rather than assuming pre-acquisition positioning is unchanged.
What is the single best test for whether you need a runtime layer, not just a scanner? Ask whether you can currently answer, for any agent, "what tools did this specific agent call in the last 24 hours, and was each call within its assigned scope." If artifact scanning is your only AI security tooling, you cannot answer that question — which is the signal you need a runtime governance layer alongside it.