Quick Start
Integrate in under 30 minutes
Step 1 — Get your API key
Sign up at veridion-nexus.eu. Your API key is displayed once on the success screen and emailed to you. It starts with ss_test_
Step 2 — Make your first evaluation
curl -X POST https://api.veridion-nexus.eu/api/v1/shield/evaluate \
-H "Authorization: Bearer ss_test_your_key_here" \
-H "Content-Type: application/json" \
-d '{
"destination_country_code": "US",
"data_categories": ["email", "name"],
"partner_name": "OpenAI",
"agent_id": "agt_your_agent_id",
"agent_api_key": "agt_key_your_agent_api_key"
}'Step 3 — Handle the decision
const { decision, reason, legal_basis } = response;
if (decision === 'BLOCK') {
throw new Error(`Transfer blocked: ${reason}`);
}
if (decision === 'REVIEW') {
await queueForHumanReview(transferId);
return; // do not proceed
}
// decision === 'ALLOW' — proceed with transferIntegration Patterns
Where does evaluate() fit?
Veridion Nexus works at your application's outbound layer — the point where your code calls an external API. You don't need to add it to every line of code. Add it once, to the wrapper function that calls your AI provider.
How to set destination_country_code
This field is not auto-detected — you set it once per vendor integration based on where that vendor processes data. Example: OpenAI → "US", AWS Frankfurt → "DE", Anthropic → "US". You define it as a constant in your wrapper function, not dynamically per call.
Pattern 1 — Direct wrapper (simplest)
Wrap your AI provider call. One function, one evaluate() call.
def call_openai(messages, user_data):
# Evaluate before every external AI call
shield = evaluate_transfer(
agent_id="agt_your_agent_id",
agent_api_key="agt_key_your_agent_api_key",
destination_country_code="US",
data_categories=["email", "name"],
partner_name="OpenAI"
)
if shield["decision"] == "BLOCK":
raise Exception("Transfer blocked")
if shield["decision"] == "REVIEW":
queue_for_review(shield["seal_id"])
return None
return openai.chat.completions.create(
messages=messages
)Pattern 2 — LangChain middleware
Add as a LangChain callback or middleware. Evaluates automatically before every LLM call.
from langchain_core.callbacks import BaseCallbackHandler
class SovereignShieldCallback(BaseCallbackHandler):
def on_llm_start(self, serialized, prompts, **kwargs):
result = evaluate_transfer(
agent_id="agt_your_agent_id",
agent_api_key="agt_key_your_agent_api_key",
destination_country_code="US",
data_categories=["email"],
partner_name="OpenAI"
)
if result["decision"] == "BLOCK":
raise BlockedTransferError(result["reason"])
# Add to your LLM
llm = ChatOpenAI(callbacks=[SovereignShieldCallback()])Pattern 3 — Express middleware (Node.js)
Add as Express middleware to evaluate all outbound requests automatically.
const shieldMiddleware = async (req, res, next) => {
const result = await shield.evaluate({
agentId: 'agt_your_agent_id',
agentApiKey: 'agt_key_your_agent_api_key',
destinationCountryCode: 'US',
dataCategories: req.body.dataCategories || [],
partnerName: req.body.partnerName
});
if (result.decision === 'BLOCK') {
return res.status(403).json({
error: 'Transfer blocked',
reason: result.reason
});
}
req.shieldDecision = result;
next();
};
app.use('/api/ai', shieldMiddleware);Not using a framework? The Direct Wrapper pattern works for any language. See for curl, Python, and Node.js implementations.
Authentication
All API requests require a Bearer token in the Authorization header.
Authorization: Bearer ss_test_your_api_key| Header | Required | Description |
|---|---|---|
| Authorization | Yes | Bearer {api_key} |
| Content-Type | Yes | application/json |
API keys start with ss_test_ for trial accounts and ss_live_ for Pro accounts.
Agent Registration
All evaluate() calls must originate from a registered agent. Sign in to the dashboard and open the Agents section before integrating the API.
Each registered agent receives:
agent_id— unique identifier (format: agt_XXXXXXXX)agent_api_key— secret key shown once at registration (format: agt_key_XXXXXXXX)
Both are required on every evaluate() call alongside your tenant API key.
Quick registration steps
- Sign in to the dashboard and open the Agents section
- Click "Register New Agent"
- Complete the 5-step wizard (identity, data policy, transfer policy, autonomy & oversight, review)
- Copy your
agent_idandagent_api_key— the key is shown only once
Evaluate Transfer
POST /api/v1/shield/evaluate
Evaluates a cross-border data transfer and returns a compliance decision with a cryptographically sealed evidence record.
Request body
| Field | Type | Required | Description |
|---|---|---|---|
| agent_id | string | Required | Registered agent ID (agt_...). Obtain from the Agents page in the dashboard. |
| agent_api_key | string | Required | Agent API key (agt_key_...). Shown once on registration; rotate via dashboard if lost. |
| destination_country_code | string | Yes | ISO 3166-1 alpha-2 country code (e.g. "US", "CN") |
| data_categories | array | Yes (optional, defaults to REVIEW) | Personal data categories being transferred (e.g. ["email", "name"]) |
| partner_name | string | No | Name of receiving party (e.g. "OpenAI") |
| source_ip | string | No | Source IP address |
| dest_ip | string | No | Destination IP address |
| protocol | string | No | Transfer protocol (e.g. "HTTPS") |
| request_path | string | No | API endpoint being called |
Calls without agent_id and agent_api_key return 400 AGENT_REQUIRED. Register your agent in the dashboard before making your first transfer call.
Example request
{
"source_system": "my-ai-agent",
"destination_country_code": "US",
"data_categories": ["financial"],
"partner_name": "OpenAI",
"agent_id": "agt_abc123def456",
"agent_api_key": "agt_key_abc123..."
}Example responses
ALLOW (EU/EEA destination):
{
"decision": "ALLOW",
"reason": "Germany is EU/EEA — no transfer restrictions",
"legal_basis": [],
"country_status": "eu_eea",
"seal_id": "seal_a1b2c3d4e5f6...",
"evidence_id": "evt_..."
}ALLOW (Adequate country):
{
"decision": "ALLOW",
"reason": "Japan has EU adequacy decision",
"legal_basis": ["GDPR Art. 45"],
"country_status": "adequate_protection",
"seal_id": "seal_...",
"evidence_id": "evt_..."
}REVIEW (SCC required):
{
"decision": "REVIEW",
"reason": "United States requires SCC — human review needed to verify safeguards",
"legal_basis": ["GDPR Art. 46(2)(c)"],
"country_status": "scc_required",
"seal_id": "seal_...",
"evidence_id": "evt_..."
}BLOCK:
{
"decision": "BLOCK",
"reason": "China blocked by organizational policy — GDPR does not prohibit transfers to a country by name; this product tier is not permitted",
"legal_basis": ["GDPR Art. 44", "GDPR Art. 46"],
"country_status": "blocked",
"seal_id": "seal_...",
"evidence_id": "evt_..."
}Response Reference
Response fields
| Field | Type | Description |
|---|---|---|
| decision | string | ALLOW, BLOCK, or REVIEW |
| reason | string | Human-readable explanation |
| legal_basis | array | Applicable GDPR articles |
| country_status | string | eu_eea, adequate_protection, scc_required, blocked, unknown |
| seal_id | string | Cryptographic seal ID for evidence lookup |
| evidence_id | string | Evidence event ID in the vault |
Decision logic
| Destination | Personal Data | SCC Registered | Decision |
|---|---|---|---|
| EU/EEA country | Any | N/A | ALLOW |
| Adequate country (Art. 45) | Any | N/A | ALLOW |
| SCC-required country | No | N/A | ALLOW |
| SCC-required country | Yes | Yes (active) | ALLOW |
| SCC-required country | Yes | No | REVIEW |
| Blocked country | Any | N/A | BLOCK |
| Unknown country | Any | N/A | REVIEW |
| Missing data_categories | — | — | REVIEW |
Error Codes
| HTTP Status | Code | Description |
|---|---|---|
| 400 | AGENT_REQUIRED | Missing agent_id or agent_api_key. Register in the dashboard Agents section |
| 400 | bad_request | Missing or invalid request body |
| 401 | unauthorized | Missing or invalid API key |
| 402 | trial_expired | Trial period has ended |
| 422 | validation_error | Request validation failed |
| 500 | internal_error | Server error |
Error response format:
{
"error": "unauthorized",
"message": "Missing or invalid API key"
}Shadow Mode
During your 30-day trial, your account starts in Shadow Mode.
Shadow Mode behaviour
- • All transfers are evaluated normally
- • ALLOW/BLOCK/REVIEW decisions are made and sealed in evidence
- • Your application always receives ALLOW — nothing is blocked
- • Use this to understand your transfer risk profile
Enforce Mode behaviour
- • All transfers evaluated normally
- • BLOCK decisions actually block the transfer (API returns 403)
- • REVIEW decisions queue for human approval
- • Available after upgrading to Pro
Switch between modes in your dashboard under Settings.
Code Examples
Evaluate a transfer to the US (OpenAI):
# Evaluate a transfer to the US (OpenAI)
curl -X POST https://api.veridion-nexus.eu/api/v1/shield/evaluate \
-H "Authorization: Bearer ss_test_your_key" \
-H "Content-Type: application/json" \
-d '{
"destination_country_code": "US",
"data_categories": ["email", "name"],
"partner_name": "OpenAI",
"agent_id": "agt_your_agent_id",
"agent_api_key": "agt_key_your_agent_api_key"
}'Evaluate a transfer to Germany (EU/EEA - always ALLOW):
# Evaluate a transfer to Germany (EU/EEA - always ALLOW)
curl -X POST https://api.veridion-nexus.eu/api/v1/shield/evaluate \
-H "Authorization: Bearer ss_test_your_key" \
-H "Content-Type: application/json" \
-d '{
"destination_country_code": "DE",
"data_categories": ["email"],
"partner_name": "AWS Frankfurt",
"agent_id": "agt_your_agent_id",
"agent_api_key": "agt_key_your_agent_api_key"
}'MCP Server
Veridion Nexus is available as an MCP (Model Context Protocol) server. This makes GDPR transfer evaluation available as a tool in Claude and Cursor workflows, without manual API integration.
veridion-nexus-mcpRun:
npx -y veridion-nexus-mcpEnv:
VERIDION_NEXUS_API_KEYveridion-nexus-gatewayRun:
npx -y veridion-nexus-gatewayEnv:
AL_API_BASE_URL, AL_SERVICE_TOKEN, UPSTREAM_MCP_COMMAND — see the Accountability Ledger section below.Sovereign Shield — published as veridion-nexus-mcp. The evaluate_transfer tool requires agent_id and agent_api_key on every call. Accountability Ledger proxy — install veridion-nexus-gateway separately; it wraps an upstream MCP server and logs tool calls to the ledger (see below).
REST API
- • Manual integration (~30 minutes)
- • Add
evaluate()call before each transfer - • Handle ALLOW/BLOCK/REVIEW in your code
- • Best for: existing codebases
MCP Server
- • 5-minute setup — JSON config only
- • Claude and Cursor can call
evaluate_transferas part of their workflow - • No code changes to your application
- • Best for: AI-native applications and agentic workflows
Setup: Claude Desktop
Sovereign Shield (install using npx): npx -y veridion-nexus-mcp
{
"mcpServers": {
"veridion-nexus": {
"command": "npx",
"args": ["-y", "veridion-nexus-mcp"],
"env": {
"VERIDION_NEXUS_API_KEY": "ss_test_your_key_here"
}
}
}
}File location: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)
Setup: Cursor
Sovereign Shield (install using npx): npx -y veridion-nexus-mcp
{
"mcpServers": {
"veridion-nexus": {
"command": "npx",
"args": ["-y", "veridion-nexus-mcp"],
"env": {
"VERIDION_NEXUS_API_KEY": "ss_test_your_key_here"
}
}
}
}File location: .cursor/mcp.json in your project root.
Available tools
The evaluate_transfer tool now requires agent_id and agent_api_key parameters on every call. Sign in to the dashboard and register your agent in the Agents section first.
| Tool | Parameters | When to use |
|---|---|---|
| evaluate_transfer | agent_id, agent_api_key (required), destination_country_code, data_categories, partner_name, … | Before any external API call with personal data |
| check_scc_coverage | destination_country_code, partner_name | To verify SCC exists for a partner/country |
| get_compliance_status | — | To get account overview and pending reviews |
| list_adequate_countries | filter (optional) | To check a country's GDPR transfer status |
Accountability Ledger
What is the Accountability Ledger
The Accountability Ledger is an MCP proxy that sits between your AI agents and upstream MCP servers. It intercepts every tool call, records it in a tamper-evident SHA-256 hash chain, and forwards the call only after logging succeeds — producing evidence suitable for EU AI Act Article 12 (record-keeping for high-risk AI systems) alongside your existing Sovereign Shield transfer checks.
| Without Accountability Ledger | With Accountability Ledger |
|---|---|
| Tool calls leave no structured audit trail | Every tool call is logged with metadata and chained hashes |
| No cryptographic proof of log integrity | Sequential SHA-256 links detect tampering |
| Hard to demonstrate AI Act oversight to regulators | Evidence vault entries support Art. 12-style accountability |
How it works
- Intercept — the proxy receives the tool call from the agent.
- Hash — inputs/outputs are hashed (minimisation-friendly field lists where configured).
- Log — an append-only record is written to the ledger with the previous entry hash.
- Forward — the call is passed to the real MCP server and the response is logged.
Fail-closed
If logging to the Accountability Ledger fails, the tool call is not forwarded — the agent receives an error instead of silently bypassing compliance.
Setup
Register your agent in the dashboard Agents section, then configure the MCP Governance Gateway (e.g. npx -y veridion-nexus-gateway in stdio mode) with:
| Variable | Required | Description |
|---|---|---|
| AL_API_BASE_URL | Yes | Veridion API base URL (e.g. https://api.veridion-nexus.eu) |
| AL_SERVICE_TOKEN | Yes | Service token issued for proxy→API calls (from your tenant configuration) |
| AL_AUTH_MODE | No | jwks (default) or dev_bypass for local development only |
| UPSTREAM_MCP_MODE | No | stdio (default) or sse |
| UPSTREAM_MCP_COMMAND | Yes (stdio) | Shell command to launch your upstream MCP server |
What gets logged per tool call
| Field | Description |
|---|---|
| agent_id | Registered agent identifier |
| tool_name | MCP tool invoked |
| input_hash | Hash of tool inputs (field-level minimisation where configured) |
| output_hash | Hash of tool outputs |
| timestamp | When the call was recorded |
| latency | End-to-end timing where measured |
| entry_hash | Hash chain link tying this row to the previous ledger entry |
| eu_ai_act_category | Annex III / risk category annotation when applicable |
EU AI Act Art. 12 compliance
Article 12 requires providers of high-risk AI systems to keep logs automatically generated by the system (to the extent such logs are under their control), in a way that ensures an appropriate level of traceability of the system's functioning throughout its lifetime. The Accountability Ledger supports this by creating immutable, time-ordered records of agent tool usage with cryptographic integrity — suitable as part of your technical documentation and audit evidence, alongside organisational measures and risk management.
Supported Annex III high-risk use-case categories (illustrative)
| Category | Examples |
|---|---|
| Biometrics | Remote biometric identification |
| Critical infrastructure | Road traffic, supply of water/gas/electricity |
| Education & vocational training | Access, admission, assignment, assessment |
| Employment & workers management | Recruitment, promotion, termination, task allocation |
| Healthcare | Medical devices, diagnosis, treatment recommendations (where high-risk) |
| Financial services | Credit scoring, insurance pricing, trading / market abuse monitoring |
| Essential services — public & private | Emergency services, benefits eligibility, other essential public services |
| Law enforcement & justice | Evidence evaluation, crime analytics, administration of justice |
| Migration & border | Asylum, visa, border control |
| Democratic processes | Election influence or voter profiling |
Hash-only vs full payload: by default the ledger stores hashes and field names (data minimisation). Full payload capture is not required for the hash chain; your DPA and logging policy should define any additional retention.
Viewing logs and generating reports
Open ACM Overview in the dashboard to review tool-call events, transfer annotations, and oversight items tied to your agents.
- Query the audit trail and filter by agent, time range, or decision
- Run hash-chain verification to prove log integrity end-to-end
- Export compliance bundles as JSON for auditors or your GRC tooling
Limitations
Veridion Nexus supports demonstrable compliance — it does not guarantee it. Understand these limitations before integrating:
Regulatory scope summary: Chapter V alignment is described in product documentation. Country classification lists are maintained in software and reviewed periodically — last reviewed: March 2026. Reconcile against EU Commission sources at least quarterly.
Art. 46 — SCC vs other safeguards
The runtime enforces Standard Contractual Clauses (SCC) via your SCC registry. Binding Corporate Rules (BCR) and other appropriate safeguards under Art. 46 are not evaluated automatically — record them in your own compliance program.
Art. 49 derogations — out of scope
Transfers that might rely on Art. 49 derogations are not automated. Assessment stays with your legal process. Roadmap: possible future support for workflow or evidence capture only — not legal conclusions.
Blocked destinations — organizational policy
The default “blocked” country tier is organizational policy, not a claim that GDPR statutorily prohibits transfers to a given country by name.
Unclassified destinations — conservative default
Unknown or unclassified destinations may be BLOCKed as a conservative product default. Other Chapter V mechanisms may still exist in your legal assessment outside this engine.
Caller-provided classification
Veridion Nexus trusts the data_categories you provide. It does not inspect payload content. If you classify personal data incorrectly, the evaluation reflects that.
Country list is static
EU adequacy decisions change. The blocked/adequate/SCC-required classification is updated manually — it does not pull live from the EU Commission. Verify current adequacy status at commission.europa.eu. Treat last reviewed: March 2026 as a snapshot; plan at least quarterly reconciliation.
Not legal advice
Veridion Nexus is a technical enforcement and evidence tool. It does not replace a DPO, legal counsel, or a Transfer Impact Assessment. Consult a privacy lawyer for your specific situation.
No TIA generation
Transfer Impact Assessments require legal and factual analysis specific to your organisation. Veridion Nexus does not generate TIAs.
Shadow Mode does not block
Veridion Nexus evaluates every transfer and records the real decision — ALLOW, BLOCK, or REVIEW — but always returns ALLOW to your application. No transfers are stopped during Shadow Mode. Use it to observe your risk profile before enabling enforcement.
SCC verification is registry-based
Veridion Nexus checks whether an active SCC exists in your registry for the destination partner. It does not verify the legal validity, completeness, or effectiveness of your safeguards (including supplementary measures under Schrems II), Transfer Impact Assessments, or DPAs. A registry match is not full Chapter V compliance.