Pangea AI Guard vs Trussed AI: API Guardrails or Runtime Enforcement?
Pangea publicly describes API and SDK based services that evaluate prompts, responses and data, and that applications call at defined integration points. Trussed enforces policy in the AI execution path across models, agents, tools, MCP servers, AI sites and coding assistants, and produces audit-ready evidence from that enforcement. They are different architectural models. The right choice depends on where you need policy applied, which interactions must be covered, and what evidence you must show a regulator.
Evaluation questions to run against both approaches
- Where is policy evaluated: in the application's call path, at a proxy, or elsewhere? Which AI interactions can bypass it?
- Does it cover model calls, agent tool calls, MCP servers, AI sites and coding assistants, or only prompts and responses?
- Which actions does it take on a violation (allow, redact, block, rate limit, escalate), and are they enforced or advisory?
- Does human approval pause the action until a person decides, and is the approver recorded?
- Can it be self-managed in your cloud, and where are data and evidence stored, for how long, and under what residency controls?
- What does each decision record (inputs, policy version, decision, approver), and can it be exported and mapped to your obligations?
Two architectural models, not two feature lists
The core difference is where policy is applied. An API-based AI security service is invoked by an application at integration points the application was built to use. The application sends a prompt, a response or a piece of ingested data to the service and then acts on what comes back. In-path runtime enforcement sits in the route AI traffic takes, so the control itself applies policy to what passes through it.
Pangea describes its AI Security Platform as helping security teams protect workforce AI use, enable secure AI innovation and ship secure AI applications quickly. Its publicly listed services follow the API model. Authorization is described as an access control engine that integrates with AI applications through APIs and SDKs. Data Guard is described as evaluating prompt inputs, responses and data ingestion from external sources for malicious content.
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Its scope is individual interactions and tool calls. When a policy applies, the action is allow, redact, block, rate limit, or escalate for human approval.
API-based service vs in-path enforcement
The table compares the two models on the dimensions that most affect a regulated enterprise. It describes the models in general terms. Test any specific product against each row.
- Where policy applies: API service: at the integration points where the application calls it. In-path: on the traffic routed through the control.
- Coverage: API service: the calls developers add to each application. In-path: models, agents, tools, MCP servers, AI sites and coding assistants that sit behind the control.
- Response to a violation: API service: a result returned to the caller, so enforcement depends on how the application handles it. In-path: the control applies the action itself, whether allow, redact, block, rate limit or escalate.
- Deployment: API service: follows the provider's deployment options, which should be confirmed. In-path (Trussed): self-managed in the customer cloud, with configurable retention and data residency.
- Evidence: API service: a record of the calls made to it, which matches the calls sent. In-path (Trussed): continuous audit-ready evidence generated by enforcement, mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST.
- Implementation effort: API service: integration work in each application. In-path: routing AI traffic through the control and defining policy once for the traffic it covers.
Coverage, bypass and failure behavior
Coverage is a function of placement. A service that applications call covers the calls they are written to send. A new agent, a prototype, an AI site used by staff or a coding assistant may never call it. The review question is therefore not what the service detects, but which interactions it can see and which can skip it entirely.
Agent tool calls and MCP server interactions raise the stakes. A prompt filter can inspect text, but a tool call is an action with side effects. Applying policy at the point the action executes lets a control decide whether the call is permitted before it happens. An API model can support this only if every agent framework is written to ask first and to honor the answer.
Placement also changes the operational tradeoffs. Both models add a dependency to the request. An API call adds a network hop per check. An in-path control adds a component to the traffic route, so its availability matters directly. For either model, define what happens on timeout or service unavailability, whether requests fail open or fail closed, and whether a developer can remove the integration point. Ask for production uptime figures, not design intent. Trussed reports 99.95% uptime on live production traffic.
Evidence is an output of enforcement
Detection results and audit evidence are not the same thing. A detection record shows that content was evaluated. Evidence shows what policy was in force, what the AI attempted, what the control decided and what happened next. When the control that decides is also the control that records, the evidence is a direct product of the decision. When the application decides what to do with a verdict, the record of what actually happened sits elsewhere.
The EU AI Act points in this direction without prescribing a log format. For high-risk AI systems it calls for design that lets natural persons effectively oversee the system in use, and for testing against prior defined metrics and probabilistic thresholds. It also provides for market surveillance authorities to have access to documentation and to training, validation and testing data sets, which may be through APIs or other remote access. That text speaks to documentation and data sets, not to runtime logs, so do not assume it requires a particular log. It does mean you should be able to show how oversight works and how policy was tested.
That is why human approval should be tested as an enforceable control, not an alert. If escalation pauses the action until a person approves it, the approval is part of the evidence. Trussed generates continuous audit-ready evidence from enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. As of October 2026, the EU AI Act also leaves data protection obligations for providers and deployers unchanged where AI use involves personal data, so retention and residency of the evidence itself need the same scrutiny.
When each model fits
An API-based service fits when the AI estate is a small number of applications you build and control, the main need is inspecting prompts, responses and ingested data, and your teams can maintain the integration in each application. It is a reasonable way to add detection to an application already under development. The cost is per-application effort and coverage that depends on each integration being present and correct.
In-path enforcement fits when the estate is broad or changing, when agents call tools and MCP servers, when staff use AI sites and coding assistants, or when you must show a regulator or auditor what your AI was allowed to do and what it did. The cost is a component in the traffic route, which makes availability and failure behavior first-order requirements. The two are not mutually exclusive, and some teams will use both for different layers.
Trussed is built for the second case. It enforces policy at runtime, not reviewed after the fact, and keeps 100+ models under one policy plane. It has run continuously for 18+ months in production in a regulated enterprise, generates 30+ GB of audit evidence per day, and serves customers in insurance, pharma, healthcare and education. Its certifications and attestations include SOC 2 Type II, HIPAA, GDPR, FERPA, ISO 27001 and NIST AI RMF. It also provides code provenance, covering the origin, licence and security context of code.
Two places to apply AI policy
Application-invoked API service
The application sends content to a service and acts on the result.
In-path runtime enforcement
Policy is applied to traffic as it passes through the control.
Coverage
Defined by the calls sent versus the traffic routed.
Enforcement
A returned verdict versus an action taken by the control.
Evidence
Records of service calls versus evidence produced by enforced decisions.
Test enforcement against your own AI estate
Walk through how policy is enforced on model calls, agent tool calls and coding assistants, and what audit-ready evidence each decision produces.
Explore Agent and Tool-Call Enforcement