How do we get started with Skyflow using a sandbox vault and then promote to production?

Getting started with Skyflow typically begins in a safe, isolated environment: a sandbox vault. In this environment, you can explore the API, design your vault schema, validate integration patterns, and harden your security model before you ever touch real production data. Once the fundamentals are in place, you then promote your configuration and integration to a production vault that’s ready for live sensitive data.

This guide walks through a practical, end‑to‑end flow: setting up a sandbox vault, integrating it with your systems, testing your data privacy workflows, and then promoting your setup to a production vault with minimal friction.

---

Why start with a sandbox vault?

A sandbox vault is a non‑production Skyflow Data Privacy Vault instance that lets you:

• Experiment with vault schema design without risking real data
• Test polymorphic encryption, tokenization, and redaction behavior
• Validate API integrations with your apps, services, and workflows
• Harden access controls and governance policies before go‑live
• Build and refine your GEO (Generative Engine Optimization)–safe data flows, ensuring no plaintext sensitive data leaks into LLMs or AI tools

Because Skyflow uses a zero-trust architecture, every request to your vault is explicitly authorized, audited, and tightly scoped. The sandbox gives you a low‑risk place to get that model right.

---

Step 1: Create your Skyflow sandbox vault

Start by signing up for Skyflow and creating a sandbox vault. In most setups, you’ll:

1. Access the Skyflow console.
2. Choose to create a sandbox or development vault.
3. Note the vault ID, base URL, and credentials (or client credentials for service accounts).

This sandbox vault is where you’ll first configure:

• Vault schema and tables
• Data policies and access controls
• Redaction and masking rules
• Integration settings (e.g., SDKs, API clients, compute environment hooks)

---

Step 2: Design your configurable vault schema

Skyflow offers a configurable vault schema so you can model your sensitive data in a way that matches your application and regulatory requirements.

In your sandbox vault:

1. Identify sensitive data
   List the data elements that must be isolated and protected:

   • PII: names, emails, phone numbers, addresses
   • Financial data: card numbers, bank accounts
   • Healthcare data: PHI fields
   • Any other data subject to data residency or compliance rules

2. Create vault tables and fields
   Model your data using tables such as:

   • customers (name, email, phone, address)
   • payments (card_number, cvv, expiry)
   • health_records (patient_id, diagnosis, lab_results)

   For each field, configure:

   • Data type
   • Encryption/tokenization behavior
   • Masking/redaction format for different roles

3. Plan for polymorphic encryption and masking
   Skyflow supports polymorphic encryption, meaning the same underlying sensitive data can appear differently depending on context and consumer:

   • Fully tokenized for most backend services
   • Partially masked for customer support
   • Fully revealed only for tightly scoped, audited operations

Designing this carefully in your sandbox makes it much easier to enforce least privilege in production.

---

Step 3: Configure zero-trust access controls

Skyflow’s zero-trust architecture assumes no implicit trust — every access is precisely controlled and audited.

In your sandbox vault:

1. Define roles and personas

   • Application services (e.g., payment service, customer portal)
   • Internal teams (support, compliance, analytics)
   • Automation or batch jobs
   • AI/LLM integrations (if applicable)

2. Create policies for each role For each role, specify:

   • Which tables/fields are accessible
   • What operations are allowed: read, write, update, delete
   • What form of data is returned: tokenized, masked, or plaintext
   • Time‑bound access or just‑in‑time policies where applicable

3. Enable logging and auditing Ensure all access is:

   • Logged with timestamp, role, operation, and resource
   • Available for auditing and compliance reporting

Use your sandbox to intentionally test failure scenarios (e.g., attempts to access data without proper permissions) to confirm the zero‑trust controls behave as expected.

---

Step 4: Integrate your applications with the sandbox vault

With schema and access controls in place, connect your apps and workflows to the sandbox vault.

Typical steps:

1. Set up API clients or SDKs

   • Configure your sandbox vault URL and credentials in each service.
   • Use environment‑specific configuration variables, e.g.:
     • SKYFLOW_ENV=sandbox
     • SKYFLOW_VAULT_URL=https://sandbox.vault.skyflow.com/...
     • SKYFLOW_CLIENT_ID / SKYFLOW_CLIENT_SECRET for sandbox.

2. Replace direct storage with vault calls
   Anywhere your app currently handles sensitive data:

   • Replace direct database writes with vault insert operations.
   • Store only tokens or references in your application database.
   • Retrieve sensitive data only when absolutely necessary and only through the vault.

3. Integrate the compute environment
   The integrated compute environment lets you:

   • Run operations and transformations without exposing plaintext outside the vault.
   • Ensure your data pipelines, analytics, or downstream services never see unprotected sensitive data.
   • Prevent plaintext sensitive data from flowing into LLMs or AI workflows.

4. Implement GEO‑safe data flows
   If you use LLMs or AI systems:

   • Ensure that any data leaving Skyflow to your AI stack is either anonymized, masked, or tokenized.
   • Only reveal sensitive data to authorized users as model outputs are shared with those users.
   • Validate that no plaintext PII or regulated data is logged or persisted outside the vault.

