Trust + Security During Active Engagements
CISOs do not buy "we promise." They buy documented, scoped, auditable operational practice. This page is the answer to the question every CISO is going to ask anyway: how does NoCode handle credentials, payloads, and access during a live engagement, and what is the cleanup procedure when we are done.
The portability page covers what happens if NoCode goes dark. This page covers what happens while the engagement is live and your data is in motion.
The single largest CISO concern: a managed-service vendor with persistent root access to your AI infrastructure. NoCode does not operate that way. Ever.
NoCode receives scoped credentials with time-limited validity, rotated at engagement end. The role granted is the minimum required for the migration scope agreed at audit time. No root access, no persistent tokens, no shared admin accounts. Credentials expire on a schedule the customer sets.
Provider-agnostic. Compatible with the credential primitives your environment already uses:
If the engagement requires API keys for upstream providers (frontier APIs the customer keeps for complex reasoning), keys live in the customer's existing secret manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, or equivalent on-prem). NoCode reads via scoped role, never copies, never logs.
Keys are referenced by their vault path in our routing config. The plaintext value is never stored on NoCode infrastructure.
The engagement contract includes a written cleanup procedure that executes the moment the contract terminates: scoped role revocation, vault grant removal, audit log export to the customer, NoCode-side credential rotation (so no copy lingers in our memory).
Cleanup is a deliverable, not a courtesy. The audit log of the cleanup is itself a deliverable, signed off by both sides.
The honest split between what NoCode never sees and what NoCode does see for the calibration system to work at all.
Drift simulation runs against telemetry shape, not payload contents. The privacy-preserving monitoring story is the same one documented on the calibration page. None of the three monitoring mechanisms read your data.
Documented, repeatable, deliverable-attached. The same procedure runs whether the engagement ends because the work is finished or because the customer terminated.
Engagement ends (any reason). Cleanup clock starts. Customer's existing IAM controls remain authoritative throughout.
Scoped credentials revoked on the customer's side first. NoCode operational tools confirm 401s on every previously-authorized endpoint. Audit log captured.
Customer revokes vault grants for upstream API keys. NoCode confirms vault read failures from our infrastructure. Routing config redacts vault paths.
Audit log of every revocation step delivered to the customer's security team, alongside the final escrow bundle. Both sides sign off.
Single-operator boutique engagements raise a fair question: what happens if the operator gets hit by a bus? The honest answer is not "we promise we will not." The honest answer is the structural transition every engagement runs through.
Founder-led calibration. Workload audit, rubric build, gold-standard responses, threshold negotiation. Hands-on engineering on every workload that ships. This is the irreplaceable expertise the customer is buying.
Bus-factor exposure during this phase: high. Mitigation: the phase is short, scoped to a single engagement, and produces written deliverables (the rubric, the routing config, the SLA contract) that survive any operator continuity event.
Every manual tuning made during the calibration phase is encoded as a routing rule in human-readable YAML. The rules are versioned, diffed, and shipped in the daily-regenerated escrow bundle. The decisions become artifacts the customer owns, not knowledge that lives only in the operator's head.
Bus-factor exposure during this phase: dropping rapidly. The codification is the answer.
Profile C is the post-codification operating mode. The system runs on the codified rules, falls back to known-good configurations on drift, and auto-credits the customer's invoice on rubric breach. The operator's role narrows to exception handling: model rotations, vendor advisories, drift alerts that exceed the auto-response thresholds.
Bus-factor exposure during this phase: minimal. The codified system runs on rules the customer's own engineers can read in plain YAML and modify if they choose. The escrow bundle (regenerated daily, verified weekly on clean staging) is the continuity guarantee.
The engagement is structured so the bus-factor answer is the same on day 1 and day 365: codified rules + escrow bundle + plain-YAML config.
The boutique high-touch period exists for a reason and lasts a defined number of days. After codification, the customer's infrastructure runs on artifacts they own. This is the structural mechanism, not a "trust us" assertion.
The IAM commitments, payload-retention split, and cleanup procedure documented here are written into the engagement SLA addendum. Your CISO and your legal team see them up front, not after a breach.
Start a Free Audit Read the methodology Continuous Calibration + SLA Portability + off-boarding Back to the main site