Back to Blog
Tutorial

Add AI Governance to Your AI Agent in 5 Minutes

A hands-on tutorial: install the SDK, add PII redaction, enforce policies, and integrate with LangChain — all in under 5 minutes.

February 12, 2026  ·  6 min read  ·  Tork Network

Correction — 3 August 2026

Published February 2026. This tutorial installed the on-device package and then described cloud behaviour, which is a real conflation and not a wording nit. Code samples are corrected in place; the narrative claims are corrected here.

tork-governance is the on-device family. tork-governance makes the governance decision on your machine. PII detection, redaction and the returned verdict are computed on-device. With no API key it makes zero network calls: prompts, completions and detected PII values never leave the machine, and nothing appears in your dashboard.

Supply an API key and the SDK additionally reports a metadata-only attestation of each decision — the action taken, PII type labels and counts, a risk classification, policy labels and a salted fingerprint. It never sends input text, output text or PII values. The decision itself is still made on-device and is never delayed or changed by reporting. Those attestations appear in your dashboard and are included in the daily on-chain anchor — each one recorded as a client attestation (capture_mode=edge, attested_by=client), a claim Tork recorded but did not execute and cannot independently verify. Requires tork-governance 0.24.0+ (PyPI) or 0.11.0+ (npm).

A decision reported by an on-device SDK is recorded as a client attestation (capture_mode=edge, attested_by=client): a claim Tork recorded but did not execute and cannot independently verify. A decision made by @torknetwork/sdk is recorded as capture_mode=cloud, attested_by=tork — Tork made that call itself. Both are equally immutable once anchored; they differ in what is immutable. A client attestation freezes your claim. A server-governed receipt freezes Tork's own decision.

Two further corrections below: govern() is synchronous and returns output, not governed; and the ~20ms / sub-second latency figures describe the cloud path only. Local governance is free and unlimited — decisions made on your own machine are never metered. Evidence is what is metered: attestations, receipts and anchoring.

“Your AI agent just leaked a customer's Social Security number to a third-party API.”

That's not a hypothetical. It happened last month to a production agent with no governance layer. The fix took 30 seconds — adding one middleware call. The cleanup took three weeks.

This tutorial walks you through adding real governance to your AI agent. Not a toy demo — actual PII redaction, policy enforcement, and compliance receipts that hold up under audit. You'll be done before your coffee gets cold.

Prerequisites

Step 1: Install the SDK

Pick your language. This is the on-device family — tork-governance decides on your machine and its entry class is Tork:

# On-device family — decides locally, entry class `Tork`
 
# Python
pip install tork-governance
 
# JavaScript / Node.js
npm install tork-governance

Want a dashboard row that records Tork's own decision rather than your attested claim? That is the cloud family: npm install @torknetwork/sdk, entry class TorkClient. The two are separate packages — tork-governance does not export TorkClient, so mixing them produces code that does not run.

Optionally set an API key. The on-device SDK governs fine without one, and with no key it makes no network calls at all:

export TORK_API_KEY="tork_live_your_key_here"

Step 2: Add PII Redaction

The most common governance failure is PII leakage — user data passing through to LLMs, logs, or third-party APIs unredacted. Tork detects 50+ PII types across 13 regional formats and redacts them before they leave your system.

Python

from tork_governance import Tork
 
# No api_key = fully local, zero network calls
tork = Tork()
 
# Scan for PII before sending to the LLM.
# govern() is synchronous and runs on-device.
result = tork.govern("Email john@acme.com, SSN 123-45-6789")
 
# result.output → "Email [EMAIL_REDACTED], SSN [SSN_REDACTED]"
# result.pii.matches → the PII types found
safe_content = result.output

JavaScript

import { Tork } from 'tork-governance';
 
// No apiKey = fully local, zero network calls
const tork = new Tork();
 
// Scan for PII before sending to the LLM.
// govern() is synchronous — do not await it.
const result = tork.govern('Email john@acme.com, SSN 123-45-6789');
 
// result.output → "Email [EMAIL_REDACTED], SSN [SSN_REDACTED]"
const safeContent = result.output;

The output field always contains the redacted version — there is no governed field, as this post originally stated. The original text is never logged or stored by Tork: on this package, detection and redaction happen in-memory on your machine and the text never leaves it.

Step 3: Enforce Policies

PII redaction keeps data safe. Policy enforcement keeps your agent safe. Define what your agent is — and isn't — allowed to do:

Python

# default_action decides what happens when PII is found
tork = Tork(default_action="deny")
result = tork.govern(user_message)
 