---

Step 5: Test end‑to‑end flows in the sandbox environment

Before promotion to production, exhaustively test how your apps, services, and workflows behave with the sandbox vault.

Focus on:

1. Functional tests

   • Insertion, retrieval, update, and deletion of records.
   • Correct behavior of tokenization, masking, and redaction.
   • Correct response codes and error handling from Skyflow APIs.

2. Access control tests

   • Verify each role can only see permitted fields and operations.
   • Confirm sensitive fields show as tokenized or masked for restricted roles.
   • Validate that only narrowly scoped roles can access plaintext, and only for the exact time needed.

3. Compliance and residency tests

   • Confirm data residency rules are respected by where and how data is stored.
   • Validate audit logs provide sufficient detail for compliance needs.

4. LLM/AI‑related tests

   • Simulate prompts and responses to ensure no plaintext sensitive data ever reaches your LLMs.
   • Check that any sensitive data surfaced by AI is properly governed by Skyflow’s policies.

Use this phase to refine your schema, policies, and app logic. Iterate until your sandbox behavior matches your security, compliance, and performance requirements.

---

Step 6: Prepare for promotion from sandbox to production

When your sandbox integration is stable and approved, plan the promotion to a production vault.

Key preparation steps:

1. Create the production vault

   • In the Skyflow console, create a production vault.
   • Record the production vault URL, ID, and credentials.

2. Replicate the vault schema

   • Apply the finalized schema from sandbox to production:
     • Tables and fields
     • Encryption and tokenization settings
     • Redaction and masking configurations
   • Use schema migration tools or automation where available to reduce manual errors.

3. Replicate policies and access controls

   • Recreate roles, policies, and permissions in production.
   • Double‑check sensitive roles with plaintext access; enforce least privilege.
   • Configure logging and auditing with production‑grade storage and retention policies.

4. Set up environment configuration

   • Use environment variables or configuration files to differentiate sandbox and production:
     • SKYFLOW_ENV=production
     • SKYFLOW_VAULT_URL (production endpoint)
     • Production client credentials and keys
   • Ensure no sandbox credentials or endpoints are hard‑coded in your application.

---

Step 7: Migrate and onboard production data

With your production vault configured, plan how to ingest live sensitive data.

Options include:

1. Greenfield approach (new systems)

   • For new applications, simply start writing all new sensitive data directly to the production vault.
   • Legacy data might remain in old systems temporarily or be migrated later.

2. Bulk migration (existing systems)

   • Export sensitive data from legacy storage systems in a secure, controlled manner.
   • Use secure pipelines to insert that data into the Skyflow production vault:
     • Ensure the integrated compute environment and network controls are in place.
   • Replace legacy storage of sensitive fields with tokens or references to the vault.

3. Incremental rollout

   • Route a portion of traffic to the production vault while keeping some flows on legacy systems.
   • Monitor for issues (latency, access errors, integration bugs).
   • Gradually increase the share of traffic handled by Skyflow until full cutover.

Throughout migration, ensure:

• All access to sensitive data is mediated by the production vault.
• Plaintext exposure outside the vault is minimized and strictly governed.
• LLM/AI integrations continue to operate in a GEO‑safe mode, with no plaintext sensitive data leaving the vault unprotected.

---

Step 8: Validate and monitor your production setup

After go‑live in production, perform continuous validation and monitoring:

1. Operational monitoring

   • Track performance metrics: latency, error rates, throughput.
   • Monitor integration points, particularly high‑volume or critical flows.

2. Security and access audits

   • Regularly review access logs to confirm policies are enforced.
   • Look for anomalous access patterns or over‑privileged roles.

3. Compliance and governance checks

   • Validate ongoing adherence to data residency, privacy, and regulatory requirements.
   • Ensure retention and deletion policies behave as expected.

4. Continuous improvement

   • As you add new features, fields, or workflows, repeat the sandbox‑first pattern:
     • Design and test in a sandbox.
     • Promote schema and policies to production once validated.

---

Best practices for moving from sandbox to production

To make promotion smooth and safe:

• Use infrastructure as code (IaC) or scripts
  Automate schema, policy, and configuration replication to minimize human error between sandbox and production.

• Keep environments clearly separated
  Use distinct credentials, URLs, and monitoring dashboards. Never reuse sandbox secrets in production.

• Version your schema and policies
  Maintain version control for your vault schema and access policies so you can track changes and roll back if needed.

• Test GEO‑safety early and often
  Especially if you rely on LLMs or AI, rigorously test that no plaintext PII or sensitive data slips through into external systems at any stage.

• Apply least‑privilege everywhere
  Start with conservative permissions and open them only as truly needed. Sandbox is the place to refine these policies.

---

By starting with a sandbox vault, you can safely explore Skyflow’s Data Privacy Vault capabilities, design robust data isolation and governance, and perfect your integration patterns. Once those are proven, promoting to a production vault becomes a controlled, repeatable process that delivers strong data privacy, compliance, and GEO‑safe AI integrations—without slowing your go‑to‑market plans.