Compliance Readiness: Controls, Evidence, and Continuous Assurance

Readiness is a continuous control discipline

Strong assurance begins with controls that operate every day. Celestice puts security and privacy requirements into execution and delivery paths, exercises failure cases, retains evidence, assigns owners, and makes remediation visible. That creates a continuously improving control environment customers can evaluate with confidence.

Our program draws on the Trust Services Criteria and relevant NIST, CIS, OWASP, MITRE ATLAS, Cloud Security Alliance, and privacy guidance. Each reference becomes useful when it is connected to a concrete control, a repeatable test, an accountable owner, and dated evidence.

Start with a reviewable control register

Every public and procurement statement should have an owner and a source of evidence. A concise control register records:

• the exact statement being made;
• the system and environment it covers;
• the implemented control supporting it;
• the test, configuration, or record that provides evidence;
• the relevant coverage and customer responsibilities; and
• the date and owner of the last review.

This keeps security communication concrete and useful as information moves between a blog, questionnaire, technical review, and contract. For example, encrypted private object storage in the production AWS design can be connected directly to configuration, deployment, and review evidence.

We apply the same discipline to framework-informed scenarios and assurance mappings. Each NIST, CIS, OWASP, MITRE, or Cloud Security Alliance reference identifies the implemented control, test, evidence, and owner relevant to the requirement. The result is an actionable crosswalk that guides engineering and makes customer reviews faster.

Evidence area one: identity, isolation, and agent authority

The named shared Express, Connections REST and tRPC, Profile, Planning, and Simulation paths validate a requested tenant against memberships in verified identity claims. Least-privilege capabilities distinguish viewing from acting on covered agent paths. Tests exercise missing, malformed, unentitled, and explicit service-role cases. A shared selector and focused service middleware make these checks consistent and reviewable across the protected paths.

For agent workflows, structured contracts carry capability, risk, approval, and audit requirements. Consequential operations can pause for an authorized reviewer, and the most restrictive applicable policy route wins. The workflow record connects the proposal, evidence, policy result, reviewer decision, and outcome.

The corresponding evidence is concrete: authorization and tenant-boundary tests, capability registry changes, approval records, policy decisions, and activity events. This is more defensible than saying “zero trust” without identifying which request is checked, by what component, and with what negative test.

Evidence area two: privacy engineering

The shared agent context path applies a canonical privacy filter before protected text can reach the primary model, context compaction, response evaluation, or model-backed memory extraction. The Director routing call and OpenViking context integration apply the same privacy primitives. Recognized identifiers are redacted or replaced with deterministic, purpose-scoped HMAC pseudonyms; credentials are always redacted.

The control is production fail-closed, covers nested model-bound message fields, and emits counts and policy metadata without the transformed values or internal scope. Tests cover recognized data classes, structured payloads, scoped unlinkability, credential handling, key requirements, and secondary model paths.

HMAC pseudonyms are protected references designed to reduce direct-identifier exposure while preserving limited workflow continuity. Celestice layers this control with data minimization, access controls, provider governance, path inventory, and focused tests so privacy protection does not depend on a single mechanism.

Payment data uses an even narrower collection boundary. Rainlight directs payment- method entry and management to Stripe's hosted billing portal and renders no PAN or CVC fields. Both former Admin API POST paths for manual payment methods return 410. Payment reads use an explicit PAN/CVC-excluding projection, and canonical SQL requires the legacy card_number_enc and card_cvc_enc columns to remain NULL. The projection can still contain personal billing information and application metadata, which remain subject to ordinary privacy controls. A focused regression test checks those UI, route, service, and database properties together. This architecture materially reduces Celestice's payment-data footprint and supports a more focused PCI DSS responsibility model.

Rain also avoids creating a second top-level authentication-secret store. The canonical auth-user schema omits the upstream Supabase password hash and named confirmation, recovery, email-change, and phone-change token fields; an allowlisted internal-sync projection ignores them. Focused tests plus canonical database deployment checks make that boundary reviewable.

Evidence area three: secure software delivery

No single scanner covers a modern application. Celestice uses several forms of automated analysis across the code and infrastructure lifecycle:

