Security for Financial AI: Controls, Boundaries, and Evidence

Financial AI changes the shape of the security problem

Financial software already handles unusually sensitive data. AI adds a second problem: information can move through prompts, tool arguments, retrieved documents, memory, evaluation calls, and agent-to-agent messages rather than one conventional request and response. An agent may also be able to call tools, start a workflow, or propose an action. Protecting only the login page or database is therefore not enough.

Our security model starts with a simple assumption: every additional data path and agent capability is something that must be bounded. We organize the current control set around five questions:

1. Who is making the request, and for which tenant?
2. How does the organization's identity provider connect to Celestice?
3. What is the minimum data this workflow needs?
4. What is this agent allowed to read, propose, or change?
5. What privilege does this workload actually hold at runtime?
6. What must be checked before code or infrastructure is deployed?
7. What evidence will show that the control ran?

This is less dramatic than a “fortress” metaphor, but it is more useful. A serious security program is a collection of explicit boundaries, negative tests, deployment checks, and owned exceptions—not a collection of adjectives.

Layer one: identity, tenant context, and least privilege

Multi-tenant systems fail dangerously when a tenant identifier is treated as ordinary input. On the named shared Express, Connections REST and tRPC, Profile, Planning, and Simulation paths, Celestice resolves tenant selection from verified identity claims and rejects a requested tenant that is not among the actor's memberships. Tests exercise malformed, missing, unentitled, and service-role cases. This is meaningful coverage, not a platform-wide assertion: remaining HTTP, worker, agent, and direct-service ingresses are still being inventoried, and database RLS needs retained deployed-state evidence.

Least privilege continues above the data layer. Capabilities describe what a user, service, or agent may do. Read access does not imply action access; access to one account or workflow does not imply platform-wide authority. Deployment identities are also scoped. CI/CD uses short-lived OpenID Connect credentials and purpose-limited cloud roles instead of treating long-lived cloud keys as a normal deployment method.

These controls reduce blast radius. They do not make identity risk disappear. Access reviews, credential hygiene, revocation, and customer identity configuration remain part of operating the system safely.

Enterprise identity federation

Organizations federate sign-in to their own OIDC identity provider—Okta, Microsoft Entra ID, Google Workspace, or any compliant issuer. When federation is active, Celestice holds no separate password for the federated user. MFA enforced at the organization's provider therefore applies to Celestice without a second enrollment step.

The design separates who a provider is (a connection) from what it may claim. Each connection binds to one or more DNS-verified email domains. An unverified domain cannot route sign-in and cannot connect to an existing account—even if the provider's token contains a matching email claim. Organization placement derives from the verified connection, never from an assertion inside a token that could be replayed or misissued.

Provider groups grant roles only through an explicit configured mapping. Role mapping applies at account creation, not on every sign-in: a role granted directly in Celestice is never silently reverted by a stale group claim arriving on the next authentication. This gives organizations full control over their identity lifecycle while keeping the platform's authorization state deterministic and auditable.

Layer two: minimize model-bound data

Celestice now applies a canonical privacy filter to shared agent context preparation. Recognized direct identifiers and credentials are transformed before the protected context can reach the main model, context summarization, response evaluation, or model-backed memory extraction on that shared path. The filter covers message text, structured content, tool arguments, and artifacts rather than assuming sensitive data only appears in the visible prompt.

The safe default is redaction. Where a workflow needs stable references, purpose-scoped pseudonyms let the system preserve continuity without putting the raw identifier in model-bound text. Credentials are always redacted. The control fails closed in production if enforcement is disabled or pseudonymization is configured without adequate key material.

Pseudonymization is not anonymization. A pseudonymized record remains personal data when it can be related back to a person using additional information. Pattern-based classification also cannot recognize every identifier, image, document format, or free-form disclosure. For those reasons, we describe this as a material exposure- reduction control—not as proof that no personal data can ever reach a model provider.

Payment data: remove the application path

For payment credentials, the strongest data-minimization control is not collecting them. Rainlight directs payment-method management to Stripe's hosted billing portal and renders no primary account number (PAN) or CVC fields. Both former Admin API routes for manually adding a payment method now return 410 provider_managed_payment_methods.

Payment-method reads use an explicit PAN/CVC-excluding projection rather than fetching a complete historical row and removing card credentials afterward. The projection can still contain personal billing data such as cardholder name, billing address, and application metadata, so normal authorization, minimization, and retention controls remain necessary. At the database boundary, a canonical CHECK constraint requires the legacy card_number_enc and card_cvc_enc compatibility columns to remain NULL. A focused regression test asserts the UI, API, service projection, and database invariant together.

This materially reduces Celestice's payment-data surface and can narrow applicable PCI DSS scope. It does not establish PCI DSS compliance or transfer every responsibility to Stripe. Hosted-page configuration, scripts, webhooks, access control, incident response, and the applicable assessment scope still require review.

Layer three: govern the agent, not only the model

Prompt security matters, but an agent's ability to act matters more. Celestice uses structured contracts around agent capabilities, risk, approval, and audit evidence. Those contracts answer questions that a prompt alone cannot reliably answer:

