Celestice combines privacy engineering, verified access, governed agent actions, secure software delivery, and threat-informed testing. These layers protect financial workflows while producing evidence customers and security teams can review with confidence.
Implemented
The control operates in code, configuration, or a defined procedure.
Tested
Automated or repeatable evidence exercises the control and its failure cases.
Framework-informed
Leading guidance structures threat scenarios, control tests, evidence, and priorities.
Provider control
A trusted cloud or service provider operates the control within its service boundary.
Implemented · Tested
Shared agent paths redact credentials and transform recognized direct identifiers through redaction or purpose-scoped HMAC pseudonyms before protected model and memory calls. Content-free reports record what the policy transformed without copying the values.
Implemented · Tested
Secret, source, dependency, container, and infrastructure checks run throughout delivery. Verified gates stop defined regressions, while dated evidence and explicit baselines keep remediation visible and accountable.
Implemented · Tested
Agent tools carry permissions, risk levels, tenant scope, approval modes, and audit records. Consequential workflows can pause for human approval, and context and handoffs preserve the authority of the originating request.
Implemented · Tested
Organizations federate sign-in to their own identity provider over OIDC. A connection identifies the provider, DNS-verified domains define what it may claim, and organization placement derives from the verified connection rather than from anything asserted in a token.
Implemented · Tested
Authenticated services derive organization scope from verified identity claims and validate requested tenant selectors against membership. Capabilities and row-level controls add independent layers around sensitive financial data.
Implemented · Tested
Workloads run with explicit privilege constraints and constrained network egress. Automated components authenticate as narrowly scoped identities holding only the data access their code paths require, bounded by row-level policy as well as by grant.
Implemented · Provider control
Deployment uses short-lived OIDC credentials, scoped roles, private encrypted storage, HTTPS-only delivery, browser security headers, and layered cloud monitoring and detection controls.
Tested · Framework-informed
Threat scenarios and controls are organized with NIST, OWASP, CIS, MITRE ATLAS, Cloud Security Alliance, and Trust Services guidance, connecting each priority to owners, tests, evidence, and remediation.
Celestice treats security as a system property spanning requests, models, tools, data, software delivery, infrastructure, and operations.
Remove direct identifiers and secrets when the financial task does not need them.
Establish tenant, role, and capability from authenticated context—not from prompts or model output.
Let agents prepare and recommend while policy and approval controls govern consequential action.
Combine authorization, privacy filtering, storage, delivery, edge, and operating controls.
Exercise malformed, missing, cross-scope, nested, and adversarial cases—not only the happy path.
Prove a control ran through content-free results tied to the relevant code or deployment.
Celestice validates selected tenant context against memberships in verified identity claims across shared authenticated services. A tenant selector chooses among authorized contexts; it does not grant membership.
Shared agent context paths preserve the financial facts needed for analysis while transforming recognized direct identifiers before primary, compaction, evaluation, and model-backed memory calls. Credentials are always redacted.
Optional HMAC pseudonyms are stable only inside a narrow environment, purpose, agent, and subject scope. The same value produces a different reference in unrelated contexts, reducing unintended correlation while preserving limited workflow continuity.
Pseudonymized information remains protected personal data and is layered with authorization, encryption, retention, deletion, and provider governance.
Organizations federate sign-in to Okta, Microsoft Entra ID, Google Workspace, or any OIDC provider, so account lifecycle and multi-factor enforcement stay where they are already managed. Celestice never holds a separate password for a federated user.
Federation separates who a provider is from what it may claim. That separation is what allows the strongest control on this page: an organization’s provider speaks only for domains it has proven it controls, and for no one else’s.
A provider may authenticate only email domains the organization has proven it controls through a published DNS record. An unverified domain does not route sign-in and cannot connect to an existing account.
Placement derives from the configured connection, never from a claim inside a token. A token asserting a different organization still resolves to the one the connection names.
Provider groups grant roles only through a configured mapping, so a provider cannot select local authority by naming a group. A default role is always applied, so no account arrives without one.
Group mapping applies at account creation rather than on every sign-in, so a role granted directly in Celestice is not silently reverted when the user authenticates again.
Validation of a provider assertion covers signature against published keys, issuer, audience, expiry, nonce binding to the originating request, and subject presence—each exercised by tests that are verified to fail when the check is removed.
Consequential activity remains attributable. Records carry the initiating identity, organization and capability context, the policy decision that applied, the approval or rejection, and the outcome.
Records distinguish a person from a background service from an agent operating under delegated authority—the distinction that makes a trail actionable rather than merely present.
Refused and failed requests are recorded alongside successful ones, because a pattern of refusals is what an investigation looks for first.
A unified projection presents records in one shape for ingestion into an organization’s own monitoring, so Celestice activity is reviewed alongside everything else rather than in isolation.
Deletion removes the identifying link to a user while preserving the record that an event occurred, so security history cannot be erased by removing an account.
Privacy controls follow the data through its purpose, processing, retention, rights, and provider lifecycle—not only the moment it reaches a model.
Classify data by source, sensitivity, tenant, location, recipient, owner, and intended use before introducing a new connector or tool.
Collect only what a workflow needs, then apply scoped access, pseudonymization, encryption, provider boundaries, and controlled exports.
Connect retention to purpose and obligations, and design deletion across primary records, indexes, caches, memories, logs, backups, and providers. Where deletion meets an audit obligation, the event is retained and the identifying link to the person is removed.
Authenticate requests, preserve tenant separation, coordinate relevant systems, and retain content-free evidence of the resulting action.
Stripe-hosted surfaces handle payment-method entry and management. Celestice forms do not render PAN or CVC fields, reads exclude those fields, and database invariants keep legacy card-credential columns null.
Browser-facing integration routes do not accept OAuth access, refresh, or ID tokens. Connection lifecycle responses use explicit safe-metadata projections rather than returning credential-bearing records.
The application user schema and allowlisted sync projection exclude Supabase password hashes and named confirmation, recovery, email-change, and phone-change tokens.
Celestice keeps consequence decisions outside generated text. Routine analysis can move efficiently, while higher-impact actions follow explicit risk, policy, and human-approval paths.
Defines the tools, data scopes, and operation classes available to the actor.
Classifies the consequence of the proposed action and selects the protective path.
Binds an authorized reviewer to the exact action and supporting evidence.
Preserves the source, policy, decision, execution, and result lineage.
Results are tied to repository state and release decisions. Explicit baselines preserve existing work, block regressions in defined scopes, and retire entries as fixes land.
TruffleHog gates verified secrets, while Gitleaks checks repository history.
Pinned Semgrep delta scans block new ERROR, HIGH, and CRITICAL findings.
Trivy identifies high and critical vulnerabilities and gates defined critical findings with reviewed exception handling.
Pinned Checkov scans active cloud and Dockerfile targets, with explicit baselines that block new findings.
Workflows validate scanner versions, parser success, target coverage, baselines, and evidence generation.
Scenarios connect the asset at risk, enforcing control, negative test, and retained result. Tests look for concrete outcomes such as denied capability, protected data, held approval, no side effect, and bounded resource use.
Celestice uses NIST Cybersecurity and Privacy Frameworks, NIST AI RMF, OWASP application and generative-AI guidance, CIS Controls, MITRE ATLAS, Cloud Security Alliance CCM, and Trust Services guidance to structure risks and priorities.
Requirement- and technique-level mappings connect applicable guidance to the named control, owner, test, result, and remediation priority. That makes the framework useful to engineering teams and customer reviewers alike.
Celestice builds a reviewable operating history through control ownership, repeatable tests, security findings, approval records, access reviews, incident exercises, recovery evidence, and managed exceptions.
The named service, environment, tenant boundary, repository, or model path.
The protection being enforced and its intended outcome.
The code, workflow, configuration, template, or procedure.
The unit, integration, adversarial, scan, or deployed-state exercise.
Dated evidence tied to a revision, artifact, or deployment.
The owner, priority, compensating control, target date, and review point.
Architecture boundaries, control summaries, representative test and scan evidence, privacy design, agent governance, deployment protections, and current remediation records support customer due diligence.
Start a security conversationSend a concise description, affected surface, reproduction steps, and impact to support@celestice.com. Please avoid accessing other users' data, disrupting service, or including sensitive data in the initial report.
View security.txt
The new code for old wealth.
