📍 ISACA Chennai Conference 2026 · Workshop 2: ASSURE — AI Guardrails Lab · Chennai, Tamil Nadu

Most AI governance conversations in BFSI stay at the policy level: frameworks, controls, audit checklists. The ASSURE workshop at ISACA Chennai 2026 started from the opposite end. Every participant saw a live prompt injection attack on a banking chatbot, ran an adversarial prompt against a loan document extraction pipeline, and had to explain, in front of the room, why the guardrail they designed didn't catch it.

The point wasn't to be adversarial. It was to build the intuition that risk officers and auditors need when they're reviewing AI deployments: what does a guardrail that actually works look like, and how do you tell the difference between a system that is genuinely protected and one that looks protected on paper?

Who Was in the Room

CISOs
Banking & NBFC
Model Risk Officers
HFCs & PSU Banks
IT Auditors
BFSI
Compliance Officers
Private Banks
AI/ML Engineers
BFSI Technology
Risk Committee Members
Regional Banks

Most attendees were not AI engineers. The majority were risk and audit professionals who are now responsible for overseeing AI systems they didn't build — a function that RBI's AI/ML Circular has made explicit and mandatory.

The Workshop Structure: Four Modules

01

Threat landscape: what attacks look like in BFSI AI

Live demonstration of five attack categories against a simulated BFSI chatbot: prompt injection, indirect injection via RAG retrieval, PII exfiltration, jailbreak attempts targeting financial advice constraints, and system prompt extraction. The point: these aren't theoretical attacks. They work on production-like systems today, and they look different from traditional cybersecurity threats — detection requires BFSI-specific classifiers, not generic content filters.

02

Guardrail design: the three levers that actually matter

Participants worked in groups to design guardrails for a loan document extraction pipeline. The three design levers — coverage (what fraction of the risk surface does the guardrail cover?), false-positive rate (how often does it block legitimate requests?), and latency (can it run in-line without degrading UX?) — turned out to be tighter constraints than most participants expected. A guardrail with 95% coverage at 0.5% FPR at 11.6ms is a very different engineering problem from one that simply blocks "bad-looking" inputs.

03

RBI compliance mapping: what the circular actually requires

Walk-through of RBI's AI/ML Circular (January 2025) and draft eMRM framework (June 2026), focused on what AI security controls are needed to satisfy the specific obligations. The gap most participants hadn't seen before: RBI requires evidence that controls functioned — not just that controls were designed. A guardrail architecture document satisfies the design obligation. A tamper-evident audit log of guardrail events, hash-chained and exportable, satisfies the evidence obligation.

04

Red-team exercise: break your own guardrail

Each group attempted to bypass the guardrail they designed in Module 2. The exercise was intentionally humbling: most guardrails that looked solid in design had at least one bypass route that their designers hadn't anticipated. The goal wasn't to prove that guardrails can be defeated — it was to show what adversarial testing before deployment looks like, and why external red-teaming against a BFSI benchmark (like FinProof) produces more reliable results than internal testing against the team's own assumptions.

Key Takeaways From the Room

  • Most BFSI AI deployments have monitoring but not guardrails — they detect problems after the fact, not prevent them at inference time. Monitoring satisfies logging requirements; guardrails satisfy control requirements.
  • The false-positive rate is a governance problem, not just an engineering problem. A guardrail that fires on 10% of legitimate transactions creates regulatory risk (discrimination, service denial) that may exceed the risk it was designed to reduce. The 0.5% FPR bar exists for a reason.
  • RAG pipelines are a specific attack surface most teams hadn't evaluated. Indirect prompt injection — where malicious instructions are embedded in documents that the RAG retriever returns — bypasses most input-side guardrails entirely. Output-side classification is the only reliable defense.
  • Vendor AI is your risk, not the vendor's. Every participant who managed a vendor-supplied AI system was responsible for its compliance under RBI's framework. Vendor attestations and SOC 2 reports do not satisfy independent validation requirements.
  • Audit evidence is not the same as audit documentation. A policy document and an architecture diagram are documentation. A hash-chained log of every guardrail event, with the specific classification, the input hash, and the timestamp, is evidence. Regulators are starting to ask for the latter.

"The room shifted in Module 3. When we mapped the eMRM requirements to specific evidence types, people realized they had the documentation but not the evidence. That's a gap most participants hadn't articulated before the workshop, but they're now responsible for closing it."

— Workshop facilitator, Zytra Technologies

The Benchmark Question

One of the most common questions from auditors and risk officers: how do you evaluate whether a BFSI AI guardrail is actually good? Not: does it have a policy document? Not: has it passed internal testing? But: how do you know the coverage and false-positive rate claims are accurate?

The honest answer from most vendors is: you don't, unless you run it against an independent benchmark. The FinProof benchmark — Zytra's open BFSI AI safety evaluation suite — exists to address this gap. FinProof tests guardrails against 13 adversarial attack categories drawn from BFSI-specific threat data, with reproducible test methodology that any organization can run. The leaderboard publishes results for any system submitted for evaluation.

For auditors reviewing AI guardrail claims: FinProof results are a more reliable signal than vendor-provided test reports. Independent benchmark performance is harder to inflate than internal testing results.

What Participants Left With

Every participant received a copy of the ASSURE framework — a four-question checklist for evaluating any BFSI AI deployment from a security and governance standpoint:

  1. Coverage: Does this deployment have a guardrail that covers its full risk surface — including RAG retrieval outputs and agentic tool calls — or only direct user inputs?
  2. Evidence: Is there a tamper-evident audit log of guardrail events that can be exported for RBI examination, or only internal monitoring dashboards?
  3. FPR: What is the documented false-positive rate, and has it been validated against BFSI-relevant legitimate traffic (not just adversarial test sets)?
  4. Red-teaming: Has the guardrail been red-teamed against BFSI-specific adversarial prompts, either internally or via an independent benchmark?

These four questions fit on a single page in an audit workpaper. They also map directly to the control evidence requirements in RBI's eMRM framework. A BFSI AI deployment that can answer all four with documented evidence is in a substantially better position than one that can only point to vendor documentation.

About ISACA Chennai Chapter

ISACA Chennai Chapter connects IT audit, risk, and security professionals in Tamil Nadu and the surrounding region. The Chapter's annual conference brings together practitioners from banking, financial services, insurance, and technology — with a focus on practical, exam-relevant content for CISA, CISM, CRISC, and CGEIT certification holders. For more information about ISACA Chennai events and membership: ISACA Chennai Chapter.

Zytra is available to facilitate ASSURE workshops for ISACA chapters, banking associations, and regulatory training programs across India. If your organization is interested in hosting a BFSI AI guardrails lab, contact us.