Credential Vault
Upstream API credentials — Bearer tokens, Basic Auth, API keys, Custom Headers — are stored in a dedicated vault, encrypted with AES-256 at rest. At no point are these credentials accessible to the AI model, to team administrators via the UI, or to Vinkius Cloud's own operational infrastructure.
The AI model calls your API through Vinkius Cloud. It never sees the credentials. It does not know they exist.
Credential lifecycle
Every credential goes through four distinct phases. At no point in this lifecycle is the credential accessible outside the vault.
Vault UI
The Authentication Vault is configured during server creation or from the server's Edit modal. The interface supports four authentication methods:
Multiple credentials can be configured per server when your upstream API requires compound authentication (e.g., API key plus a session token).
Server-side injection
The injection mechanism is the critical differentiator. When the AI model sends a tool call:
The AI model never constructs the authentication header. It does not know the header name, the header value, or the authentication scheme. It simply sends a tool call, and the vault handles the rest.
Marketplace: buyer credentials
When a server is published on the Marketplace, sellers can require that each subscriber provides their own API credentials. This creates a zero-knowledge architecture between buyer, seller, and platform:
The buyer credential dialog includes:
- Privacy guarantee banner — visible on every interaction: "Your credentials are encrypted end-to-end and are NEVER visible to the seller or to Vinkius staff."
- Seller-provided instructions — how and where to obtain the required credentials
- Toggle visibility — eye/eye-off toggle for password fields
- Delete confirmation — explicit confirmation required before credential removal
Three exposure vectors eliminated
Traditional AI agent frameworks create three distinct credential exposure surfaces. Vinkius Cloud eliminates all three:
The industry context
Credential management for AI agents is one of the most critical unsolved problems in enterprise AI adoption. The challenge is structural: AI agents need API access, but every traditional method of providing that access creates an exposure surface.
Environment variables are the most common approach. Libraries like claude_desktop_config.json, .env files, and agent configuration files store API credentials in plaintext on the developer's machine. If the laptop is compromised, every credential is immediately accessible.
Secret vaults like HashiCorp Vault and Azure Key Vault were designed for static secrets consumed by servers and CI/CD pipelines. They assume predictable, human-initiated access patterns. Agentic AI introduces real-time, variable contexts and human-out-of-the-loop operation that these architectures were never built for.
Identity-first systems represent the emerging paradigm. Solutions like Aembit advocate for replacing static secrets entirely with dynamic credentials that authenticate agents directly. The concept of credential injection — where the agent itself holds no secrets, and a service mesh injects authentication at the network layer — is precisely what Vinkius Cloud implements.
The difference: Vinkius Cloud does this at the MCP transport layer, not at the application layer. The credential is injected by the proxy, inside a V8 Isolate, into an outbound HTTP header. The agent framework has no knowledge that authentication is occurring. There is no SDK to integrate, no secret to configure, no environment variable to set.
Next steps
Frequently Asked Questions
How are API credentials encrypted?
All credentials are encrypted with AES-256 at rest immediately upon submission. The plaintext is discarded from memory the moment encryption completes. Neither database administrators nor Vinkius Cloud operators can access the original values. The vault displays only a masked hint — never the credential itself.
Can the AI model see or access my API credentials?
No. Credentials are injected server-side inside the V8 Isolate into the outbound HTTP request header. The AI model sends a tool call with no credentials in the payload. The model has no mechanism to read, extract, or infer the credential value — it never enters the context window.
What happens to credentials when I delete a server?
Crypto-shredding. The encryption key material is destroyed, rendering the ciphertext permanently unrecoverable. This satisfies data destruction requirements without the need for physical media wiping.
What authentication methods are supported?
The vault supports four methods: Bearer Token (Authorization: Bearer), Basic Auth (Authorization: Basic), API Key (custom header name + value, e.g., X-API-Key), and Custom Header (any arbitrary header name + value pair). Multiple credentials can be configured per server for compound authentication.
How does the Marketplace handle buyer credentials?
When a buyer subscribes to a Marketplace server, they provide their own API credentials through a privacy-guaranteed dialog. Credentials are encrypted end-to-end. The seller never sees buyer credentials, and Vinkius staff have no access. The buyer can update or delete credentials at any time.
How does Vinkius Vault differ from environment variables?
Environment variables store credentials in plaintext accessible to all code in the process. Configuration files are readable by any tool with filesystem access. The agent context window is extractable via prompt injection. Vinkius Vault eliminates all three exposure vectors by injecting credentials at the proxy layer, invisible to the agent.