Zero Data Retention for AI Agents: The Enterprise Security Standard

Last update: September 2026

What is Zero Data Retention for AI Agents?

Zero Data Retention (ZDR) for AI agents is a technical and contractual guarantee that all prompts, context windows, and model outputs are processed in-memory only and never written to persistent storage: no logs, no databases, no training datasets.

The moment a session ends, the data is gone. It is neither a privacy policy nor a retention schedule with a 30-day delete, it is an architectural constraint: a ZDR-enforced AI agent is technically incapable of storing what it processes. That distinction (between a promise to delete and a system that cannot retain) is what separates genuine ZDR from marketing language.

This matters because AI agents are now handling data that carries legal consequences when it persists. A customer support agent that processes billing disputes touches payment card data, PCI DSS scope. A healthcare agent that pulls patient history into a RAG pipeline handles Protected Health Information, HIPAA applies, and a Business Associate Agreement is not sufficient if the underlying model is logging inputs.

A legal AI that drafts contract clauses from internal precedents is processing privileged communications, if those prompts are retained by an LLM provider and used for training, the privilege is arguably gone. GDPR Article 25 (Data Protection by Design) and SOC 2 Trust Criteria CC6.1 both require that data handling controls are built into the system. ZDR is what "built in" looks like at the model layer.

This article covers what ZDR enforcement actually requires (technically, contractually, and architecturally) and where most enterprise AI deployments fall short of it. You will leave with a clear picture of the three implementation pillars, what your MSA with an LLM provider needs to say, how metadata-only auditing satisfies compliance requirements without storing content, and how each of these applies to the regulated industries where ZDR is no longer optional.

TL;DR - Key Takeaways

• ZDR is an architecture, not a policy: prompts, context, and outputs are processed in-memory only and never written to logs, databases, or training sets. When the session ends, the data is gone.
• Policy promises are not enough: a provider's default terms do not guarantee ZDR. It must be explicitly contracted in your MSA or Data Processing Addendum, with audit rights included.
• Three technical pillars make it real: dynamic PII masking before transmission, a stateless AI gateway that never writes to disk, and metadata-only audit logging that captures events without storing content.
• Regulatory scope is clear: HIPAA requires ZDR for any agent handling PHI. GDPR Article 25 requires data protection by design. SOC 2 CC6.1 requires logical access controls that ZDR satisfies at the model layer.
• You can still audit without storing content: timestamps, token counts, policy outcomes, and anomaly flags satisfy compliance requirements without retaining a single prompt or response.
• "Data that does not exist cannot be breached."

---

Why ZDR is the New "Gold Standard" for Enterprise AI

The difference between a data retention policy and a data retention architecture is the difference between a promise and a guarantee. Traditional enterprise data controls assume data lands somewhere (a database, a log, a model training set) and focus on governing access to it. ZDR removes that assumption: the data never lands, so there is nothing to govern, nothing to breach, and nothing to produce in a regulatory investigation.

Why traditional controls fail for AI agents

Traditional data security tools were built around a different assumption: that sensitive data flows into defined systems, gets written somewhere, and can therefore be governed at the storage layer. DLP controls scan files and emails. Retention policies schedule deletion. Encryption protects data at rest. These controls all require the data to exist somewhere first. AI agents break that assumption.

When a legal agent retrieves ten years of contract precedents to draft a clause, or a customer support agent pulls a patient's full account history to resolve a billing dispute, that sensitive context passes through an LLM that (by default) may log it, cache it, or use it to improve future model versions. There is no file to scan. There is no database row to delete. The exposure happens in the inference layer, and most enterprise security stacks have no visibility there at all.

Why ZDR is the correct response

ZDR addresses the exposure at the point it occurs. Rather than attempting to recover or delete data after it has been processed, ZDR prevents persistence from happening in the first place. A stateless AI gateway intercepts every request, applies dynamic PII masking before transmission, and enforces provider-side ZDR API options, so the LLM never receives identifiable data, and the provider's infrastructure never retains the session.

The result is an agent that can reason over sensitive context within a session and leave no recoverable trace when the session closes. This is why ZDR is increasingly described as a gold standard: it is the only approach that eliminates the exposure rather than managing it.

ZDR vs data minimisation