• Which tools and data scopes may this agent use?
• Is the proposed operation low, moderate, high, or critical risk?
• Which actions must pause for an authorized reviewer?
• What source data, policy checks, and assumptions support the proposal?
• What decision and execution events must be recorded?

The most restrictive applicable rule wins. A permissive route cannot silently bypass a stronger approval requirement. Consequential operations can be held for human review, and the resulting decision is attached to the workflow record. This gives operators a defensible chain from input and policy to recommendation, approval, and outcome.

Current tests exercise tenant, capability, privacy, and approval boundaries. The security program expands that evidence across prompt injection, unsafe tools, approval bypass, memory poisoning, and other agent scenarios, cross-checked against relevant OWASP and MITRE ATLAS concepts. The resulting matrix connects threats to named controls, negative tests, owners, results, and remediation priorities.

Layer four: make secure delivery repeatable

Application controls are only useful if a release cannot casually route around them. Celestice's delivery process uses complementary scanners because they answer different questions:

• Secret scanning looks for credentials committed to source.
• Static application security testing looks for unsafe code patterns.
• Dependency scanning checks known vulnerabilities in third-party packages.
• Infrastructure-as-code scanning checks cloud and deployment configuration.
• Container scanning checks operating-system and packaged component findings.

The enforcement mode is explicit:

• Secrets: TruffleHog gates verified secrets, while pinned Gitleaks scans git history and fails on detected findings.
• Repository and images: Trivy reports high and critical vulnerabilities and gates critical results, subject to reviewed, documented exemptions. High results remain advisory remediation work.
• Application code: pinned Semgrep 1.136.0 uses push and pull-request delta scans to block new ERROR, HIGH, or CRITICAL findings.
• Infrastructure and containers: pinned Checkov 3.3.12 compares live Azure Bicep, AWS CloudFormation, service and agent Dockerfiles, and Rainshine against explicit baselines. Any new finding fails CI.
• Dependencies: ecosystem dependency-audit results remain advisory.

Special parser cases receive documented manual review alongside the automated gates. The baselines preserve visibility into existing findings while blocking regressions. Checkov validation also fails on parse errors, zero scanned resources, version drift, or stale baseline entries within the included scope.

In the deployment design, private encrypted storage and blocked public access reduce accidental exposure. The marketing surface now sends Content Security Policy, transport security, framing restrictions, content-type protection, referrer policy, permissions policy, and cross-origin headers. These reduce common browser attack paths, while the edge architecture supports layered traffic filtering, monitoring, and rate protection according to deployment needs.

The AWS security baseline defines a multi-region management-event trail with log-file validation, encrypted private security-log storage, GuardDuty, Security Hub, IAM Access Analyzer, and configurable private-subnet flow logs. These detective controls improve visibility; they are not described as immutable WORM records, and an alert only helps when its deployed state, routing, and owner are periodically verified.

Workload isolation and scoped service identity

Delivery controls gate what reaches production. Workload isolation controls what that code can do once it runs.

Each workload operates under explicit privilege constraints. Those constraints are verified against the rendered deployment output—the actual resource definitions a deployment produces—rather than the source templates. A template variable that resolves to an overly permissive value is caught at the artifact that would ship, not at the abstraction that hides it.

Network egress is constrained by policy. A workload that processes client portfolio data does not hold a path to arbitrary internet endpoints; its reachable destinations are declared and enforced at the network layer.

Automated components—background workers, scheduled jobs, agent tool executors—authenticate as narrowly scoped service identities. Each identity holds only the data access its code paths require. Row-level policy provides an additional boundary: even a valid service credential cannot read rows belonging to an unrelated tenant or workflow. The combination of grant-level and row-level policy means a compromised workload's blast radius is bounded by design, not only by monitoring.

Layer five: preserve evidence and strengthen assurance

A useful control should produce reviewable evidence: a test result, scan artifact, deployment identity, configuration state, approval, or event. We preserve non-sensitive privacy-filter counts and policy versions without logging the values that were transformed. Agent workflows preserve capability, risk, approval, and activity data. Delivery jobs preserve which checks ran and which artifact was evaluated.

That evidence supports efficient customer reviews, accountable operations, and future independent assurance. Framework-informed scenarios connect NIST, OWASP, MITRE, and other guidance to named controls and tests, while provider evidence strengthens the shared-responsibility picture at the infrastructure layer.

Celestice provides controls and evidence that help customers address requirements shaped by their role, jurisdiction, configuration, contracts, and operating procedures. Clear scope and ownership make that evidence more useful to security, privacy, compliance, and procurement teams.

The takeaway

Our security position is built on concrete controls: membership-checked tenant selection on named services, federated identity with DNS-verified domain binding, least-privilege capabilities, privacy enforcement on shared model-bound paths, approval-gated agent actions, workload-scoped service identities bounded by row-level policy, multiple forms of scanning, short-lived deployment identity, private encrypted storage, browser protections, and targeted negative tests.

Continuous improvement keeps those protections current. Every control is connected to a meaningful failure test and evidence a reviewer can inspect.

References

• NIST Cybersecurity Framework 2.0
• NIST Privacy Framework
• CISA Secure by Design
• OWASP Application Security Verification Standard
• PCI Security Standards Council: PCI DSS