• secret scanning for committed credentials;
• static application security testing for code-level weaknesses;
• dependency scanning for known vulnerable packages;
• infrastructure-as-code scanning for unsafe cloud configuration; and
• container scanning for operating-system and packaged component findings.

Useful compliance evidence is a dated result tied to a repository state and release decision. The current gates are specific:

• TruffleHog gates verified secret findings, and Gitleaks gates findings in git history.
• Trivy gates critical repository and image vulnerabilities subject to documented exemptions; Trivy high findings remain advisory.
• Semgrep is pinned to 1.136.0, and push or pull-request delta scans block new ERROR, HIGH, and CRITICAL findings.
• Checkov is pinned to 3.3.12, and explicit baselines gate every new finding across the live Azure Bicep, AWS CloudFormation, service and agent Dockerfile, and Rainshine targets.
• Ecosystem dependency audits remain advisory.

The active Redis Bicep target and CKV_AZURE_171 are explicit scanner exceptions for current parser/preview limitations; they require manual review and are not counted as scanned passes.

A documented Trivy exemption carries a bounded scope, owner, technical rationale, compensating control, and expiry. Checkov baselines keep existing findings visible while validators block regressions and drive the remediation backlog forward.

Repeated scan history demonstrates that the process operates over time. For included targets, validators fail when a new finding appears, a parser fails, coverage is zero, the pinned scanner version drifts, or a fixed finding leaves a stale baseline entry. These artifacts support change management, vulnerability management, accountable remediation, and continuous improvement.

Evidence area four: deployment and infrastructure

Celestice's AWS deployment design uses GitHub Actions OpenID Connect and scoped cloud roles, allowing CI to obtain short-lived credentials rather than storing routine long- lived AWS deployment keys. Trust policies restrict which repository and workflow context can assume a role, and production promotion can retain a separate approval boundary.

Production storage is designed to be private, encrypted, and protected from public access. Network and service roles are scoped to their purpose. Browser-facing responses carry security headers such as Content Security Policy, strict transport security, framing and content-type restrictions, referrer policy, and permissions policy. The edge architecture supports layered traffic filtering, monitoring, and rate protection according to deployment needs.

The AWS security baseline also defines multi-region CloudTrail management-event logging with log-file validation, encrypted private log storage, GuardDuty, Security Hub, IAM Access Analyzer, and configurable VPC flow logs. Deployed-state checks, alert ownership, and review procedures turn that baseline into operating security evidence.

Infrastructure-as-code makes these controls reviewable and testable. A template, deployed-state check, scan result, and deployment log together are stronger evidence than a screenshot. Deployed-state monitoring, configuration-drift detection, and periodic access review keep the implemented environment aligned with that design.

Evidence area five: AI-specific threat testing

Conventional application testing does not cover all agent failure modes. Celestice's threat-model and testing roadmap includes prompt injection, indirect instructions in retrieved content, sensitive-data leakage, excessive agency, cross-tenant access, unsafe tool arguments, memory poisoning, approval bypass, replay, and unbounded resource use.

Each scenario should connect four things: the asset at risk, the enforcing control, the negative test, and the retained result. Current scenario design is informed by OWASP guidance, MITRE ATLAS, and the NIST AI Risk Management Framework. The technique-level evidence mapping connects each applicable threat to a control, owner, negative test, result, and remediation priority. That living matrix makes framework guidance operational rather than decorative.

Evidence area six: disciplined security operations

Code is a large part of the control environment, and disciplined operations make those protections durable. Celestice maintains:

• a current system and data-flow inventory;
• named owners for security, privacy, access, vulnerability, incident, and continuity decisions;
• a data classification and retention schedule;
• joiner, mover, and leaver access procedures with periodic reviews;
• an incident response plan with a tabletop exercise and recorded follow-up actions;
• backup restore tests and recovery objectives;
• a vendor and model-provider inventory with data-use and retention decisions;
• a vulnerability intake path through security.txt; and
• a risk register with owners, target dates, and accepted-risk expirations.