It is worth distinguishing ZDR from data minimisation, since the terms are sometimes used interchangeably. Data minimisation (as defined under GDPR Article 5(1)(c)) requires that only the data necessary for a specified purpose is collected, and that it is not kept longer than necessary. This still permits temporary retention followed by scheduled deletion. ZDR is stricter: no retention occurs at any point, even momentarily in persistent form.

For regulated industries, this distinction is material. HIPAA's Minimum Necessary Standard (45 CFR §164.514(d)) and its Technical Safeguards (§164.312) both point toward ZDR as the appropriate architecture for AI systems handling PHI.

GDPR Article 25's requirement for Data Protection by Design explicitly favours architectures where privacy is enforced structurally, not procedurally. SOC 2 Trust Service Criteria CC6.1 (logical and physical access controls) is satisfied at the model layer when ZDR is implemented correctly. They are the audit standards your auditors will apply.

That is the architectural logic. What changes across regulated industries is which framework maps to which control, and how auditors expect you to evidence it. The next section covers what HIPAA, GDPR, and SOC 2 each specifically require from a ZDR implementation, and where each one diverges.

ZDR and Regulatory Compliance: What Each Framework Actually Requires

The three frameworks that drive most enterprise ZDR adoption (HIPAA, GDPR, and SOC 2) each approach data protection from a different angle. What they share is a structural preference for controls that are built into a system rather than applied after the fact. ZDR satisfies all three, but the way it satisfies each is specific enough to matter in a vendor assessment or an audit.

HIPAA: Technical Safeguards and the Business Associate Agreement

HIPAA's Security Rule requires covered entities and their business associates to implement Technical Safeguards under 45 CFR §164.312. For AI agents handling Protected Health Information, two provisions are directly relevant. Section §164.312(a)(2)(iv) requires encryption and decryption controls for ePHI. Section §164.312(b) requires audit controls: hardware, software, and procedural mechanisms that record and examine activity in systems that contain or use ePHI.

ZDR satisfies both in a specific way: because no PHI is written to disk, the encryption-at-rest requirement becomes moot, there is no stored data to encrypt. And because metadata-only audit logging captures session events without storing PHI content, the audit control requirement is satisfied without creating a new data residency liability.

The Business Associate Agreement (BAA) question is frequently misunderstood. Signing a BAA with an LLM provider is necessary but not sufficient. A BAA creates a legal obligation not to retain PHI; it does not create a technical barrier to retention. If the provider's infrastructure logs your inputs by default and you have not explicitly enabled ZDR API options, the BAA is covering a risk that the architecture has not actually eliminated. The correct sequence is: confirm ZDR is technically enabled at the API level first, then ensure the BAA reflects that configuration.

The Minimum Necessary Standard (§164.514(d)) adds a further requirement: only the PHI necessary to fulfil a specific function should be accessed or transmitted. For AI agents using RAG pipelines to retrieve patient records, this means the retrieval layer (not just the LLM) must implement access controls that limit what context enters the prompt. ZDR at the inference layer combined with access-scoped retrieval is the complete HIPAA technical architecture.

GDPR: Article 25 and the Data Protection by Design Obligation

GDPR Article 25 requires that data protection principles are implemented by design and by default, not as an add-on after a system is built. Article 5(1)(c) requires data minimisation: personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." Article 28 requires that any third-party processor (including an LLM provider) processes personal data only on documented instructions and provides sufficient guarantees that appropriate technical measures are in place.

ZDR maps directly onto all three. Article 25 is satisfied when ZDR is implemented architecturally, a system that cannot retain data is a system where data protection is built in, not bolted on. Article 5(1)(c) is satisfied because data that is never stored cannot be retained beyond its necessary processing window. Article 28 is satisfied when your DPA with the LLM provider explicitly documents ZDR as a technical measure and your audit rights allow you to verify it.

One area where GDPR and ZDR intersect in a non-obvious way is Data Protection Impact Assessments (DPIAs) under Article 35. DPIAs are required for processing likely to result in a high risk to individuals, which includes large-scale processing of sensitive categories of data by automated systems.

An AI agent with a correctly implemented ZDR architecture materially reduces the residual risk documented in a DPIA, because the data processed never enters a persistent state where it could be subject to a breach, a subject access request, or an erasure obligation. In practice, this means your DPIA can document ZDR as the primary technical control for the high-risk processing activity, simplifying the remediation requirements.

SOC 2: Trust Service Criteria and ZDR as a Logical Access Control

