From my experience working on financial systems, PII leaks rarely happen because someone intentionally exposed sensitive data. Most of the time they come from ordinary engineering decisions made during development that aren’t caught by code reviews. For example, a developer catches an exception from a third-party API and logs the response payload for troubleshooting. Or an entire object gets serialized because it is easier than identifying the one field actually needed for debugging.
Most organizations already have downstream protections in place: masking layers, redaction rules, log filtering, SIEM detection, retention policies. Those controls matter, and you absolutely want them. But they also assume sensitive data has already entered the system somewhere along the way. That’s what led me to start thinking more about whether AI agents could become another defensive layer earlier in the development lifecycle.
Specifically, I used Claude to help construct a review agent focused on identifying areas where PII leaks could potentially occur inside the codebase. The requirements were fairly straightforward: review application code for patterns where identity or financial data could accidentally be exposed.
What surprised me was not that it found issues. Static analysis tooling already exists for that. What surprised me was how effectively it identified the exact categories of problems that repeatedly show up in financial applications, particularly around exception handling and third-party integrations.
One of the most common patterns it flagged was broad exception logging around external APIs. That pattern exists everywhere. A third-party system throws an exception, the application catches it, and the full response gets logged for troubleshooting. The problem is that many third-party responses contain far more sensitive information than developers realize. In payment systems, onboarding flows, or identity verification platforms, logging the exception often means logging customer data alongside it.
The agent consistently identified those paths as high-risk areas with very little guidance.
It also surfaced findings that were technically correct even when they were acceptable in my current development environment. In several places it identified APIs that were effectively unsecured. In context, I knew exactly why those endpoints were open during development. But honestly, that is almost beside the point. In a production review, those are precisely the kinds of findings you would want surfaced immediately.
That’s what I find interesting about using AI this way. The value is not perfect accuracy. The value is earlier visibility.
Security has always worked best as multiple defensive layers rather than a single control point. Input validation matters. Log filtering matters. Access controls matter. Monitoring matters. AI agents do not replace any of those systems. They become another layer operating earlier in the development lifecycle before risky patterns become normalized and before unsafe code reaches production.
What makes this more practical is that these agents do not need to operate as isolated review tools. They can be integrated directly into the development workflow itself. For example, running the review agent through a Claude hook before pull request creation creates another lightweight enforcement layer that evaluates risky patterns before code review even begins.
For years, “shift left” security has mostly meant adding more enforcement gates into CI/CD pipelines. More scanners. More policy checks. More things developers need to satisfy before merging code. What AI introduces is slightly different. It creates the possibility of continuously reviewing engineering intent while the code is still being written.
In systems handling financial or customer data, earlier visibility is often the difference between prevention and cleanup.