The FinServ AI Tool Problem

Financial services firms are fast adopters of developer tools. Bloomberg terminals, proprietary trading systems, and algorithmic execution platforms represent decades of sophisticated engineering. FinServ engineering teams are experienced, well-resourced, and under constant productivity pressure.

When AI coding tools became available, FinServ developers adopted them quickly. The challenge: the same features that make AI tools productive (large context windows, code completion, architecture suggestions) make them significant IP and compliance risks in a regulated industry.

What Is Actually at Risk

Proprietary Trading Algorithms

A quantitative strategy expressed in code represents years of research and real competitive advantage. The function names, variable names, and structural patterns in a trading algorithm are themselves proprietary information, independent of the underlying data.

If a developer pastes 500 lines of execution logic into a Claude prompt to ask about optimization, those 500 lines include the logic of the strategy. That logic is now in Anthropic's infrastructure.

Client Data Patterns

Financial services code often handles account identifiers, transaction patterns, and portfolio structures. Even schema definitions and type annotations reference client-identifiable patterns. A data model file for a wealth management system contains identifiers like AccountHolder, PortfolioBalance, and TaxLotEntry that, in aggregate, describe client data structures.

Regulatory Algorithms

Anti-money laundering detection logic, credit scoring models, and fraud detection patterns represent both IP and regulatory documentation. These algorithms are often confidential for competitive reasons and also because their disclosure could enable evasion.

The Regulatory Landscape

SOX (Sarbanes-Oxley)

SOX Section 404 requires effective internal controls over financial reporting. For technology firms and firms where technology enables financial reporting, auditors are increasingly examining access controls over the systems that generate financial data. AI tool usage that exposes those systems' internal logic is a SOX risk for public companies.

MiFID II / Market Regulation

Firms subject to MiFID II have obligations around algorithmic trading systems including documentation and change management. Sending algorithmic trading logic to AI APIs calls for audit controls; with them in place, the change management record stays complete.

FINRA and SEC Rules

FINRA and SEC rules on data security and privacy apply to client information, which can include data patterns that appear in code. The question of whether identifiers in source code constitute "client data" is fact-specific, and the conservative approach is to treat them as potentially covered.

How Leading FinServ Teams Are Handling This

Pattern 1: Tiered Access by Repository Classification

Teams classify repositories by sensitivity level:

• -Public tier: Open source libraries, developer tooling, non-proprietary infrastructure code. Unrestricted AI tool use.
• -Internal tier: Business logic free of client data and trading algorithms. AI tools allowed with audit logging.
• -Restricted tier: Proprietary trading algorithms, client data models, regulatory systems. AI tools only through mutation proxy.
• -Confidential tier: Highest-value strategies, real-time trading systems. AI tools disabled entirely.

This approach lets developers use AI tools productively on most code while applying strict controls where they matter.

Pattern 2: Mutation Proxy in CI/CD Pipeline

Going beyond per-developer proxy configuration, some teams deploy Pretense as a required component of the development pipeline. The CI/CD system validates that commits touching restricted repositories were made with Pretense active.

# .github/workflows/ai-security-gate.yml
name: AI Security Gate
on: [push, pull_request]
jobs:
  check-ai-controls:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pretense/scan-action@v1
        with:
          fail-on: high
          repositories: restricted,confidential
          report: pr-comment

This approach enforces the control at the pipeline level, above any individual developer's setup.

Pattern 3: Audit Trail for Compliance Reviews

Several firms use Pretense primarily for the audit artifact, with protection as a second benefit. The reasoning: whatever the limits of any single technical protection, a complete log of what AI API calls were made, from which repositories, with which mutation records, satisfies the auditor's question about control documentation.

The audit log generated by Pretense includes enough information to answer: what code was sent, when, by whom, whether proprietary identifiers were mutated, and whether any secrets were detected and swapped for stand-ins.

Technical Implementation for FinServ Environments

