- Most existing cloud and AI security platforms enforce posture at scan time, not at the moment an agent calls a tool, escalates a privilege, or exfiltrates a file. That gap is where autonomous agents create net-new risk.
- The category split that matters is runtime enforcement versus posture reporting. A platform that only inventories your agents and flags misconfigurations cannot block a prompt injection mid-session.
- Per-agent pricing scales predictably; per-token pricing does not. A 50-agent deployment can cross six figures in token-based billing faster than most teams model in a POC.
- Purpose-built agent security vendors (Zenity, Noma, Straiker, Lasso) are structurally different from repositioned AI-SPM tools that added “agentic” to their category names in 2024 and 2025.
- The demo questions that reveal enforcement depth are not on any vendor’s website. They are listed at the end of this article.
The best AI agent security platforms in 2026 are those that enforce policy at runtime, at the level of individual tool calls and action approvals, rather than reporting agent inventory after the fact. Purpose-built vendors including Zenity, Noma, Straiker, Lasso Security, and Operant AI provide identity-level and action-level controls. Repositioned platforms from Palo Alto Networks, Zscaler, and Wiz provide strong posture management but structurally cannot intercept an agent action already in progress without a proxy or sidecar component in the data path.
Why Your Current AI Security Platform Probably Cannot Control Autonomous Agents
The framing that “my cloud security platform will cover this” breaks down at one architectural fact: posture management reads configuration state. It does not sit in the execution path of an agent that is currently deciding whether to call a database API, send an email, or spin up a compute resource.
An autonomous agent running inside a LangChain workflow or a Microsoft Copilot Studio app makes tool calls at runtime, under a service account or OAuth token, with permissions that were valid when provisioned and may have drifted since. A CSPM or AI-SPM that scans configuration nightly will report that the agent has excessive permissions. It will not intercept the call at 2:47 AM when a prompt injection causes the agent to exfiltrate a customer table.
Runtime enforcement requires one of two things: a proxy in the request path (adding latency, measured in milliseconds for inline inspection), or an eBPF-based or sidecar-based runtime sensor that can observe and block at the kernel or container boundary. Posture-only platforms have neither by design. That architectural gap is the reason a dedicated evaluation is worth running.
How SecurityOpsWire Scored These Platforms: The RACE Framework
To create a comparison that is not just a reshuffled vendor feature list, SecurityOpsWire used a four-axis framework for evaluating each platform. We are calling it the RACE Framework: Runtime Enforcement, Agent Identity, Coverage Breadth, and Economics.
Runtime Enforcement asks whether the platform can block or pause an agent action before it completes, not just log it afterward. Inline proxy, eBPF sensor, and sidecar deployment all qualify; scan-only or API-polling do not.
Agent Identity asks whether the platform manages the non-human identities agents run under, including OAuth tokens, service accounts, API keys, and session credentials, with the ability to detect privilege drift and enforce least-privilege at provisioning time.
Coverage Breadth asks how many agent frameworks, orchestration layers, and tool-call protocols the platform supports natively: LangChain, AutoGen, Copilot Studio, CrewAI, and the Model Context Protocol (MCP) tool-access layer that is increasingly the plumbing under multi-agent systems.
Economics asks how the pricing model behaves as agent count grows: per-agent seat, per-token consumption, per-API-call volume, or flat platform fee. A platform cheap at 10 agents can become prohibitive at 500 without the team realizing it during a POC.
What to Evaluate Before You Build a Shortlist
Five criteria separate the platforms that will actually reduce agent risk from the ones that produce a compliance artifact.
First, where does enforcement happen? If the vendor says “we analyze agent logs,” that is detection after the fact. Ask specifically whether their sensor or proxy sits in the data path before the tool call completes.
Second, how are agent identities modeled? Agents do not authenticate like humans. They use service principals, OAuth tokens with delegated scopes, and API keys that rotate infrequently. A platform that cannot inventory and govern those identities cannot enforce least-privilege on them.
Third, what is the proxy latency budget? Inline enforcement adds latency. For a customer-facing agent, 200 milliseconds of added inspection time may be acceptable. For a high-frequency trading tool or a real-time voice agent, it may not. Get a real number from the vendor under production-equivalent load, not a lab benchmark.
Fourth, how much tuning is required before the platform stops producing false positives at a rate that causes alert fatigue? A platform that fires on every multi-step agent workflow without baseline learning will be disabled within two weeks of deployment.
Fifth, how does pricing scale? Get the per-agent rate, ask what counts as an “agent” in their licensing model (a Copilot action, a LangChain chain, a CrewAI crew member?), and model the cost at 10x your current deployment before signing anything.
The 17 AI Agent Security Platforms: Capabilities, Gaps, and Operating Costs
| Platform | Runtime Enforcement | Agent Identity | MCP / Tool-Call Coverage | Pricing Model | Best Fit |
|---|---|---|---|---|---|
| Zenity | Yes (inline) | Yes | Yes | Not publicly disclosed | Microsoft 365 / Copilot-heavy orgs |
| Noma Security | Yes (inline) | Yes | Yes | Not publicly disclosed | ML pipeline and model governance teams |
| Straiker | Yes (proxy-based) | Yes | Yes | Not publicly disclosed | Full-lifecycle agent deployment, any cloud |
| Lasso Security | Yes (inline gateway) | Partial | Yes | Not publicly disclosed | LLM app developers, prompt injection defense |
| Prompt Security (SentinelOne) | Yes (proxy) | Partial | Yes | Not publicly disclosed post-acquisition | Orgs already on SentinelOne EDR |
| WitnessAI | Yes (inline) | Yes | Partial | Not publicly disclosed | Regulated industries, auditability requirements |
| Operant AI | Yes (eBPF-based) | Yes | Yes | Not publicly disclosed | Kubernetes-native agent workloads |
| Lakera | Yes (Lakera Guard proxy) | Partial | Partial | Not publicly disclosed | Prompt injection defense, LLM guardrails |
| CalypsoAI | Yes (proxy) | Partial | Partial | Not publicly disclosed | Government and defense contractor environments |
| Invariant Labs | Yes (policy engine) | Partial | Yes | Open-source core; enterprise pricing not disclosed | Teams building custom agentic policy |
| Aporia | Yes (guardrails proxy) | Partial | Partial | Not publicly disclosed | Model output reliability and hallucination control |
| Palo Alto Networks Prisma AIRS | Partial (WAAP + inline for some paths) | Partial | Partial | Not publicly disclosed | Existing Prisma or XSIAM customers |
| Zscaler AI Security | Partial (SSPM / posture-heavy) | Partial | Limited | Not publicly disclosed | Orgs already routing traffic through Zscaler proxy |
| Obsidian Security | No (posture + ITDR) | Yes (SaaS identity focus) | Limited | Not publicly disclosed | SaaS identity risk, non-human identity governance |
| Wiz AI Security Posture Management | No (posture only) | Partial | Limited | Not publicly disclosed | Cloud-native teams with existing Wiz investment |
| Protect AI | No (model and supply chain focus) | No | Limited | Not publicly disclosed | ML model security, AI supply chain scanning |
| Lacework AI Security | No (anomaly detection, post-fact) | Partial | Limited | Not publicly disclosed | Teams already on Lacework CNAPP |
No vendor in this category publicly discloses per-agent or per-token pricing as of July 2026. Every platform on this list quotes per environment. That fact alone is operationally significant: you cannot model your total cost of ownership without a direct sales conversation, and you should treat any vendor that refuses to give you a per-agent rate during a POC as a pricing risk.
Purpose-Built Platforms: Where Runtime Enforcement Is the Core Product
Zenity
Zenity focuses specifically on securing AI agents built on low-code and no-code platforms, including Microsoft Copilot Studio, Power Automate, and ServiceNow. Its enforcement model intercepts agent decisions at what the company describes as the decision point, where context and intent converge before an action executes. For organizations running heavy Microsoft 365 deployments with citizen-developer-built Copilot agents, Zenity currently has no direct competitor that covers that surface equally well.
The operational cost to consider: Zenity requires integration with each agent-building platform separately. If your organization runs a mix of custom Python agents and Microsoft Copilot agents, you will need to map coverage gaps manually. Pricing is not publicly disclosed as of July 2026.
Noma Security
Noma covers both the development phase (scanning training data, model provenance, and pipeline dependencies) and the runtime phase (agent behavior monitoring and tool-call enforcement). This dual coverage is relevant for security teams that own both the AppSec side of AI development and the operational security of deployed agents. Noma’s model governance capabilities are deeper than most runtime-focused competitors, which matters for teams subject to the EU AI Act or internal model review requirements.
The gap: Noma’s documentation and public materials focus heavily on the development and pipeline side. Teams that need pure runtime enforcement without a development-phase workflow may find the platform over-specified for their use case.
Straiker
Straiker positions as a full-lifecycle platform, covering agent discovery, identity management, runtime policy enforcement, and red-team testing of deployed agents. Its proxy-based architecture means it can enforce on agents regardless of which framework built them, which is a structural advantage over platforms that instrument at the framework SDK level and therefore have gaps when agents are built with unsupported libraries.
The tuning burden for Straiker’s policy engine is real. Teams that deploy it without a dedicated detection engineer to write and iterate on agent behavior policies will find the default rules either too permissive or too noisy. Budget two to four weeks of policy tuning before expecting reliable enforcement signals.
Lasso Security
Lasso Security operates as an inline gateway that inspects both prompts and responses, with particular depth in detecting prompt injection, data exfiltration through model output, and jailbreak attempts against deployed LLM applications. For teams building customer-facing AI products where prompt injection is the primary attack surface, Lasso’s detection depth exceeds most competitors.
The identity management capability is partial. Lasso does not provide the non-human identity governance layer that Zenity or Noma do. Teams that need both prompt-level defense and service-account-level identity control will need to pair Lasso with a separate identity governance tool.
Operant AI
Operant AI uses eBPF-based runtime sensing to observe and enforce on agent workloads running inside Kubernetes clusters, without requiring a proxy in the HTTP request path. This is architecturally significant: eBPF enforcement adds less latency than a proxy-based approach and does not require routing changes in the network layer. For teams running high-throughput agent workloads in Kubernetes where every added millisecond matters, Operant is the strongest technical fit.
The trade-off is coverage outside Kubernetes. Operant is not designed for agents running in serverless environments, browser-based agents, or SaaS-hosted automation platforms. A team with mixed deployment patterns will face coverage gaps.
Invariant Labs
Invariant Labs publishes an open-source policy engine for agentic AI, which gives security engineering teams the ability to write and version-control agent behavior policies in code, similar to how detection-as-code works in modern SIEM workflows. The open-source core is genuinely useful for teams that want to build custom enforcement logic without vendor lock-in. Enterprise packaging and pricing are not publicly disclosed as of July 2026.
WitnessAI
WitnessAI emphasizes auditability and compliance-grade logging of every agent action, which matters for regulated industries where an auditor will ask for a complete record of what an AI agent did with customer data. The platform’s inline enforcement architecture means it can both block actions and produce the audit trail from a single sensor. For a healthcare organization or a financial institution under strict data governance requirements, WitnessAI’s audit depth is operationally relevant in a way that lighter-weight guardrail products are not.
Guardrail and Prompt-Defense Platforms: Narrower Scope, Deeper in One Layer
Lakera
Lakera Guard operates as a proxy layer specifically designed to detect and block prompt injection, data leakage through LLM outputs, and off-topic or policy-violating model behavior. Lakera’s detection models are trained on a large corpus of adversarial prompt examples, and the company publishes research on prompt injection patterns that practitioners cite regularly.
Lakera does not manage agent identities or govern tool-call permissions. It is a prompt-and-response filter, not an agent security platform in the full sense. Teams that conflate the two will underbuy on identity controls and overpay for a capability they already have if they also run an API gateway with input validation.
CalypsoAI
CalypsoAI has a meaningful installed base in government and defense contractor environments, where the requirements for content filtering, model output inspection, and audit logging are more demanding than in commercial sectors. Its proxy architecture supports air-gapped and on-premises deployments, which matters for agencies that cannot route traffic through a cloud-based SaaS proxy.
Commercial enterprises with standard cloud deployments will find CalypsoAI’s feature set oriented toward use cases they may not have. The on-premises capability that is a differentiator for a cleared defense contractor is overhead for a SaaS startup.
Aporia
Aporia started in ML observability and expanded into LLM guardrails and agent policy enforcement. Its strength is output reliability: detecting hallucinations, off-topic responses, and policy violations in model outputs. For teams that care primarily about what agents say to end users rather than what tool calls they make internally, Aporia’s observability heritage gives it depth competitors lack.
The coverage of internal tool calls and agent-to-agent communication is less mature than in purpose-built agent security platforms. Aporia is a better fit for a customer-facing AI product team than for a security operations team trying to govern internal agentic automation.
Platform Extensions: Runtime Capabilities Added to Cloud and AI Security Foundations
Prompt Security (SentinelOne)
Prompt Security was acquired by SentinelOne in 2024, and its prompt inspection and data loss prevention capabilities for LLM applications are now being integrated into the SentinelOne platform. For organizations already running SentinelOne EDR across endpoints, the integration reduces the number of vendor relationships and the number of agents deployed. The combined product covers employee use of AI tools (shadow AI discovery, DLP for LLM inputs) and deployed AI application security.
Post-acquisition integration timelines are what they are. Teams evaluating this should ask specifically which Prompt Security features are available in production inside the SentinelOne console today versus on the roadmap, and get that answer in writing. Pricing is not publicly disclosed as of July 2026.
Palo Alto Networks Prisma AIRS
Prisma AIRS is Palo Alto’s dedicated AI security product, distinct from their broader Prisma Cloud CNAPP. AIRS covers AI application discovery, prompt injection detection, and runtime security for AI workloads, with inline enforcement available through integration with XSIAM and the existing Palo Alto proxy infrastructure. For organizations already routing traffic through Palo Alto’s NGFW or Prisma Access, the integration path is shorter than deploying a net-new vendor.
The platform is strongest when it can use existing Palo Alto sensors. In environments that do not run Palo Alto network infrastructure, AIRS becomes a standalone deployment with less native enforcement depth. Pricing is not publicly disclosed as of July 2026.
Zscaler AI Security
Zscaler’s AI security capabilities are built on top of its existing Zero Trust Exchange proxy architecture. Any organization already routing all traffic through Zscaler gets AI application visibility and some inline inspection as a natural extension. The posture management and SaaS security posture capabilities are solid.
Zscaler is not a purpose-built agent security platform. Its enforcement applies at the network and application layer for traffic it already proxies. Agents that communicate internally within a cloud VPC, or that use direct API calls that bypass the Zscaler proxy, are outside its enforcement perimeter.
Identity and SaaS-Focused Platforms with Agent Governance Capabilities
Obsidian Security
Obsidian is fundamentally a SaaS security and identity threat detection platform that has extended coverage to non-human identities, including service accounts and OAuth tokens that agents use. For teams whose primary AI agent risk is identity-related, specifically over-permissioned service accounts and OAuth token sprawl across SaaS applications, Obsidian’s detection depth on that surface is strong.
Obsidian does not provide prompt-level enforcement or tool-call interception. It will detect anomalous identity behavior after the fact and can trigger remediation workflows, but it is not an inline enforcement platform. Pair it with a runtime enforcement tool for full coverage, or use it alone if identity governance is the gap you are prioritizing.
AI Security Posture and Supply Chain Platforms
Wiz AI Security Posture Management
Wiz ASPM scans cloud environments for AI workloads, identifies misconfigured model endpoints, over-permissioned AI service accounts, and exposed training data stores. For a cloud security team that wants AI workloads included in their existing CSPM workflow, Wiz’s agentless scanning approach adds AI context without deploying a new sensor. The integration with existing Wiz findings means AI risk surfaces in the same risk graph as cloud misconfigurations.
Wiz ASPM is posture management. It does not enforce at runtime, and Wiz has not published documentation as of July 2026 indicating a sensor or proxy for agent action interception. Teams that evaluate Wiz for agent security should scope the use case to inventory, misconfiguration detection, and data exposure scanning, not runtime control.
Protect AI
Protect AI focuses on the security of ML models themselves: scanning models for embedded malware, detecting vulnerabilities in ML frameworks and dependencies, and providing an SBOM equivalent for AI supply chains. This is a distinct problem from agent runtime security. If your threat model includes adversarially poisoned models or supply chain attacks on ML dependencies, Protect AI addresses a gap that none of the runtime enforcement platforms cover.
Protect AI is not an agent runtime enforcement platform. Teams that need runtime control should not substitute it here.
Lacework AI Security
Lacework, now part of Fortinet’s portfolio, provides anomaly detection on cloud workloads including AI services. Its behavioral detection engine can surface unusual API call patterns from AI workloads, which is relevant context for a SOC analyst investigating an agent that may have been compromised. The detection is post-fact and anomaly-based, not policy-enforced.
For teams already on Lacework CNAPP, the AI workload anomaly detection is a low-cost incremental capability. For teams evaluating a purpose-built agent security platform, Lacework’s AI coverage is not a substitute for runtime enforcement.
How Per-Agent Versus Per-Token Pricing Actually Behaves at Scale
None of the vendors on this list publish pricing. That is a structural fact about this market, not a gap in this article. Get all quotes directly from each vendor and model two scenarios before signing: your current deployment and a 10x scaled deployment.
Consider this illustrative scenario to frame the modeling conversation. A financial services firm runs 40 deployed agents today: 12 Copilot Studio automations, 18 custom Python agents on Kubernetes, and 10 ServiceNow AI assistants. At a hypothetical per-agent rate of $500 per agent per month (a figure used here only for illustration, not sourced from any vendor), monthly cost is $20,000. At 10x agent count, that is $200,000 per month, or $2.4 million annually, before including the human tuning cost of managing policies across 400 agents.
Per-token pricing behaves differently. A high-throughput agent that processes thousands of documents per day can consume tens of millions of tokens monthly. At any non-trivial per-token rate, that agent alone can exceed what per-agent pricing would cost for the entire fleet. Ask every vendor which model they use, whether there are rate tiers, and whether proxy inspection tokens count separately from model inference tokens.
Proxy latency is the third cost that never appears on a pricing page. An inline enforcement proxy that adds 150 milliseconds per agent invocation adds 15 seconds of latency to a 100-step agent workflow. For background automation, that is irrelevant. For a real-time customer service agent, it is a product problem. Get latency benchmarks under production-equivalent concurrency, not idle-state demos.
Which Platforms Fit Which Deployment Patterns
If your agents are primarily Microsoft 365 and Power Platform automations built by business users, Zenity is the purpose-built choice. No other platform on this list has equivalent depth on that specific surface.
If your agents run in Kubernetes and you have a security engineering team that can operate eBPF-based tooling, Operant AI provides the lowest-latency runtime enforcement available. The tradeoff is that you need engineering capacity to tune it.
If your primary risk is prompt injection and data leakage through model outputs in a customer-facing product, Lakera Guard or Lasso Security are purpose-built for that layer. Neither replaces an identity governance tool for the service accounts those agents run under.
If your organization is deeply invested in Palo Alto Networks infrastructure, Prisma AIRS is the path of least integration friction. If you are deeply invested in SentinelOne, the Prompt Security integration is worth evaluating for its coverage of shadow AI and employee LLM use alongside deployed application security. If neither applies, neither platform offers enough differentiation to justify displacing a purpose-built vendor.
For security engineering teams that want policy-as-code control without vendor lock-in, Invariant Labs’ open-source engine is a starting point, not a production platform. Budget engineering time proportional to the control you want to exercise.
Demo Questions That Reveal Enforcement Depth
Every vendor in this category will say “yes” to “do you provide runtime protection.” These questions are harder to answer with a slide.
- Show me a live demo where an agent makes a tool call that violates a policy and the platform blocks it before the downstream API receives the request. Not a replay. Live.
- What is the measured latency added by your proxy or sensor under 100 concurrent agent sessions? Can you provide a benchmark from a real customer environment?
- How does your platform model agent identity? Specifically, how do you inventory and govern OAuth tokens and service principals used by agents, and how do you detect when an agent’s effective permissions have drifted from its provisioned permissions?
- How does your platform handle an agent framework you do not natively support? What is the coverage gap, and how do you propose we detect it?
- What does your pricing model look like at 500 agents? At 5,000 tool calls per minute? Is that per-agent, per-token, or consumption-based, and what counts as a billable unit?
- How many hours per week does a typical customer spend tuning policies in the first 90 days? What is the default false-positive rate before tuning?
- Does your platform support the Model Context Protocol, and can you show me how you enforce policy on an MCP tool call specifically?
For teams evaluating MCP-specific controls in depth, the best MCP security tools for locking down agent-to-tool access covers the protocol-level enforcement options that sit beneath most of the platforms on this list.
Frequently Asked Questions
What does an AI agent security platform actually control?
At minimum, a platform should inventory deployed agents and their identities. Purpose-built platforms go further: they enforce policy on tool calls (what the agent can call and under what conditions), inspect prompts and responses for injection or data leakage, govern the OAuth tokens and service accounts agents run under, and produce audit logs of every agent action. Posture-only platforms do the inventory and misconfiguration parts but cannot block a malicious action in progress.
Which platforms enforce at runtime versus only report posture?
Zenity, Noma, Straiker, Lasso, Operant AI, Lakera, CalypsoAI, WitnessAI, Aporia, Invariant Labs, and Prompt Security (SentinelOne) all provide some form of runtime enforcement through a proxy or sensor. Wiz AI Security Posture Management, Lacework, and Protect AI are posture and scanning tools that do not sit in the enforcement path. Palo Alto AIRS and Zscaler provide partial inline enforcement contingent on routing traffic through their existing infrastructure.
How is per-agent pricing different from per-token pricing for AI agent security?
Per-agent pricing charges a flat rate per deployed agent regardless of how often it runs, which makes costs predictable. Per-token pricing charges based on the volume of text processed by the enforcement layer, which scales unpredictably with agent workload intensity. A high-throughput agent can consume 50 to 100 times more tokens than a low-frequency one, so per-token billing can produce wildly different monthly invoices from month to month. Model costs explicitly under your expected workload before committing.
What is the Model Context Protocol and why does it matter for agent security?
The Model Context Protocol (MCP) is an emerging standard for how AI agents connect to external tools, databases, and APIs. Agents that use MCP servers to call tools create a new attack surface: a compromised MCP server can instruct an agent to take actions the user never intended. Platforms that can inspect and enforce policy at the MCP layer, specifically at the tool-call message level, close a gap that conventional application firewalls and API gateways miss entirely.
How do I secure AI agents running in Kubernetes?
For Kubernetes-native agent workloads, eBPF-based runtime enforcement (as Operant AI provides) is the most architecturally appropriate approach because it observes agent behavior at the kernel level without requiring a proxy in the HTTP path. Complement it with RBAC policies that restrict what service accounts agent pods can call, network policies that limit egress to approved tool endpoints, and admission controllers that prevent agent containers from running with excessive capabilities. Operant and similar eBPF tools provide the behavioral detection layer on top of that baseline hardening.
Are repositioned AI-SPM tools sufficient for agent security?
AI Security Posture Management (AI-SPM) tools address misconfiguration, exposed model endpoints, and AI supply chain risk. They do not address the runtime control problem because they are not architecturally designed to sit in the execution path of a running agent. Whether an AI-SPM tool is sufficient depends on your threat model. If your risk is a misconfigured model endpoint or over-permissioned training data access, AI-SPM may be enough. If your risk is a prompt-injected agent taking unauthorized actions, it is not.
What is the tuning burden for AI agent security platforms?
Expect two to four weeks of active policy tuning before a runtime enforcement platform stabilizes to an acceptable false-positive rate in most environments. Platforms that use behavioral baselining (learning normal agent patterns before enforcing) typically reach stability faster than rule-only platforms. Ask vendors for the average tuning hours per week reported by production customers in environments comparable in size and agent complexity to yours. This number is almost never in marketing materials, but most vendors have it.
Three Shortlists Based on How Your Agents Are Deployed
For a Microsoft 365-centric organization with Copilot Studio agents built by business teams: start with Zenity for agent governance and add Obsidian for non-human identity coverage across the broader SaaS estate. Those two platforms cover the surface that matters most without requiring a network architecture change.
For a cloud-native engineering team running custom Python or LangChain agents on Kubernetes: evaluate Operant AI for eBPF-based runtime enforcement, Noma for ML pipeline and development-phase security, and Straiker for policy breadth across frameworks. The combination provides depth at every phase from model training through agent action.
For an organization with a mixed deployment (some SaaS agents, some Kubernetes workloads, some third-party AI tools used by employees): Straiker’s framework-agnostic proxy approach covers the widest surface, and WitnessAI adds audit-grade logging for regulated workloads. Complement with Obsidian for SaaS identity governance. Run the demo questions above with all three before narrowing.
The platforms that will reduce real agent risk in 2026 are the ones willing to answer question one in the demo list with a live demonstration, not a recorded video. If a vendor cannot show you a blocked agent action in real time, you are buying a reporting tool, not an enforcement platform.
