TRAXX

AI Governance

How TRAXX's AI is controlled, scoped, audited, and isolated. Built for Indian regulated industries — BFSI, pharma, healthcare, government — where AI access is a compliance question, not just a feature toggle.

The 5 pillars

What "AI Governance" actually means

When a CIO or compliance officer asks "is your AI safe", they mean five very specific things. Here's how TRAXX answers each.

01

Permission-scoped access

Every page-permission row in TRAXX has six independent flags: canView, canCreate, canUpdate, canDelete, canProcess, and canAi. The AI flag is independent — a user can read PO records but be blocked from invoking the AI on them.

In code: AccessManagementInterceptor line 93–95 — "For AI pages, also check canAi flag."
02

Default-deny

The can_ai column defaults to 0 (deny). New users, new roles, new pages — none of them get AI access until an administrator explicitly grants it. There is also a global AI_FEATURE:USE role permission that gates the entire AI subsystem.

In code: V97 migration — ADD can_ai BIT NOT NULL DEFAULT 0.
03

Full audit trail

Every AI tool call passes through AuditInterceptor: user ID, tenant code, tool name, input arguments, returned record IDs, IP, user-agent, timestamp. The audit table is the same one your statutory auditor reviews — AI activity is just another row class.

Aligned with RBI AI/ML guidance §4 (accountability) and §5 (model risk management).
04

Tenant data isolation

Multi-tenant by design — each customer has their own database. TenantContext (an InheritableThreadLocal) is set in JwtAuthFilter before any DB call and cleared in finally. MultiTenantDataSource routes the AI's tool calls only to that tenant's database — there is no shared schema across customers.

DPDPA Section 8 — purpose limitation and storage limitation.
05

Open-source agent framework

The AI is orchestrated by Dify — an open-source agent framework. Every prompt, every tool selection, every reasoning step is inspectable inside Dify Studio. No black box. Your InfoSec team can review the workflow before any deployment.

RBI AI/ML guidance §3 — explainability and interpretability.
Architecture

Why the AI never touches your database directly

The boundary that matters: the AI sees only what your tool callbacks return. Tools are server-side endpoints under your permission system. Even if the AI is told to "give me all vendor details", the tool callback enforces what the user can see.

User Question
"Pull last 3 invoices from BEL"
Dify Agent
decides which tool to call
Your Tool Callback
enforces canAi + permissions
The Dify agent never has database credentials. It calls your HTTP tool endpoints. Your endpoints check canAi, then return only what the user is allowed to see — same as if the user had clicked the page themselves.
For regulated industries

If your DD checklist mentions RBI or DPDPA, read this.

RBI AI/ML guidance alignment

  • ✓ §3 Explainability — open-source Dify, inspectable workflows
  • ✓ §4 Accountability — full AuditInterceptor trail
  • ✓ §5 Model risk management — hallucination guards, response sanitization
  • ✓ §6 Data governance — permission-scoped tool callbacks

DPDPA principles alignment

  • ✓ Sec 8(2) Purpose limitation — AI access bound to user's role
  • ✓ Sec 8(7) Storage limitation — audit log retention configurable
  • ✓ Sec 8(4) Accuracy — every AI claim cites source records
  • ✓ Sec 11 Data principal rights — user can request AI activity log on their data

On-premise deployment & model selection — roadmap

For BFSI customers with stricter requirements, the following are on the active roadmap:

  • Q3 2026 — Model abstraction layer (Claude / Anthropic alongside OpenAI; per-tenant model selection)
  • Q3 2026 — Data classification with AI opt-out per data class (PAN, Aadhaar, KYC documents)
  • Q4 2026 — Single-tenant on-premise / VPC deployment package
  • Q4 2026 — Pen-test report covering the AI surface specifically
If you're a BFSI customer with a specific RBI / DPDPA gap, talk to us — roadmap items can be brought forward for committed deployments.

Compliance team questions

Is the AI sandboxed? +
The AI is permission-scoped — every tool call enforces the user's role and the page-level canAi flag. It is not a runtime sandbox in the JVM/container sense, but it is functionally equivalent for the buyer's compliance question: the AI cannot see, or act on, anything the user is not allowed to. Per-tenant Dify workspace isolation is on the Q4 2026 roadmap.
Which LLM does it use? +
Today: OpenAI via Dify orchestration. The architecture is model-agnostic by design — Dify supports Anthropic Claude, OpenRouter, local LLMs, and custom endpoints. Per-customer model selection (e.g. Claude for BFSI) ships Q3 2026.
Where does the AI run? +
The Dify orchestrator runs in our managed cloud (single-tenant per customer for the database; shared Dify instance with tenant scoping today). The LLM provider runs wherever its endpoint is hosted. On-premise / customer-VPC deployment for the full stack is on the Q4 2026 roadmap.
Can our InfoSec team review the AI workflow before go-live? +
Yes. Dify is open-source and the workflow is inspectable in Dify Studio — every prompt template, tool, and reasoning step. We provide read-only access for your InfoSec / compliance team during DD.
Can we get an audit-trail extract for a specific time window? +
Yes. The same audit table that supports CARO 2020 evidence extracts also contains every AI tool call. Filter by date range, user, tool, or tenant — exportable as CSV or PDF.

Send this page to your compliance team

If your DD checklist asks AI-governance questions, this is the page to share. Schedule a session to walk through the architecture with your InfoSec lead.

Schedule a Demo Contact Sales