DEV Community

The Nexus Guard
The Nexus Guard

Posted on

VoltAgent Just Asked Us to Build Their Guardrail Provider Interface. Here Is What We Shipped.

#ai #typescript #security #agents

Galileo just published their 2026 guardrail solutions guide. Deloitte says only 20% of organizations have mature AI governance. The guardrail market is exploding.

But here is the problem: every guardrail solution is a silo. You pick Galileo or NVIDIA NeMo or Guardrails AI, and your agents are locked to that implementation. There is no standard interface for plugging in guardrail logic.

VoltAgent Asked for a Fix

VoltAgent is a 6.8k-star TypeScript framework for building AI agents. They already had InputGuardrail and OutputGuardrail types — handler functions that run before and after model calls.

But the existing system was monolithic. You wrote guardrail functions directly. No way to swap providers. No way for external packages to plug in without coupling to VoltAgent internals.

Maintainer uchibeke opened issue #1166 asking for decoupled guardrail hooks. The requirements:

  1. Allow people to implement their own guardrail — custom logic, custom rules
  2. Use any provider — AIP, APort, or any external implementation
  3. Skip guardrails entirely — everything works like before

We commented with our experience building AIP — cryptographic agent identity with trust scoring. uchibeke said: "Do you mind doing a PR?"

So we did. PR #1171.

The GuardrailProvider Interface

The design is deliberately simple:

interface GuardrailProvider {
  readonly name: string;
  readonly description?: string;
  readonly severity?: GuardrailSeverity;
  readonly tags?: string[];

  evaluateInput?(
    content: string,
    context: GuardrailProviderContext
  ): Promise<GuardrailProviderDecision> | GuardrailProviderDecision;

  evaluateOutput?(
    content: string,
    context: GuardrailProviderContext
  ): Promise<GuardrailProviderDecision> | GuardrailProviderDecision;
}
Enter fullscreen mode Exit fullscreen mode

Providers implement evaluateInput, evaluateOutput, or both. Each returns a decision:

interface GuardrailProviderDecision {
  pass: boolean;
  action?: 'allow' | 'modify' | 'block';
  message?: string;
  modifiedContent?: unknown;
  metadata?: Record<string, unknown>;
}
Enter fullscreen mode Exit fullscreen mode

Three outcomes: let it through, replace it, or block it.

The Factory: Zero Boilerplate Integration

The createGuardrailsFromProvider() factory converts any provider into VoltAgent-native guardrail arrays:

import { Agent, createGuardrailsFromProvider } from '@voltagent/core';

// Any provider: AIP, content filter, PII detector, custom rules
const provider = new MyGuardrailProvider();
const { inputGuardrails, outputGuardrails } = createGuardrailsFromProvider(provider);

const agent = new Agent({
  name: 'guarded-agent',
  inputGuardrails,
  outputGuardrails,
});
Enter fullscreen mode Exit fullscreen mode

Multiple providers compose naturally:

const identity = createGuardrailsFromProvider(new AIPProvider());
const content = createGuardrailsFromProvider(new ContentFilter());

const agent = new Agent({
  inputGuardrails: [...identity.inputGuardrails, ...content.inputGuardrails],
  outputGuardrails: [...identity.outputGuardrails, ...content.outputGuardrails],
});
Enter fullscreen mode Exit fullscreen mode

Why This Matters

The guardrail market is fragmenting fast. Galileo, NVIDIA NeMo, Guardrails AI, Lakera, AWS Bedrock Guardrails — each is a walled garden. If you pick one, you are locked in.

A clean provider interface changes the game:

  • Framework authors get guardrail capabilities without building them
  • Guardrail providers get distribution without framework-specific integrations
  • Users can swap providers without rewriting agent code

This is the same pattern that made database drivers and logging backends work. You do not write SQL directly — you use an interface. You do not call console.log — you use a logger with pluggable transports.

What AIP Brings to This

AIP implements GuardrailProvider with cryptographic identity verification:

  • evaluateInput: verify the requesting agent's Ed25519 signature and check their trust score (PDR — Promise-Delivery Ratio) against a configurable threshold
  • evaluateOutput: sign the response for downstream verifiability

But the interface does not care about AIP specifically. A content filter, a PII detector, a compliance checker — they all implement the same two methods.

The Broader Pattern

This week we also posted AIP as the 5th issuer in a multi-attestation format. Five independent systems — InsumerAPI (on-chain identity), RNWY (behavioral trust), Maiat (job completion), ThoughtProof (attestation), AIP (trust delegation) — producing composable verification.

The guardrail provider interface and the multi-attestation format solve the same problem at different layers: how do you make trust infrastructure pluggable?

At the framework level: GuardrailProvider interface.
At the verification level: composable attestation arrays.
At the identity level: DID-based cryptographic proofs.

No single system should own the trust stack. The interop pattern wins.

Links:

Top comments (0)