How many checkpoints does Raidu run on every AI execution?

Five. User Input, Before LLM, Before Tool, After Tool, and Agent Response. Every interaction passes through every checkpoint and leaves a tamper-evident record.

What is the latency overhead per checkpoint?

You choose how deep the checking goes for each use case.

How does connector-aware PII enforcement work?

Every connector declares the PII it needs to function in a manifest. The firewall adapts per connector. Gmail sees emails, Stripe does not. Change a manifest and every execution after that change proves it used the new policy.

How does Raidu protect the audit trail?

Every record is hash-chained with SHA-256 and written to write-once storage with 10-year retention.

What guardrails does Raidu run?

61 guardrail policies across 36 detection services and four stages. Input guardrails: prompt injection, jailbreak detection, PII and PHI, PCI, tool-abuse attempts. Pre-inference: PII masking, secrets redaction, topic policy, model policy. Tool-call: connector-aware PII, scope, budget, rate. Post-inference: hallucination, bias, toxicity, groundedness, data exfiltration, content filter, code safety. Plus policy and compliance controls: approval gates, masked logging, data residency, retention, regulatory mapping, legal hold, audit replay. 61 guardrail policies are configurable.

Platform

One place to approve, monitor and record every AI call.

Raidu sits between your applications and the models they call. It applies your rules before each call, tracks your spend with budgets and alerts, and keeps the record your reviewers ask for.

In plain words. Five checks run on every AI message, before it reaches the model and after it answers. Private details are replaced. Your rules are applied. Spend is tracked with budgets and alerts. Every decision is written to a record that shows if anyone changes it. The technical detail below is for your IT team.

Illustrative. No customer data.

SOC 2 Type II ISO/IEC 27001:2022 certified · Tower platform HIPAA compliant GDPR compliant DPDP full obligations · 13 May 2027 SOC 2 Type II ISO/IEC 27001:2022 certified · Tower platform HIPAA compliant GDPR compliant DPDP full obligations · 13 May 2027

In the path. Not beside it.

Raidu sits between people, agents and workflows and the models and tools they reach for. Calls routed through it are checked before they arrive.

HUMAN (CHAT)

AGENT

WORKFLOW

IDE ASSISTANT

API CLIENT

RAIDU RUNTIME

5 checkpoints

PII MASK · POLICY · HASH-CHAIN · WORM

467 MODELS / 60+ PROVIDERS

GMAIL · OUTLOOK · SLACK

JIRA · LINEAR · ASANA

STRIPE · HUBSPOT · ZENDESK

S3 · SNOWFLAKE · BIGQUERY

◆ Write-once audit log, hash-chained so any change shows, kept for 10 years. Signed with your own key

The runtime

Five checkpoints. Each explainable. Each on record.

Checkpoint 01 · User Input · user prompt

PII detected and noted by type and position. Raw values are not written to the record. The AI understands the original request. The governance record is already open.

What fires

detect_entities attach_context open_execution

Example trace

INPUT → "send contract to jane.doe@acme.com, SSN 412-55-9021, card 4242 4242 4242 1234"

EMAIL US_SSN CREDIT_CARD

checks per call

personal-data and credential types

on record

each decision

Guardrails

61 guardrail policies in 27 categories. 36 detection services.

Every guardrail runs inline. Every match produces a plain-English explanation. Every decision is on a tamper-evident record.

PII Detection Input

SSN, credit card, phone, email, address; 79 entity types

PHI Detection Input

HIPAA-scoped patient identifiers, MRN, diagnosis codes

PCI Detection Input

Card PAN, CVV, track data, cardholder name

Prompt Injection Input

Direct, indirect, multi-turn, encoding tricks

Jailbreak Input

Roleplay, DAN, persona exploits, context escalation

Secrets Pre-inference

AWS keys, GitHub tokens, API keys, private keys

Topic Policy Pre-inference

Allow / deny lists per team, per model

Model Policy Pre-inference

Approved model list · per-use-case routing

Tool Policy Tool call

Which agents can call which connectors

Scope Policy Tool call

Which records each tool call is allowed to touch

Budget Policy Tool call

Per-user, per-agent, per-model budgets and alerts

Rate Policy Tool call

Requests per second, burst control

Data Exfiltration Post-inference

Outbound secrets, tokens, keys, internal IDs

Toxicity Post-inference

Hate, harassment, violence, self-harm

Bias Post-inference

Protected class, hiring, lending, healthcare

Hallucination Post-inference

Cross-reference against source documents

Groundedness Post-inference

Confidence scoring for every factual claim

Content Filter Post-inference

Sexual, CSAM, extremism, weaponry

Code Safety Post-inference

Malware, license risk, credential leaks in generated code

Approval Gates Policy

Human-in-the-loop for high-risk actions

Masked Logging Policy

Never log raw PII anywhere after ckpt 02

Custom Policy

Configurable policy rules, versioned and auditable

Data Residency Compliance

Keep records in the region where they were written

Retention Policy Compliance

TTL per data class, redaction on expiry

Regulatory Mapping Compliance

EU AI Act · HIPAA · GDPR · SB 26-189

Legal Hold Compliance

Freeze records on litigation trigger

Audit Replay Compliance

Re-run past executions with new policy

Connector-aware firewall

Gmail sees emails. Stripe does not.

Every connector declares the PII it needs to function. The firewall adapts per connector. The table is generated from the connector manifest, not hand-written. Change a manifest and every execution after that change can prove it used the new policy.

Connector NAME EMAIL PHONE ADDRESS SSN CREDIT_CARD MRN

Gmail ✕ ✕ ✕

Outlook ✕ ✕ ✕

Slack ✕ ✕ ✕ ✕

Stripe ✕ ✕ ✕ ✕

Salesforce ✕ ✕ ✕

Zendesk ✕ ✕ ✕ ✕

Jira ✕ ✕ ✕ ✕

GitHub ✕ ✕ ✕ ✕ ✕

HubSpot ✕ ✕ ✕

S3 ✕ ✕ ✕ ✕ ✕ ✕ ✕

ALLOWED ✕ DENIED (MASKED) N/A

467

Models supported

473

Prebuilt agent tools

60+

Model providers

PII and credential types