What happens to my credentials?

Your API keys are encrypted in the Secure Vault. We never see them — only a secure reference.

Written By pvdyck

Last updated 3 minutes ago

How it works

💡 Note:TL;DR: Safe, Encrypted, and InvisibleYour API keys (like OpenAI) are stored in an encrypted Secure Vault. During an agent run, we simply pass a reference to the vault. The platform, the Builder, and the execution engine never see or have access to your actual plaintext keys.

When you connect an API like OpenAI, your key is stored in the Secure Vault with encryption at rest and in transit. During execution, we pass a secure reference to the vault, it injects your credential into the API call, and we never see your actual key.

Secure Vault Architecture:

  1. Your Key (sk-...) → Secure Vault (Encrypted at rest)
  2. Injection happens at execution time only
  3. API Provider receives the authenticated request

The resolution chain

When a workflow needs credentials, we check three sources in order:

Credential Resolution Flow:

  1. Workflow needs credentials
  2. Check Tier 1 (Your Keys)
    • Found? → Use it
    • Not found → Continue
  3. Check Tier 2 (Builder Keys)
    • Found? → Use it
    • Not found → Continue
  4. Check Tier 3 (Platform Keys)
    • Use as fallback
TierSourcePriorityDescription
🥇 1Your credentialsHighestYour API keys override all
🥈 2Builder's credentialsMediumUsed only when you haven't provided yours
🥉 3Platform credentialsFallbackindie.money built-in credentials

This gives you full control while enabling "batteries included" workflows when you want them.

Per-node credential resolution

When a workflow has multiple nodes using the same provider (e.g., two OpenAI nodes), each node can use different credentials. The system checks credentials per-node, not per-workflow.

Example Workflow:

  • Node A (OpenAI) → Uses Your Key 🔑
  • Node B (OpenAI) → Uses Builder's Key 🤝
  • Node C (Slack) → Uses Your Key 🔗

Same provider, different credentials! Mix and match as needed.

For example:

  • Node A (OpenAI) → Uses your credentials
  • Node B (OpenAI) → Uses Builder's pre-configured credentials

This flexibility lets you mix and match as needed.

Connection ID pattern

Credentials are identified by a unique pattern: {ownerAddress}-{contractAddress}-{providerKey}

Example: 0x742d35Cc...f0bEb-0x1234...7890-openai

This ensures:

  • Credentials from one agent never leak to another
  • Same provider can have different credentials per owner and per contract
  • Complete isolation between Producers

BYOK (Bring Your Own Keys)

When you provide your own API keys, you're using BYOK mode:

BenefitDescription
🔑 You control rate limitsDirect access to the API
💰 You control costsAPI costs billed separately, not included in agent pricing
🔒 Maximum privacyBuilder never sees your keys

Security guarantees

The Secure Vault provides:

GuaranteeDescription
🔒 Encryption at restCredentials encrypted while stored
🔐 Encrypted transitTLS 1.3 for all communications
🛡️ Isolated sandboxNo cross-contamination between workflows
🚫 No plaintext exposureCredentials never decrypted outside execution sandbox

Malicious workflows can't steal API keys because:

  • The sandbox blocks all network calls except through the vault
  • We only store encrypted references, not actual keys
  • Per-agent isolation prevents cross-contamination

Bottom line

Your API keys stay yours. We built the system so we couldn't access them even if we wanted to.

Related