Building a PII-Safe Agentic Architecture for BFSI on AWS Serverless
A reference architecture for running AI agents on banking data without leaking PII — guardrails at ingress, redact-before-reason, VPC-only model calls, and an audit trail that survives an RBI inspection.
A PII-safe agentic architecture is an AI-agent system designed so that no unmasked personally identifiable information ever enters a model prompt, a tool call, or a log line unless a named, auditable control explicitly allows it for that step. For a bank or NBFC, it is the difference between an agent programme a regulator can approve and one it can shut down.
Every bank we talk to wants agents. Loan-file summarisation, KYC document triage, relationship-manager copilots — the use cases are obvious and the models are ready. What is not ready, at most institutions, is the answer to one question a regulator will eventually ask: when your agent called a model, what customer data left your perimeter, and can you prove it?
An agentic workflow is not one model call. It is a loop — plan, call a tool, read the output, plan again — often dozens of steps for a single request, and every step is a fresh opportunity for an account number or an Aadhaar-linked detail to ride along in a prompt, a tool response, or a log line. Bolting a redaction filter onto the front of that loop protects exactly one of those steps.
This post is the reference architecture we use to protect all of them, built entirely on AWS serverless primitives.
Key takeaways
- Agent loops multiply PII leak paths: prompt assembly, tool round-trips, model-side memory, and observability logs all carry customer data
- The core principle is redact-before-reason: models reason over tokens, and only a separately-permissioned rendering step may resolve them
- Amazon Bedrock Guardrails handles ingress/egress PII detection, and its 2026 detect-only API lets each agent step run a different safeguard set
- PrivateLink-only inference plus per-domain KMS keys keeps the whole path inside your VPC — the fact that turns "no LLMs" into a negotiable posture
- India's DPDP Act 2023 covers every automated step that touches personal data, with penalties up to ₹250 crore per contravention
Why agents change the PII threat model
A traditional application leaks PII in predictable places: the database, the API response, the log. An agent adds four new leak paths that most security reviews have never had to think about:
- Prompt assembly — the orchestrator stuffs retrieved documents into context, and nobody reviews what the retriever returned
- Tool round-trips — a CRM lookup returns the full customer record when the agent needed one field
- Model-side memory — conversation history accumulates identifiers turn by turn
- Observability — traces and step logs faithfully record every prompt, PII included
The reference architecture
The design principle is simple to state: redact before you reason. No token of unmasked PII enters a model context, a tool call, or a log line unless a named control explicitly allows it for that step.
1. Guardrails at ingress and egress
Amazon Bedrock Guardrails detects and redacts PII in both user inputs and model responses — predefined types (names, account numbers, addresses) plus custom regex types for domain identifiers like PAN, CIF, or IFSC-linked strings. AWS reports up to 99% accuracy on its automated reasoning checks for policy enforcement. Since mid-2026 the InvokeGuardrailChecks API also runs in detect-only mode, so multi-step agent loops can apply *different* safeguard sets per step instead of one blunt filter for the whole workflow.
2. Redact-before-reason in the orchestrator
Guardrails are the safety net, not the strategy. The orchestrating Lambda tokenises PII *before* prompt assembly — the model reasons over {{CUSTOMER_7f3a}}, and only the response-rendering step, with its own IAM identity, may resolve tokens back. A minimal shape:
// Orchestrator step: tokenise before the model ever sees the record.const { redactedText, vault } = await redactPii(customerRecord, {types: ["NAME", "PHONE", "AADHAAR", "ACCOUNT_NUMBER", "PAN"],strategy: "token", // reversible only via the vault, never inline});const plan = await invokeAgent({context: redactedText, // models reason over tokenstools: scopedTools(caller), // least-privilege per step});// Only the renderer role can resolve tokens — never the agent loop.return resolveTokens(plan.response, vault, rendererRole);
3. The perimeter itself
| Layer | AWS building block | What it enforces |
|---|---|---|
| Model access | Bedrock via VPC endpoint (PrivateLink) | Inference traffic never crosses the public internet |
| Keys | KMS with per-domain CMKs | Tokenisation vault and data stores encrypted under separate keys |
| Tools | Lambda + scoped IAM roles | Each agent tool sees the minimum fields for its one job |
| State | DynamoDB + S3, SSE-KMS | Conversation state stored redacted, resolved only at render |
| Audit | CloudTrail + structured step logs | Every step records *that* PII was touched, never the PII itself |
Bedrock does not train base models on your data, and with PrivateLink the whole inference path stays inside your VPC — which is the fact that turns a "no LLMs" security posture into a negotiable one.
Mapping it to the regulators you actually face
Three regimes shape this architecture in practice:
- DPDP Act 2023 — consent, purpose limitation, and breach notification apply to every automated step that touches personal data; the redact-before-reason pattern keeps most steps outside "personal data" entirely
- RBI's data localisation mandate (2018 circular) — payment-system data stays in India, which for us means Mumbai-region-pinned storage and inference endpoints for payment-adjacent workloads
- UK GDPR / FCA expectations — for UK lending workflows, the same tokenisation pattern satisfies data-minimisation, and human review gates on adverse decisions map to explainability expectations
The audit trail is the product. A bank does not buy an agent that answers correctly; it buys an agent whose every answer it can defend eighteen months later.
What building this taught us
We are applying this architecture in AgenBTL, our commercial-lending agent platform currently in active development — eight specialised agents where consent-first data handling and FCA, PECR, MCOB and UK GDPR enforcement are constraints in the planner, not filters bolted on after. Running our own build under ISO/IEC 27001-certified controls is where most of the sharp edges in this post were found.
Frequently asked questions
Can we run LLM agents on customer data without violating the DPDP Act?
Yes, if every automated step that touches personal data is covered by consent and purpose limitation — and the redact-before-reason pattern shrinks that surface dramatically, because steps that only ever see tokens are not processing personal data at all. The failure mode is not the model call; it is the unreviewed retriever output and the raw prompt in your logs.
Does Amazon Bedrock send our data outside our AWS account?
No. Bedrock does not use customer data to train base models, and with a VPC endpoint via AWS PrivateLink the inference path never crosses the public internet. Encryption in transit and at rest with your own KMS keys completes the boundary.
Where should a bank start if agents are already in a proof of concept?
Run Bedrock Guardrails in detect-only mode in front of the existing endpoint for two weeks. The resulting report of would-be redactions is an evidence-based measure of current PII exposure, and it usually reframes the security conversation from "whether" to "which controls, in which order".
Talk to the engineers who build this
If you are putting agents anywhere near customer data, a one-hour architecture review now is cheaper than a remediation programme later. We will walk your team through this reference design against your actual stack — book a technical architecture review, or talk to us about where PII risk is hiding in your agent loop.