FinServ environments have specific requirements that go beyond a standard developer tool deployment.

Air-gapped or restricted network environments

Some trading systems run on restricted or fully offline networks. Pretense can be configured for fully air-gapped operation:

pretense init
pretense airgap on

In air-gap mode, Pretense refuses every upstream that is not on the machine, so prompts only reach a local model. Mutation and the audit log stay on the developer workstation. Air-gap mode is an Enterprise feature.

SIEM integration

FinServ security teams typically want AI tool events flowing into their SIEM alongside other security events. SIEM forwarding is an Enterprise item. On any plan, the CLI exports the audit log as JSONL, which your existing log forwarder can ship to Splunk or Sentinel:

pretense audit --json --limit 100000 > pretense-audit.jsonl

SSO and identity management

Enterprise deployments can integrate with existing SSO providers through BoxyHQ SCIM integration, so audit logs are attributed to authenticated identities, a step up from local user accounts.

A Note on "Developer Productivity vs Security"

The framing of productivity versus security is a false choice in this context. Developers at FinServ firms are already working around security controls when those controls are too burdensome. The more accurate framing is: controls that developers work with versus controls that developers work around.

A control that adds 2-8ms of latency and is completely invisible in normal workflow is one developers keep using. A control that requires manual review of every prompt, adds 2-5 minutes per AI interaction, and generates friction on deadline is one that will have informal exceptions within weeks.

The goal is a control that achieves the security objective and that developers can live with indefinitely.

How I run Pretense on my own code

I build Pretense with Claude Code, and my sessions run through it. Here is the setup I give a new engineer, in order.

1. -Run the agent through the proxy. Type pretense run claude where you would type claude. It starts a local proxy on port 9339, points Claude Code at it and stops the proxy when the session ends. Detected secrets and PII leave the laptop as stand-in tokens.
2. -Put hooks on every repo. pretense install adds a pre-commit and a pre-push hook. A key that never lands in git is a key an agent never reads.
3. -Scan before an agent reads the repo. pretense scan path . lists what it finds. In CI, pretense scan ci exits 0 when clean, 2 on findings and 3 when it examined nothing. Treat 3 as a failure.
4. -Preview the swap. pretense review . shows what would be mutated. pretense mutate <file> --preview prints one file mutated and leaves the file on disk as it was.
5. -Round-trip a file you need to share. pretense mutate <file> --map <map> swaps the secrets in place. pretense reverse <file> --map <map> turns it back into the original, byte for byte, from the encrypted map on your machine. We run that round trip on real files before every CLI release and compare sha256 hashes.

One thing I learned the hard way: inside a session the agent sees stand-ins, so a file the agent writes can hold a stand-in where you expected a real value. Grep what the agent wrote before you ship it.

What Pretense will not do is put a secret back into the model's answer. Code identifiers come back byte-exact. Secrets and PII stay as stand-ins in the response. That is deliberate: a prompt-injected model can echo a token into a link, and reversing it there would hand over the real key.

What this means if you own compliance

The outcome: a technical control for AI coding tools that you can show an auditor. Pretense helps with SOC 2, HIPAA, PCI DSS and GDPR evidence. It maps to controls. It does not certify you.

• -Pin the preset you report against. pretense scan path . --policy soc2 applies that framework's detectors. SOC 2 and PCI presets come with Startup. HIPAA, GDPR and NIST presets come with Enterprise.
• -Export the evidence. pretense audit --format csv --framework HIPAA writes the events that map to HIPAA. Attach the file to the control with the date range you sampled.
• -Test detection on your own data. Coverage varies by data type. Run pretense review . on a regulated repo, read the result and record the gaps in your risk assessment.
• -Keep the policy and the control in step. Your AI tool policy says what engineers may send. pretense run claude and the git hooks are how you show it happens.

Try it on your own repo: create a free account, then run npm i -g @pretense/cli and pretense run claude. If you need a security review first, talk to me.