SOC 2 Type II audits evaluate controls against the Trust Service Criteria. For AI agent deployments, three criteria are directly relevant. CC6.1 requires logical and physical access controls, restrictions on who and what can access sensitive data. CC6.6 requires that logical access security measures address threats from sources outside the system boundary. CC6.7 requires that the transmission and movement of information meets the organisation's objectives.

ZDR contributes to all three, but its most direct SOC 2 value is against CC6.1. When sensitive data is processed only in-memory and never written to persistent storage, the attack surface available to an unauthorised actor is the inference window only: not a database, not a log file, not a backup. This reduces the scope of CC6.1 controls required because there are fewer storage locations to govern.

For SOC 2 Type II specifically, which evaluates whether controls operated effectively over a defined period, metadata-only audit logging is what makes ZDR auditable. Your logs capture timestamps, token counts, session identifiers, policy enforcement outcomes, and anomaly flags.

These give an auditor the evidence that controls operated consistently without requiring any prompt or response content to be stored. The audit trail exists; the sensitive data does not. That is the architecture SOC 2 Type II requires for high-risk AI processing, and it is what ZDR delivers.

For teams mapping ZDR controls to the NIST AI Risk Management Framework, CC6.1 aligns with GOVERN 1.2 (accountability) and MANAGE 2.2 (incident response), making ZDR a direct contribution to NIST AI RMF compliance posture.

The Technical Pillars of ZDR Enforcement

ZDR enforcement requires two distinct layers of control, one at the provider and one within your own perimeter, working together.

1. Provider-Side Controls: Configuring the Engine

Most enterprise-grade AI providers, such as OpenAI, Microsoft Azure, and Anthropic, offer ZDR-eligible endpoints. However, these are rarely the default setting. Standard API accounts often include a 30-day retention period for abuse monitoring and safety reviews. To enforce ZDR, security leaders must ensure their API configurations are explicitly set to zero-day retention.

This involves moving to enterprise-tier agreements where the provider contractually and technically disables all persistent logging of prompt and completion data. It is crucial to distinguish between "not training on your data", a common baseline for enterprise AI, and "not retaining your data," which is the more stringent ZDR requirement.

2. Consumer-Side Architecture: The Trust Layer

While provider-side controls are essential, a truly resilient ZDR strategy includes a "Trust Layer" within the enterprise perimeter. This intermediary proxy acts as a stateless gateway, intercepting all traffic between the agent and the LLM.

Key components of this layer include:

• Dynamic Masking and Anonymization: Before any data leaves the corporate network, Named Entity Recognition (NER) models scan for Personally Identifiable Information (PII) or sensitive intellectual property. This data is swapped with non-sensitive tokens (for example, replacing a customer's name with [USER_1]). The mapping is stored locally and temporarily, allowing the agent to "demask" the response for the end-user without the LLM ever seeing the original sensitive values. Dynamic masking also limits the effectiveness of prompt injection attacks, since an adversarial payload targeting PII that has already been masked has nothing to extract
• Stateless Gateways: By routing all AI traffic through a centralised, stateless proxy, organisations can enforce uniform security policies, perform real-time toxicity filtering, and maintain audit logs that capture metadata (who, when, and cost) without ever persisting the actual content of the interaction.
• Grounding without Persisting: In agentic systems using Retrieval-Augmented Generation (RAG), the challenge is providing the agent with enough context without creating a permanent data trail. ZDR-enforced RAG ensures that the retrieved context is injected into the prompt's volatile memory and flushed immediately upon task completion, rather than being stored in the LLM's own context cache or history.

TrustGate is NeuralTrust's stateless AI gateway, the enforcement layer between your applications and LLM providers. Every request passes through TrustGate's policy engine, which applies dynamic PII masking before transmission, enforces provider-side ZDR API options, and generates metadata-only audit logs (timestamps, token counts, policy outcomes) without ever writing prompt or response content to disk. For organisations subject to HIPAA, GDPR, or PCI DSS, TrustGate provides the verifiable architectural ZDR guarantee that policy documents alone cannot.

---

How to Implement ZDR: A Practical Guide for Security Teams

Understanding what ZDR requires contractually and regulatorily is the first step. Implementing it in a way that is technically verifiable (not just documented) is where most enterprise deployments fall short. This section covers provider-side verification, MSA requirements, and how to confirm that ZDR is actually working before you deploy.

1. Verifying ZDR at the Provider API Level

Each major LLM provider implements ZDR differently, and the default configuration for all of them is not ZDR. You need to explicitly enable it.

OpenAI offers ZDR for API customers through their Enterprise agreement and Data Processing Addendum. When ZDR is enabled, API inputs and outputs are not stored and are not used for model training. This is separate from the default API behaviour, which retains inputs for up to 30 days for abuse monitoring. Confirmation that ZDR is active should come from your OpenAI account team in writing, referencing your DPA configuration, not from a privacy policy URL.

Anthropic offers a similar ZDR option for enterprise API customers. By default, Anthropic may use API data to improve its models unless you have an enterprise agreement that explicitly prohibits this. The relevant clause in your agreement should state that Anthropic will not train on your inputs, will not retain them beyond the processing window, and will provide deletion certification if requested.

Azure OpenAI Service provides ZDR through its data processing terms within the Microsoft Azure enterprise agreement. Azure OpenAI does not use customer data to train foundation models by default for enterprise customers, but logging behaviour depends on your configuration. The Azure OpenAI content filtering and logging settings must be reviewed explicitly, the default abuse monitoring configuration does retain inputs.

The common thread across all three: ZDR requires explicit contractual configuration, is not the default, and must be verified in writing rather than inferred from a provider's general privacy documentation.

2. MSA Review Checklist: What Your Contract Must Say

The legal architecture for ZDR is as important as the technical one. Your Master Service Agreement or Data Processing Addendum with any LLM provider or AI infrastructure vendor should explicitly address all of the following:

1. No training on customer data: the contract must state that the provider will not use your inputs, outputs, or any derivative thereof to train, fine-tune, or evaluate models without explicit written consent. Opt-out clauses that require you to take action are insufficient; the default must be no training.
2. Defined data residency window: the contract should specify the maximum time any customer data may exist in the provider's infrastructure, including in-memory processing windows, temporary caches, and abuse monitoring buffers. Zero is the target; if a provider requires a minimum retention window for operational reasons, this must be documented and time-bounded.
3. Right to audit: you must have contractual rights to request evidence of ZDR compliance, including the ability to commission a third-party technical audit of the provider's data handling infrastructure. A provider that cannot offer this right is offering a promise, not a guarantee.
4. Incident notification: if data persistence occurs due to a system failure, bug, or configuration error, the contract must require prompt notification — typically 72 hours, aligned with GDPR breach notification obligations — along with a root cause analysis and remediation plan.
5. Deletion certification: upon contract termination, the provider must deliver a written certification that all customer data has been deleted from their infrastructure, including backups and disaster recovery systems.

3. Confirming ZDR Is Working: Metadata-Only Audit Logging

Once ZDR is configured, you need a way to verify it is operating correctly without storing the content you are trying to protect. Metadata-only audit logging is how you do this.

A correctly implemented ZDR audit log captures: session identifier, timestamp, requesting service or agent identity, token count (input and output), latency, policy enforcement outcomes (what PII masking was applied, what provider-side ZDR option was invoked), and any anomaly flags raised by the gateway. It does not capture: prompt text, response text, retrieved RAG context, or any content field that could re-identify the data subject.

This log is sufficient to demonstrate to a SOC 2 auditor that controls operated consistently. It is sufficient to respond to a GDPR supervisory authority inquiry about how personal data was processed. It is sufficient to satisfy HIPAA audit control requirements under §164.312(b). And it gives your security team the operational visibility to detect if ZDR controls are failing — a session with unusually high token counts against a provider endpoint that should be ZDR-configured is a signal worth investigating, even if you cannot see the content.

The metadata log is the compliance record. The absence of content in that log is the proof of ZDR.

4. Human-in-the-Loop: Real-Time Oversight Without Content Storage

The most sensitive agent actions (executing a financial transaction, modifying a patient record, sending a communication on behalf of a user) should not execute without human review. The challenge in a ZDR architecture is that traditional human-in-the-loop workflows often assume the output can be queued, stored, and reviewed asynchronously. That assumption breaks ZDR.

The solution is synchronous review: the agent pauses before a high-risk action, surfaces its proposed output or intent to a human reviewer in the same active session, receives approval or rejection, then either executes or discards, and clears context regardless of outcome. The review happens inside the ephemeral session window, not against a stored copy of the content.

What gets logged is not the content of the proposed action but the oversight event itself: reviewer identity, timestamp, session ID, action category, and decision outcome (approved / rejected / escalated). This satisfies SOC 2 CC6.1's requirement for human accountability over privileged actions, and it satisfies HIPAA's requirement for documented access controls over PHI processing — without creating a persistent record of the sensitive content that was reviewed.

In practice, this means your agent orchestration layer needs to support pause-and-resume across a human decision point, with the session context held in volatile memory during the review window and flushed on completion. Asynchronous review queues that write content to a database while waiting for a reviewer are not ZDR-compliant, regardless of how short the retention window is.

The governing principle is the same as the rest of the ZDR architecture: oversight is a metadata event, not a content event. The human saw it; the system does not need to store it.

Practical Best Practices for Security Leaders

The MSA checklist in the implementation section above covers the five clauses that must appear in every provider agreement. The strategic point for security leaders is this: negotiating these clauses upfront is orders of magnitude cheaper than retrofitting them after a compliance incident. Default terms are written for the provider's convenience, not yours.

TrustLens provides session-aware posture monitoring that produces ZDR-compliant audit trails across your entire AI agent estate. Rather than logging prompt content, TrustLens captures behavioural metadata (session patterns, anomaly scores, policy violation events, and agent-to-agent interaction chains) giving security teams the visibility they need for SOC 2 and GDPR audit requirements without compromising the data ephemerality guarantee. When an agent behaves unexpectedly, TrustLens surfaces the signal without retaining the sensitive content that triggered it.

Zero Data Retention in Action

Healthcare: Protecting Patient Privacy (PHI)

Imagine a healthcare AI agent designed to assist clinicians by summarizing patient records or drafting discharge instructions. These records contain highly sensitive Protected Health Information (PHI), which is subject to stringent HIPAA regulations. By enforcing ZDR, the healthcare provider ensures that as the agent processes the patient’s history, no trace of that data remains on the LLM provider’s servers once the summary is generated. The agent operates in a "stateless" mode, pulling data from the secure Electronic Health Record (EHR) system, processing it in-memory, and then immediately flushing the context. This allows clinicians to leverage the power of AI to improve patient outcomes without the risk of creating a permanent, vulnerable cache of sensitive health data outside their own secure perimeter.

Legal and Finance: Safeguarding Trade Secrets and Privilege

In the legal and financial sectors, the protection of attorney-client privilege and proprietary trade secrets is paramount. A legal AI agent tasked with analyzing complex contracts or a financial agent drafting investment strategies must handle information that could be devastating if leaked. ZDR enforcement ensures that the "secret sauce" of a company’s strategy or the confidential details of a legal case never become part of a third-party provider’s persistent logs. By using dynamic masking to scrub names and specific financial figures before they reach the LLM, and enforcing ZDR at the API level, these organisations can safely automate high-value tasks while maintaining the highest levels of confidentiality and professional privilege.

Customer Support: Resolving Billing Issues Without PCI Leakage

Customer support agents are increasingly being tasked with resolving complex billing and account issues that involve sensitive Payment Card Industry (PCI) data. A ZDR-enforced support agent can help a customer update their billing information or resolve a payment discrepancy by interacting with the company’s secure payment gateway. Through the use of a "Trust Layer," any credit card numbers or personal identifiers are masked before the request is sent to the LLM for processing. The LLM helps the agent understand the customer’s intent and draft a response, but it never "sees" or "stores" the actual PCI data. Once the interaction is closed, the volatile memory is cleared, ensuring that no sensitive financial information is left behind in a support log or a provider’s database.

Closing Thought

Data that does not exist cannot be breached. That is the whole argument.

ZDR is not a compliance checkbox, it is an architectural decision made at the start of a project, before the first LLM call, before the first vendor contract is signed. Retrofitting it is expensive; leaving it out is a liability that compounds with every session your agents process.

The practical steps are clear: verify ZDR is contracted in your MSA or DPA, enforce it at the gateway layer, confirm it with your provider in writing, and log metadata only. TrustGate handles the enforcement layer; TrustLens gives you the audit trail without storing a single prompt.

Start there.

---

FAQs about Zero Data Retention for AI Agents

1. What is zero data retention for AI agents?

Zero data retention (ZDR) for AI agents means that prompts, context, and model outputs are processed exclusively in-memory during a session and never written to persistent storage — no logs, no databases, no training datasets. Once the interaction ends, the data is gone. ZDR is the highest-trust data handling standard for enterprise AI deployments handling sensitive or regulated information.

2. Why do enterprises need zero data retention for AI agents?

Enterprise AI agents frequently handle regulated data — PHI under HIPAA, PII under GDPR, financial data under PCI DSS, and privileged legal communications. Without ZDR, every interaction creates a data residency and breach liability risk. ZDR eliminates that risk at the architectural level by ensuring that sensitive data never persists beyond the session.

3. What is the difference between zero data retention and data minimisation?

Data minimisation is a policy principle: collect only what you need and delete it after a defined retention period. Zero data retention is a stricter technical guarantee: no persistence occurs at all, even momentarily. ZDR enforces ephemerality at the architectural level — stateless gateways, in-memory-only processing, and contractual provider-side controls — whereas data minimisation still allows temporary storage followed by scheduled deletion.

4. Does OpenAI support zero data retention?

Yes. OpenAI offers a Zero Data Retention option for API customers via their Data Processing Addendum (DPA). When enabled, OpenAI does not store API inputs or outputs and does not use them for model training. This must be explicitly requested and agreed to contractually — it is not the default API configuration.

5. How does a stateless AI gateway enforce zero data retention?

A stateless AI gateway sits between your application and the LLM provider, routing all requests through a centralised policy layer without writing inputs or outputs to disk. It applies dynamic PII masking before transmission, enforces provider-side ZDR API options, and generates only metadata-level audit logs (timestamps, token counts, policy outcomes) — never the content itself. This architecture provides both ZDR enforcement and a compliance audit trail.

6. What is dynamic PII masking in the context of zero data retention?

Dynamic PII masking uses Named Entity Recognition (NER) to identify and redact or replace personally identifiable information — names, account numbers, addresses, health identifiers — before the prompt is transmitted to the LLM provider. This provides an additional ZDR layer: even if a provider's ZDR controls fail, the transmitted data contains no re-identifiable PII.

7. Can zero data retention AI agents still produce audit logs for compliance?

Yes — through metadata-only auditing. Compliant ZDR architectures log timestamps, session identifiers, token counts, latency, policy enforcement outcomes, and anomaly flags without storing prompt or response content. This satisfies SOC 2, HIPAA, and GDPR audit requirements while maintaining genuine data ephemerality.

8. How should a master service agreement (MSA) address zero data retention?

Your MSA with an AI provider should explicitly state: (1) no training on customer data without opt-in consent; (2) a defined maximum data residency window — ideally zero; (3) the right to audit ZDR compliance; (4) incident notification obligations if data persistence occurs; and (5) data deletion certification upon contract termination. Never rely on default terms — ZDR must be explicitly contracted.

9. What industries require zero data retention for AI agent deployments?

Healthcare (HIPAA — PHI cannot be retained by third-party AI providers without a signed BAA and explicit ZDR controls), financial services (PCI DSS — cardholder data must not be stored beyond transaction completion), legal (attorney-client privilege — AI-processed legal documents must not persist in provider systems), and any sector subject to GDPR or CCPA data minimisation obligations.

10. What is the Dual LLM Pattern and how does it relate to zero data retention?

The Dual LLM Pattern isolates untrusted external data (retrieved documents, user inputs, RAG context) in a sandboxed unprivileged model that has no persistent memory and cannot take privileged actions. This architectural boundary enforces zero data retention at the instruction-execution level: sensitive data processed by the privileged model never flows through a component that could retain or leak it. The pattern also reduces exposure to semantic chaining attacks, where a compromised agent in a multi-agent pipeline attempts to extract privileged context from downstream models.

---

About the Author

Alessandro Pignati is Lead AI Security Researcher at NeuralTrust, where he leads research on AI and agentic security, advancing techniques to evaluate and secure large language models and autonomous AI systems. He specializes in adversarial machine learning, AI red teaming, LLM security, and AI safety, contributing to the development of secure and trustworthy AI.

NeuralTrust is an AI agent security platform, recognized in the Gartner 2025 Market Guide for AI Gateways and Guardian Agents, and the KuppingerCole 2025 Leadership Compass for Generative AI Defense. Headquartered in Barcelona with ISO 27001 certification.