These practices convert security intent into repeatable operating evidence. A tabletop exercise can use a realistic scenario such as leaked deployment credentials, cross-tenant access, or prompt-injected data export. A restore test should record what was restored, when, by whom, and whether the recovery objective was met. An access review should result in actual revocations where access is no longer justified.

Each procedure produces an operating record, such as a completed access review, recovery result, incident exercise, decision log, or remediation ticket. That makes the program concrete for both operators and customer reviewers.

Audit attribution: who did what, and in what capacity

A timestamp and a changed value are not enough for an actionable trail. Celestice records distinguish the kind of actor responsible for each event — a person acting directly, a background service running on a schedule, or an agent operating under delegated authority. That distinction determines the appropriate response. "This record changed at 03:00" is ambiguous; "a scheduled service changed this record at 03:00" tells an investigator the change followed a known automation cadence, while "a person changed this record at 03:00" raises an immediate question about after-hours access.

Records also capture the outcome, not only the attempt. Refused and failed requests remain visible alongside successful ones. A pattern of refusals is often the first signal an investigation looks for — repeated permission denials from a single identity, or a burst of failed operations against a resource that should not be targeted. An audit trail that records only successes hides exactly the activity a security review needs to surface.

Normalized security event export

Organizations consolidate activity from dozens of systems into a central security information and event management (SIEM) platform. That consolidation fails when each source uses its own column names, timestamp formats, and severity semantics.

Celestice provides a unified event projection that presents records from separate underlying stores in one consistent shape. A consumer does not need to know the internal table topology or reconcile differing field names across services. The projection delivers a stable schema — actor kind, action, resource, outcome, and timestamp — ready for ingestion into Splunk, Sentinel, Datadog, or any standards- based collector.

The practical result: Celestice activity can be reviewed, correlated, and alerted on alongside activity in every other system the organization monitors, rather than in a separate console that only one team checks.

Retention under deletion

A deletion request and an audit obligation compete. Erasing a user account is a privacy requirement; preserving the security history that account produced is a compliance requirement. A security history that can be removed by deleting an account is not a security history — it creates a trivial erasure path for a compromised identity.

Celestice resolves this tension by retaining the event record and anonymizing the actor. When an account is deleted, the identifying data (name, email, linked credentials) is removed, but the event itself — action, resource, outcome, timestamp, and actor kind — persists with a non-reversible placeholder. Security investigations, trend analysis, and audit reviews proceed against the full timeline. No identifying data survives, and no security-relevant gap appears.

This is a deliberate design decision, not an implementation artifact. The anonymization boundary is tested: deletion tests verify that identifying fields are absent from retained records, and retention tests verify that event continuity survives account removal.

What a reviewable evidence package can contain

Without publishing sensitive configuration, a customer security review can be supported by a concise package:

1. architecture and data-flow boundaries;
2. a control summary with scope and exclusions;
3. representative CI test and scan evidence;
4. vulnerability and exception handling criteria;
5. privacy-filter design, coverage, layered safeguards, and tests;
6. tenant, capability, risk, approval, and audit-control descriptions;
7. deployment identity and infrastructure-control summaries;
8. incident and vulnerability-reporting contacts; and
9. the date of the evidence and material changes since it was produced.

Sensitive details can be shared under appropriate confidentiality rather than posted publicly. Evidence should be reproducible from current code and operations, not a static packet that survives long after the system changed.

Continuous assurance in practice

Celestice can point to verified-secret and critical-vulnerability gates, Semgrep delta checks, Checkov regression baselines, privacy tests on model-bound paths, short-lived OIDC deployment identity, approval evidence, and framework-informed threat scenarios. Each control has a defined scope, an owner, a meaningful failure test, and evidence a reviewer can inspect.

That is the foundation of continuous assurance: protections operating in the product, tests that keep them from silently regressing, and an evidence trail that supports customer review and increasingly rigorous independent assurance as Celestice grows.

References

• AICPA System and Organization Controls resources
• NIST Cybersecurity Framework 2.0
• CIS Critical Security Controls
• Cloud Security Alliance Cloud Controls Matrix
• PCI Security Standards Council: PCI DSS