if result.action == "deny":
  print(f"Blocked: {result.pii.types} ")
  # e.g. "Blocked: [PIIType.SSN]"
elif result.action == "escalate":
  print(f"Needs review: {result.pii.count} ")
  # Continue but log for a human
else:
  # action == "allow" or "redact" — safe to proceed
  llm_response = call_llm(result.output)

JavaScript

const tork = new Tork({ defaultAction: 'deny' });
const result = tork.govern(userMessage);
 
if (result.action === 'deny') {
  throw new Error(`Blocked: ${result.pii.types}`);
}
 
const llmResponse = await callLLM(result.output);

On the on-device package the decision is driven by defaultAction, which is one of allow, redact, deny, or escalate — not the strict/standard/minimal names this post originally used. Named policy tiers and the tool-call rules below are cloud-path features, configured server-side:

// tork.config.json
{
  "blocked_tools": ["shell_execute", "file_delete", "send_email"],
  "require_human_approval": ["database_write", "payment_process"]
}

Step 4: Govern Both Input and Output

Governing input catches prompt injection and PII in user messages. But LLMs can also hallucinate PII or leak training data in their responses. Govern both directions:

Python

# Govern the user's input
input_result = tork.govern(user_msg)
if input_result.action == "deny":
  return "I can't process that request."
 
# Call the LLM with governed input
llm_response = call_llm(input_result.output)
 
# Govern the LLM's output before returning to the user
output_result = tork.govern(llm_response)
return output_result.output

JavaScript

// Govern input
const inputResult = tork.govern(userMsg);
if (inputResult.action === 'deny') return 'I can\'t process that request.';
 
// Call LLM with governed input
const llmResponse = await callLLM(inputResult.output);
 
// Govern output before returning to the user
const outputResult = tork.govern(llmResponse);
return outputResult.output;

Step 5: Integrate with LangChain

If you're using LangChain (or CrewAI, AutoGen, or any of the 128 supported frameworks), Tork plugs in as a callback or middleware — no refactoring required:

Python (LangChain)

from tork_governance.adapters import TorkLangChainCallback
from langchain_openai import ChatOpenAI
 
llm = ChatOpenAI(model="gpt-4")
tork_cb = TorkLangChainCallback(api_key=os.environ["TORK_API_KEY"])
 
# Every LLM call is now governed automatically
response = llm.invoke(
  "Summarize this customer record",
  config={ "callbacks": [tork_cb] }
)

JavaScript (LangChain.js)

import { TorkLangChainCallback } from 'tork-governance/adapters';
import { ChatOpenAI } from '@langchain/openai';
 
const llm = new ChatOpenAI({ model: 'gpt-4' });
const torkCb = new TorkLangChainCallback({
  apiKey: process.env.TORK_API_KEY
});
 
// Every LLM call is now governed automatically
const response = await llm.invoke(
  'Summarize this customer record',
  { callbacks: [torkCb] }
);

The callback intercepts every LLM call, governs input and output, and produces a compliance receipt — zero changes to your existing chain logic. On the on-device package that receipt is a local object in the returned result; it is not sent anywhere and does not reach your dashboard by itself.

Step 6: Verify in the Dashboard

Correction, 3 Aug 2026: this step did not hold for the package installed in Step 1. Running the on-device SDK leaves your dashboard empty by design — with no API key it makes no network calls. Getting these rows requires an API key and an SDK version carrying attestation reporting — tork-governance 0.24.0+ on PyPI or 0.11.0+ on npm, both published 3 Aug 2026. A row reported that way is stored as a client attestation (a claim Tork recorded, not a decision Tork made or verified). The list below describes the cloud path, @torknetwork/sdk, where the decision and therefore the receipt are Tork's own.

Run your agent against the cloud path and head to the Tork dashboard. You'll see:

Compliance receipts are the part auditors care about. Each receipt is cryptographically chained to the previous one, so tampering with any single entry invalidates the entire chain. Hand these to your compliance team for HIPAA, GDPR, SOC 2, or PCI-DSS reporting.

What You Just Built

In under 5 minutes, you added:

On the cloud path that costs ~20ms added overhead at the edge, with cloud governance typically completing in under a second. Those figures are the cloud path's; the on-device package makes no network call, so its cost is local compute only. Your agent is now governed and auditable — without a single architectural change.

Next Steps

Ready to govern your agent?

Free tier includes 5,000 API calls per month. No credit card required.

Get Your API Key

Tork Network Pty Ltd — Sydney, Australia