Lasso Security vs Trussed AI: evaluating runtime control and audit-ready evidence for regulated LLM deployments

An evaluation framework for regulated LLM deployments

Vendor positioning in this market often blurs three different jobs: detecting risk, monitoring usage and enforcing policy at runtime. A fair comparison starts by separating them. Testing and posture tools find weaknesses before or during deployment. Monitoring tools show what people and applications are doing with models. Runtime enforcement acts on a live interaction and can change or stop it.

For a regulated enterprise, the deciding questions follow from what an auditor will ask afterward: what was the AI allowed to do, and what did it do? That leads to six criteria. Where does the product sit in the architecture? Which actions can it take on an individual interaction or tool call? Which surfaces does it cover? What evidence does it generate, and how durable is that evidence? How can it be deployed, and where does data reside? Which frameworks does the evidence map to?

The EU AI Act gives a useful reference point for the evidence criteria. As of October 2026, the consolidated text dated 27 July 2026 requires a risk management system for high-risk AI systems to be established, implemented, documented and maintained. It also requires appropriate accuracy, robustness and cybersecurity, performing consistently throughout the lifecycle. The related recital lists technical documentation, record-keeping and human oversight among the requirements. Whether a given deployment is high-risk is a classification question for your legal team, but the underlying expectations are a sound basis for evaluating any runtime control.

Where each product sits in the architecture

Lasso Security's public descriptions cover several areas. Lasso Red Teaming is described as automated testing for prompt injection, jailbreak attempts and data poisoning, with threat modeling. Model cards categorize vulnerabilities and provide remediation guidance, and the product is described as helping validate GenAI security posture from development through production. Lasso for Applications is described as providing continuous protection and comprehensive control for GenAI applications, agents and models through monitoring and adaptive security measures. Lasso for employees is a browser extension that gives visibility into employee GenAI chatbot usage and is meant to monitor and protect it.

These are strengths for teams that need pre-deployment testing, posture validation and visibility into workforce GenAI usage. The wording on application protection does not itself settle whether actions occur inline or after detection, so that is a point to confirm directly with the vendor.

Trussed AI sits in the execution path. Policy is enforced at runtime, not reviewed after the fact, across models, agents, tools, MCP servers, AI sites and coding assistants. The scope is the individual interaction and the individual tool call, and the available actions are allow, redact, block, rate limit and escalate for human approval. Trussed is a runtime control product. It is not a pre-deployment testing or red-teaming product, so organizations that need that capability would pair it with a separate testing tool.

The architectural distinction matters because an inline control can prevent a disallowed action, while a monitoring layer can only report it. Neither is inherently better. They answer different requirements, and many regulated programs need both testing and enforcement.

Side-by-side on the six criteria

The table reflects Lasso's publicly described capabilities and Trussed's shipped capabilities. Items marked for confirmation are questions to put to the vendor rather than judgments.

• Enforcement point: Lasso: described as continuous protection and control through monitoring and adaptive security measures; confirm whether actions are inline. Trussed: in the execution path.
• Control actions: Lasso: confirm the action set per interaction. Trussed: allow, redact, block, rate limit, escalate for human approval.
• Coverage: Lasso: applications, agents, models and employee chatbot usage via browser extension; confirm tool calls, MCP servers and coding assistants. Trussed: models, agents, tools, MCP servers, AI sites and coding assistants.
• Pre-deployment testing: Lasso: red teaming and model cards. Trussed: not a testing or red-teaming product.
• Evidence: Lasso: confirm per-interaction records, export and retention. Trussed: continuous audit-ready evidence generated by enforcement, plus code provenance (origin, licence and security context).
• Deployment and framework mapping: Lasso: confirm hosting model, residency and framework mapping. Trussed: self-managed in the customer cloud with configurable retention and data residency; evidence mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST.

Evidence quality and durability

Evidence is where the detect, monitor and enforce distinction becomes concrete. A record that says a risky prompt was observed is different from a record that says a named policy version evaluated a specific interaction and the system redacted, blocked or escalated it. The second type answers the regulator's question directly, because it ties each action to a decision.

Trussed generates audit-ready evidence as a product of enforcement, so the record exists because the control acted. That evidence is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. In production, Trussed has run continuously in a regulated enterprise for more than 18 months at 99.95% uptime on live traffic, with 100+ models under one policy plane and over 30 GB of audit evidence generated per day. Trussed also holds SOC 2 Type II, HIPAA, GDPR, FERPA, ISO 27001 and NIST AI RMF alignment.

Whichever vendor you assess, evaluate the evidence itself. Look for the policy version, decision, action, identity and timestamp on each interaction or tool call. Check whether records can be exported, whether they can be shown to be unaltered, and whether retention can be set to the period your regulator requires. Ask each vendor to document its framework mapping and to say which obligations the product evidences and which remain your responsibility.

Agent authorization is an emerging criterion. NIST has discussed short-lived, dynamic and revocable authorization as a design tenet for agent identity. For tool-call and MCP-level controls, ask how each product handles that kind of scoped, revocable permission.

Deployment, data residency and which requirements point where

Deployment model determines where prompts, responses and evidence reside. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, so evidence can stay inside your own environment and follow your own retention schedule. Ask Lasso to describe its hosting options, where data is stored and what retention and residency controls exist.

Requirements tend to point in these directions. If your near-term need is to test LLM applications for prompt injection and jailbreaks, validate posture before release, or see how employees use GenAI chatbots, Lasso's documented capabilities address those needs. If your need is to stop, redact or escalate a specific interaction or tool call as it happens, across agents, MCP servers and coding assistants, and to retain evidence of each decision in your own cloud, that points toward enforcement in the execution path, which is what Trussed provides.

The two approaches are not mutually exclusive. Testing informs which policies to write, and runtime enforcement applies them. The practical risk is buying a monitoring or testing capability and expecting it to produce enforcement evidence, or the reverse.