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:
- Who is making the request, and for which tenant?
- What is the minimum data this workflow needs?
- What is this agent allowed to read, propose, or change?
- What must be checked before code or infrastructure is deployed?
- 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.
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, orCRITICALfindings. - 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.
“Trust does not come from calling a platform secure. It comes from controls in the execution path, tests that try to break them, and evidence that can be reviewed.”
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, least-privilege capabilities, privacy enforcement on shared model-bound paths, approval-gated agent actions, 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.
