Put limits around actions
Check tool permissions, parameters, and supplied identity context. Have your connected application block a request or hold it for review before execution.
Runtime governance for AI agents
Control what your AI agents can do.
DriftGard gives you a management console, APIs and SDKs to test policies and check proposed AI actions. Your connected application uses the returned decision to allow, block or hold execution for review.
For developers, startups, growing businesses, and enterprises.
Start with one agent workflow.
One action. Three possible outcomes.
01 / Proposed actionSupport agent
// Before the application runs the tool
{
"tool": "issue_refund",
"amount": 4250,
"exception": false,
"role": "customer_support",
"policy": "refund-policy-v3.4"
}DriftGard checks the proposed action against policy and returns a decision. Your connected application uses it to allow, block, or hold execution for review.
1. ProposeAI agent
2. CheckDriftGard
3. Application enforcesRefund stopped
Policy evaluationissue_refund
Blocked
Amount$4,250
Policy ruleAgent limit: $500
PolicyRefund Policy v3.4
Example evidenceDG-DEMO-BLOCK
The refund exceeds the agent’s $500 limit. The application stops the refund and records the policy decision.
Illustrative scenario, not a live evaluation. No payment is sent. Review holds the action until an authorised person decides.
Fits into your workflowNode.jsPythonModel gatewayCLI & CI/CDLocal evaluation
Why DriftGard
Clear rules. Controlled actions.
Decisions you can investigate.
Keep your agent framework. Add checks where your application needs to decide what happens next.
Maintain tested policies
Test expected outcomes and compare policy versions. Use selected human-reviewed examples in benchmarks before activating your next Control Pack.
Investigate the decision
Inspect triggered controls, the policy version where available, and human review records. Generate reports organised by governance framework to support investigation and assurance.
What you can govern
Actions
Set tool permissions and parameter limits, such as a refund amount. Check supplied role and identity context before your integration runs the tool.
Content
Apply configured checks to prompts, responses and sensitive data. Return a block or redaction decision for your connected workflow to apply.
Models and spend
Set approved models, configure gateway routing and track usage and cost. Use configured thresholds to flag or limit spending in supported workflows.
Before. During. After.One policy lifecycle.
One policy lifecycle.
Three ways to stay in control.
Test what should happen, decide what can happen, and investigate what did happen.
Find the rule that needs work
before you activate it.
Run known examples against a Control Pack—a versioned set of rules—and compare expected and actual decisions.
- Benchmarks with expected allow or block outcomes
- Backtests against historical evaluations
- Synthetic prompts for configured HTTP targets
Policy benchmarks test your rules’ decisions. Testing an agent’s real actions also needs the right context and access.
Explore the developer quickstart →Give your application
a decision it can act on.
Evaluate prompts, responses and proposed tool calls against the active policy. Your connected application or gateway applies the result.
- Tool permissions and parameter limits
- Configured content and sensitive-data checks
- Human review for supported approval workflows
Start in log-only mode. Enable enforcement at the decision points your integration connects.
Try an allow, block or review decision ↑See what changed.
Know where to investigate.
Review policy violations, block rates and risk trends. Inspect individual evaluations and bring useful examples into the next benchmark.
- Baseline comparisons and configured alerts
- Triggered controls and decision evidence
- Human-reviewed examples for future policy tests
A change in violations is a signal to investigate. Traffic and policy changes can affect the trend too.
See the product ↓Inside DriftGard
From the rule you define
to the decision you review.
A closer look at DG’s product components, shown with fictional demonstration data. Select a screen to explore it at a larger size.
01 / DEFINE & TEST
Make your rules explicit.
Bring tool permissions, response rules, and risk thresholds into a versioned Control Pack. Test the cases you expect to allow or block before activating a change.
Look for the policy version, configured controls, and individual rule details.
02 / APPLY
See why a request was blocked.
Follow the evaluation’s decision path and inspect the controls that contributed to it. Your connected application uses that result to decide whether the real action proceeds.
Here, a proposed $4,250 refund crosses the configured $500 limit.
03 / REVIEW
Bring a person into the decision.
For connected live-review workflows, a reviewer can inspect a held AI response and its triggered controls, then approve release or reject it.
This example holds a refund confirmation for review. No customer response is sent.
Improve the next policy version
Turn reviewed examples into policy tests.
After human review, save useful prompt and response examples as benchmark candidates. Run them against a proposed Control Pack version and inspect the policy outcomes before deciding to activate it.
01
Define rules
Choose a workflow and create a versioned Control Pack.
02
Test a version
Check expected outcomes and compare policy changes before activation.
03
Apply checks
Observe connected traffic, then enable selected controls.
04
Review and benchmark
Investigate results and select reviewed examples to test your next version.
Who it’s for
One developer or multiple teams.
Start where your agents act.
You don’t need an enterprise rollout. You need a workflow worth governing and a way to connect it.
Individual developers
Review supported coding-agent activity, or add policy checks to agents you build. Blocking requires a pre-execution integration.
Explore developer tools →Startups
Put rules around customer-facing agents, sensitive data, and tools that change real systems as you move into production.
Discuss your workflow →Small & medium businesses
Add checks and human review to support or internal operations workflows, with your technical team or implementation partner.
Scope a trial →Enterprises
Coordinate policies, review workflows, and decision evidence across connected projects. Agree deployment and access requirements with us.
Discuss your requirements →Consultancies & partners
Help clients implement repeatable agent controls. Explore partner tooling for managing separate client organisations.
Explore a partnership →Connect your existing stack
Keep your stack.
Choose your control point.
Coverage follows the decision points you connect. Start in log-only mode and enable enforcement where your integration supports it.
Inside your application
Evaluate prompts, responses, and proposed tool calls. Your application acts on the returned policy decision.
Along the model request path
Connect model traffic for central routing, input and output checks, and evaluation records. Enforcement depends on the configured mode.
Explore the SDK and gateway ↗Visibility for developers
Collect supported coding-agent activity for policy evaluation and investigation. Transcript observation happens after the fact; blocking needs a supported pre-tool hook.
As policies change
Validate, lint, test, compare, and promote Control Packs through your development workflow.
CLI documentation ↗Developer quickstart
Connect a test workflow before production traffic.
During onboarding, create a project, activate its Control Pack, and create a project API key. Install the SDK in your server application. This example evaluates a proposed refund without executing a payment.
View the Node.js example
npm install @driftgard/node
import { Driftgard } from "@driftgard/node";
const dg = new Driftgard({
apiKey: process.env.DRIFTGARD_API_KEY,
});
const result = await dg.evaluateToolCall({
project_id: process.env.DRIFTGARD_PROJECT_ID,
model_id: "support-agent",
tool_name: "issue_refund",
parameters: { amount: 4250 },
agent_role: "customer_support",
});
console.log(result.decision_action, result.evaluation.allowed);
Use test data and a Control Pack that defines your refund rules. Keep API keys on the server. To enforce decisions, handle block and review outcomes in your application before calling the real tool.
Trial & pricing
One workflow. A clear test of value.
Request a trial for an agent you are building or operating. We agree the scope and price with you before activation.
What we work through together
- Choose one agent workflow and the business rules it must follow.
- Connect a test environment and review results in log-only mode.
- Test allowed, blocked, and review-required cases where supported by the integration.
- Inspect the evidence and decide whether to expand.
What your quote will specify
The trial fee, duration, included evaluation volume, retention, deployment mode, and support. We also agree usage limits and what happens if you need more capacity.
How we measure success
Time to your first useful evaluation, coverage of agreed test cases, false blocks, added latency, and whether the evidence answers your team’s questions.
Trial access is arranged with the team after we agree the scope and terms.
Before you connect
A few things before you connect.
Is DriftGard only for enterprises?
No. Individual developers, startups, small and medium businesses, and larger organisations can use DriftGard for connected AI workflows. The right setup depends on what your agents do, the controls you need, and the integration you can support. Trial scope and pricing are agreed with you.
How does DriftGard help individual developers?
The coding-agent observer can collect supported agent activity for policy checks and investigation. SDKs can check actions in applications you build, including selected policies evaluated locally. Blocking needs a supported pre-execution integration; observing a transcript cannot stop an action that already happened. DriftGard complements code review and testing.
Why add DriftGard if we already have an AI platform?
Your platform may already provide the controls you need. Evaluate DriftGard when you want to connect policy versions, runtime checks, human review, benchmarks and decision evidence across your applications. Start with a workflow where your current setup leaves a gap, and use the trial to demonstrate the additional value.
Does DriftGard replace our agents or orchestration platform?
No. Your agents and workflows continue to run in your application. DriftGard evaluates connected decision points through SDKs, a model gateway, or agent hooks. Coverage depends on what you integrate and the context you supply.
Can we observe first, and does the observer block actions?
You can start in log-only mode to review policy results before enforcing them. The coding-agent observer records and evaluates activity. It cannot stop an action that already happened. Inline blocking requires your application, gateway, or an agent hook to enforce the decision.
What data leaves our environment?
Hosted evaluation sends the content you submit to DriftGard. Local evaluation can keep prompts, responses, and tool arguments within your environment, while SDKs sync configuration. Local-with-audit mode also reports verdict metadata. We confirm the data path and retention settings for your trial.
What happens if DriftGard is unavailable or adds latency?
SDK integrations support configurable fail-open or fail-closed behaviour and a circuit breaker. Choose the behaviour for your workflow and measure added latency during the trial. Buffered gateway enforcement checks complete output before release. Pass-through streaming sends content before final output evaluation and cannot retract delivered content.
Does a passing check guarantee correctness or compliance?
No. A policy decision reflects the configured rules and supplied context. Stored evaluations and reports support investigation and assurance. They do not guarantee that an answer is correct, that every risk is detected, or that an organisation meets all regulatory obligations.
Can we start without an enterprise rollout?
Yes. Propose one workflow and a bounded test. We agree access, policy setup, integration requirements, price, and success criteria before activation. Setup time depends on your environment and access approvals.
Which action needs a rule?
Tell us what your agent does and what must stay under control. We’ll help you scope a trial around that workflow.