Galileo Protect vs Trussed AI: Evaluation Guardrails or Enforced Policy?

The architectural difference

The two approaches differ in where the decision is made and what kind of decision it is.

Evaluation-based protection comes from the evaluation and observability tradition. Inputs and outputs are assessed with metrics, classifiers or rulesets, and an intervention is triggered when a score crosses a threshold. Galileo Protect belongs to this lineage, which is why it is useful to treat it as an example of evaluation-driven guardrails rather than as a policy engine.

Policy enforcement in the execution path works differently. A policy is evaluated at a defined point on the request path, and the outcome is an explicit decision: allow, redact, block, rate limit or escalate for human approval. For the same input and the same policy version, the decision is the same. The system is not estimating whether something looks risky. It is applying a rule about what is permitted.

The practical test is simple. Is the decision made before the model call, tool call or agent action executes, or is the interaction scored and then handled? That single question determines most of the downstream differences in determinism, failure behavior and evidence.

Where evaluation-based approaches are strong

Evaluation-based approaches deserve a fair reading. Scoring is well suited to questions that are inherently graded, such as whether a response is off-topic, unsafe in tone or likely to be wrong. Teams that already measure model quality in development can reuse the same metrics in production, which gives continuity between testing and runtime.

The limitation is structural. Classifiers and metric thresholds are probabilistic, so they produce false positives and false negatives that must be tuned. That is acceptable for content quality and many content risks. It is a weaker foundation when the requirement is categorical, for example that a given agent may never call a given tool, or that a particular data class must be redacted every time. Categorical requirements call for rules that are applied, not scores that are interpreted.

Many teams will want both: evaluation to understand model behavior, and enforcement to bound what the system is allowed to do.

Evaluation criteria for runtime AI protection

These criteria describe the two architectures in general terms. Apply them to any product by asking each vendor to demonstrate the behavior, not describe it.

• Enforcement point: Evaluation-based: assessment of inputs and outputs, with action following the score. Execution-path enforcement: the decision is made before the interaction or tool call completes.
• Action types: Evaluation-based: typically a response to a threshold, such as flagging or blocking. Execution-path enforcement: allow, redact, block, rate limit and human-approval escalation as distinct policy outcomes.
• Scope of coverage: Evaluation-based: strongest on prompts and responses. Execution-path enforcement: extends to agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls.
• Policy authoring and consistency: Evaluation-based: thresholds and metrics that need tuning. Execution-path enforcement: explicit policy applied uniformly, with one policy plane across models.
• Evidence output: Evaluation-based: scores and assessments of what was observed. Execution-path enforcement: a record of the decision taken and the outcome, generated by enforcement itself.
• Deployment model and failure behavior: Ask where policy evaluation runs, who controls retention and data residency, and whether the control fails open or closed when it is unavailable. The answer should be configurable and demonstrable.

Tool calls, agent actions and audit evidence

Prompt and response filtering is one coverage question. Tool calls and agent actions are another. An agent that can call tools or reach MCP servers can cause effects that never appear in a model response. OWASP treats anomalous tool use as a runtime topic and places runtime guardrails in both the deploy and operate stages of its agentic lifecycle. A proof of concept limited to chat prompts will miss this entirely.

Evidence is where the architectural difference becomes visible to auditors. Under the EU AI Act, which sets risk-based rules for AI developers and deployers, the requirements for high-risk systems include risk management, record-keeping, human oversight, and robustness, accuracy and cybersecurity. Whether a given use is high-risk is a classification question for each organization. The Act also states that high-risk systems are tested against prior defined metrics and probabilistic thresholds. That is a testing provision, not a statement about runtime control, so in practice testing evidence and runtime control evidence answer different questions.

A record of scores shows what was assessed. An auditor reviewing runtime control usually needs more: what the AI was permitted to do, which policy applied, what decision was taken, and what then happened. Evidence generated as a by-product of enforcement can carry that decision directly. Evidence reconstructed from scores and traces has to infer it.

Where Trussed fits and how to choose

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions are allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Enforcement generates continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed is a runtime control product. It is not an observability tool or a pre-deployment testing product, so it complements evaluation rather than replacing it.

In production, Trussed has run continuously for 18+ months in a regulated enterprise, with 99.95% uptime on live production traffic and 100+ models under one policy plane.

To choose, start from the requirement. If you need graded assessment of model behavior, an evaluation-based approach is a reasonable core. If a regulated enterprise must show what its AI was allowed to do and what it did, prioritize an enforcement point in the path, explicit action types, coverage of tool calls and evidence that records decisions. Many programs will run both, with enforcement setting the boundary and evaluation measuring behavior inside it.