Decide what business agents can do. See what coding agents actually do. Bring policies, human review and decision evidence together with DriftGard.
DriftGard Refund agentINTERACTIVE EXAMPLEissue_refundAUD 250 is below the AUD 500 automatic limit. The application may execute this refund.
Illustrative policy. Local simulation only. No refund is executed.
Fits the tools your team
already builds with.
A useful agent can still take the wrong action.
Give every consequential action an explicit decision.
Two starting points. One place to manage policies and investigate decisions. Start with the workflow you need to govern.
For agents that approve payments, assign contractors, update records, send data externally or call other business tools.
For engineering teams using coding assistants across repositories and development workspaces.
Manage the rules beyond your application code. Define agent permissions, version policies, review eligible exceptions and investigate decisions in one place. Your application keeps a consistent check before each tool runs.
Set allowed tools, agent identities, required fields and parameter limits in a versioned Control Pack.
Hold eligible calls for approval. Keep invalid identities and parameters blocked. Choose what happens on timeout.
Inspect the proposed call, matched rules, policy version and final review outcome.
Example thresholds, not a prescribed refund policy. You define the rules.
Workspace: /work/frontend
Finding: destructive command pattern
Finding: potential secret exposure
Illustrative activity. A finding does not mean an action was prevented.
Connect the local observer to supported coding-agent sessions. Review captured tool calls and policy findings across the workspaces your team uses.
Map multiple folders to one DriftGard project and use a Software Development Control Pack.
Investigate recorded activity by agent, developer, tool and workspace. See the policy evidence behind each finding.
The passive observer evaluates recorded activity. It does not interrupt commands or wait for human approval.
Codex · Claude Code · Cursor · Kiro · GitHub Copilot
Capture coverage depends on the host and local session format.
Guided setup brings the configuration, connection and verification steps into your agent’s workspace.
Select business or coding. Add its identity and tools, or the workspaces you want to monitor.
Define your rules in a versioned Control Pack. Test expected allow, block and review-threshold outcomes before activating a policy version.
Create a project key. Connect your application or observer and verify captured activity.
Review activity, handle eligible approvals and use the evidence to refine your controls.
Follow the proposed action from the original policy decision through any human review to the final authorization. Keep the reason for an exception alongside the rule that first blocked it.
An allowed decision authorizes an action; it does not confirm execution. Confirming what happened requires evidence from your connected application. Use audit history, integrity checks and exports to support investigations.
See the evidence workflowConnect at the tool boundary for business agents, or collect supported local activity with the coding observer.
Evaluate proposed tool calls through the Python or Node.js SDK, a framework adapter, or the REST API.
Run the observer on your development machine. Map folders to projects and send captured activity for policy evaluation.
Keep your agent and tools. Add a policy decision at the execution boundary.
def guarded_refund(parameters, issue_refund):
result = dg.evaluate(
project_id=os.environ["DRIFTGARD_PROJECT_ID"],
model_id="agent-runtime", eval_mode="tool_call",
agent_id="refund_agent_01", agent_role="refund_agent",
tool_call={"tool_name": "issue_refund",
"parameters": parameters},
)
if result.get("evaluation", {}).get("allowed") is not True:
raise RuntimeError("Refund not authorized")
return issue_refund(**parameters)
# pip install driftgard
import os
from driftgard import Driftgard
dg = Driftgard(
api_key=os.environ["DRIFTGARD_API_KEY"],
failure_mode="closed", timeout=90, max_retries=0,
)
async function guardedRefund(parameters, issueRefund) {
const result = await dg.evaluate({
project_id: process.env.DRIFTGARD_PROJECT_ID,
model_id: "agent-runtime", eval_mode: "tool_call",
agent_id: "refund_agent_01", agent_role: "refund_agent",
tool_call: { tool_name: "issue_refund", parameters },
});
if (result?.evaluation?.allowed !== true) {
throw new Error("Refund not authorized");
}
return await issueRefund(parameters);
}
// npm install @driftgard/node
import { Driftgard } from "@driftgard/node";
const dg = new Driftgard({
apiKey: process.env.DRIFTGARD_API_KEY,
failureMode: "closed", timeout: 90_000, maxRetries: 0,
});
Server-side example. Set your project ID and API key in the environment, activate matching identity and tool rules, and pass your proposed parameters and existing refund function. Live approval requires separate configuration; this example allows 90 seconds for a 60-second review window. Unavailable checks fail closed, and exceptions stop execution. Never expose the key in browser code.
Yes. Connect the proposed tool call to DriftGard through an SDK, a supported framework adapter or the REST API. Keep the authorization check in the application’s execution path so the tool only runs after an allowed decision.
Measure it with your own policies, traffic and deployment. Network time and enabled checks affect response time; human review deliberately holds eligible requests. During a trial, measure typical and slow-request latency, test failures, and align application and proxy timeouts with your approval window.
No. Your agent chooses what to do; your application still runs the tools. DriftGard evaluates the connected calls against policy. The integration must enforce the final decision before executing a tool.
A connected business-agent application sends the proposed call to DriftGard before execution. Policy can allow or block it. A blocked call that meets your live-review criteria can be held for a reviewer. Excluded categories remain blocked, and your timeout setting determines what happens if nobody responds.
The passive observer reads recorded activity and evaluates it. A blocked policy result in this mode does not mean the command was stopped. Preventing execution requires a supported inline integration that checks and enforces the decision before the action runs.
Hosted evaluation receives the content your integration submits. The coding observer can submit captured content, with secret redaction enabled in the setup example. Redaction is not a guarantee that all sensitive data is removed. SDK local evaluation offers a different data path for supported checks. We will confirm the data flow and retention settings for your workflow.
Yes. Start with one business workflow or a set of coding workspaces. We agree trial scope, duration, evaluation volume, retention, support and pricing before activation. Tell us what you want to connect.
Failure handling depends on your integration and configuration. For a workflow that must not proceed without authorization, use fail-closed handling and test API failures, timeouts and malformed responses before rollout.
No. Authorization, execution and business outcome are different events. A decision record shows what DriftGard evaluated and decided. Execution confirmation requires evidence from the connected application. Policy checks and audit evidence also do not, by themselves, certify regulatory compliance.
Bring one workflow, one tool or one coding workspace.
We’ll help you put the right controls and evidence around it.