We Built an Impenetrable Token Vault for Your Secrets

Modern agentic platforms live and die by integrations.

Whether you’re using your agent for reading Jira tickets, pushing PRs to GitHub, sending messages into a Slack channel, or performing higher-impact actions like connecting to your database or updating production systems, the pattern is always the same:
your system needs credentials that grant access to something valuable.

In MCPTotal, this requirement is amplified. AI agents and MCP servers are explicitly designed to act across tools, services, and environments on your behalf. That power is only acceptable if the credential layer is designed for a threat model that assumes compromise—and still prevents mass exfiltration.

This post explains why a token vault is a first-class requirement for MCPTotal, why common approaches like “encryption at rest” are routinely misunderstood, and how Piiano Vault provides the right security primitives for storing OAuth tokens and API keys used by AI agents and MCP servers.

Credentials change the threat model

A secret is anything needed to authenticate to a service:

• OAuth access and refresh tokens
• API keys
• Service account credentials
• Signing secrets and private tokens

If one of these leaks, the attacker doesn’t just read your data—they act as you in another system.

This is fundamentally different from most application data breaches. Once credentials are stolen, the blast radius is external: GitHub repos, Jira projects, Slack workspaces, cloud accounts, databases, production systems or whatever you connect to your MCP servers. Containment becomes harder, detection is often delayed, and revocation is painful, if exists at all.
If MCPTotal stores credentials that allow agents or MCP servers to connect to third-party systems, we must assume attackers will target those credentials directly.
The correct question is not “are they encrypted?”
It is “what happens when something upstream is compromised?”

Malicious MCP server?

We even allow you to upload a custom MCP server, which we run on your behalf in our cloud. From a security perspective, we assume this code could be malicious or compromised.
By design, every MCP server runs in a single-tenant, isolated, sandboxed environment. The vault is never directly accessible from the MCP server. Secrets are only injected at runtime, scoped to the exact execution context and permissions required.
The worst-case scenario we consider is a deliberately malicious MCP server attempting to exfiltrate credentials. To mitigate this, we built a custom static code analyzer that scans MCP server code for exfiltration patterns and other suspicious behavior before execution.
Combined with isolation and vault-side access controls, this ensures that even untrusted MCP server code has a tightly constrained and observable blast radius.

Why “encryption at rest” does not solve this problem

Encryption at rest is frequently treated as a universal security control. It is not.
Its primary purpose is to protect data when attackers gain physical access to storage media—lost disks, stolen hardware, improper decommissioning. It works well for that threat model.
But modern cloud breaches almost never look like that.
They look like:

• Compromised application credentials
• SQL injection or logic bugs
• Lateral movement inside a cloud environment
• Misconfigured IAM or leaked tokens
• Runtime abuse of legitimate services

In these scenarios, encryption at rest provides no meaningful protection. The database is accessed through the application, using valid credentials. Data is transparently decrypted as part of normal operation.
If your OAuth tokens or API keys are stored in a database—even an encrypted one—an attacker who compromises your app or its identity layer can usually extract them at scale.
This is why “the database is encrypted” is not a sufficient answer for credential security.

“Just encrypt it in the app” still fails under realistic attacks

Application-level or field-level encryption is a common next step: encrypt the token before storing it.
This raises the bar, but it does not fix the core issue.
In real breaches, attackers don’t stop at stealing storage—they compromise runtime. Once they do, the same code paths that decrypt secrets for legitimate use can be abused for extraction. Encryption keys become another asset to steal or misuse.

On top of that, application-level encryption pushes hard problems onto your team:

• Key storage and isolation
• Key rotation and versioning
• Consistent enforcement across services
• Auditing and access visibility
• Avoiding accidental leakage via logs, traces, or prompts

None of these are cryptographic problems. They are system-design problems—and they get harder as AI agents and automated workflows increase call volume and integration surface area.

Databases optimize for access; vaults optimize for containment

Databases are designed to make data easy to retrieve and FAST. That’s their job.
A vault is designed to minimize exposure, even at the cost of flexibility.
This distinction matters when you’re storing credentials.

• Databases assume trusted callers and flexible queries
• Vaults assume hostile environments and constrain behavior

A token vault is not “a database with encryption”, it's much more.
It is a security system that happens to store secrets and what makes it special is its unique access controls.

The three common approaches to storing credentials in the backend

Most systems fall into one of these patterns:

Level 0: Plaintext in a database

Fast to build, trivial to breach. Anyone with DB access gets everything. No auditability. Maximum blast radius.

Level 1: Encrypted fields in the database

Protects against raw DB theft, but not against runtime compromise. You own key management, rotation, and enforcement. A compromised app can still dump secrets.

Level 2: Secrets managers (KMS / SSM / classic secret stores)

A solid improvement for infrastructure secrets. But most were not designed for customer-scale OAuth tokens with high throughput, tenant isolation, and rich access policies. Costs and ergonomics degrade quickly at scale.

Enterprise-level: A token vault

A purpose-built system that adds the controls missing from all the above: constrained access patterns, granular permissions, auditing, monitoring, rate limiting, and proxy-style access that reduces secret exposure.
For MCPTotal-style workloads, this is the only tier that matches the real threat model.

Why a vault actually stops attacks that beat databases

Real attackers may or may not need exotic exploits but reality says they actually exist. They can either leverage SQL injections, or use some remote code execution (RCE) attacks to run in the backend.
If you think RCE attacks are a relic of the past, think again (rect2shell).

A vault disrupts that by design:

• No free-form queries: APIs accept only parameterized inputs, eliminating injection-style abuse
• Mandatory pagination: dumping everything in one request is impossible
• Rate limiting: high-volume extraction attempts are throttled and may raise an alert
• End-user impersonation: access can be tied to logical ownership, not just service credentials
• Full auditing and monitoring: abnormal access patterns become visible instead of silent

Even if an attacker compromises an MCP server—bearing in mind that we allow users to run arbitrary code—the vault is never directly connected to the server runtime. Secrets are only injected in a tightly scoped manner.
Moreover, even in the extreme case of a compromised backend, an attacker would still need a valid JWT representing the specific user in order to access that user’s secrets. So if they want to dump all secrets, they need everybody's JWTs, good luck.

The secret sauce of a vault - JWT-based access

The ultimate access controls that turn the vault into a robust solution against fully compromised backend systems are based on a powerful mechanism tied directly to the end-user’s identity. The JWT (JSON Web Token) is a well-established standard for conveying identity, claims, and context in a tamper-proof way between systems.

Piiano Vault uses JWT-based impersonation to bind every data access request to a specific end user, tenant, and execution context. Rather than granting a backend service blanket permission to read secrets, the vault requires a valid JWT that represents who the request is acting on behalf of and why. This eliminates implicit trust between the application and the vault.

As a result, even if a backend service is fully compromised, an attacker cannot arbitrarily enumerate or exfiltrate credentials. Access is constrained to the logical owner represented by the JWT, making cross-tenant access, bulk dumping, and privilege escalation materially harder and fully auditable.

Why MCPTotal specifically requires a token vault

MCPTotal has two credential-consuming workflows:

1. The agents connecting to MCP servers (or MCPTotal's spaces)

This is normally done using oauth or alternatively API keys.

2. The MCP server connecting to third-party cloud services

The MCP server executes tool calls against third-party accounts using regular HTTP APIs.

A token vault mitigates the risk:

• Compromising an agent does not automatically expose raw tokens. In fact, a sane MCP server should never send its own credentials to the agent client
• Compromising the MCP server does not imply bulk credential access
• Access can be constrained by tenant, user, tool, and workflow
• Abnormal behavior becomes auditable and detectable

Why Piiano Vault fits the MCPTotal model

Piiano Vault is designed with the assumption that the environment will be breached.

Practically, that means:

• JWT-based access controls is the primary advantage
• Field-level encryption using modern AEAD modes (AES-GCM)
• Strong integrity guarantees and anti-tampering detection
• Managed key isolation and rotation
• Fine-grained IAM that goes beyond “can read / can’t read”
• Built-in auditing and monitoring
• Proxy / relay patterns that allow third-party calls without exposing raw secrets to agents or services

This is not about “stronger crypto”.
It is about reducing blast radius under realistic compromise scenarios.

A secure MCPTotal secrets flow

A vault-based workflow typically looks like this:

1. You launch an MCP server
2. You connect a third-party account (OAuth or API key)
3. MCPTotal stores the credential in the token vault, bound to your identity
4. When an MCP server is executed the parent already fetches the relevant secrets
5. Parent creates the MCP server and injects the secrets to it via environment variables
6. This architecture makes it impossible, at least by design, to bulk-dump all secrets from the vault

About Piiano Vault

Piiano was our original startup, focused on building a highly secure vault designed to safeguard customers’ most sensitive data. Following a strategic pivot in 2025, we are now operating as MCPtotal, where we continue to leverage and build upon this same vault technology as a core component of our new platform.

Conclusion: AI integrations demand vault-grade security

MCPTotal is designed to automate real work across real systems. That power makes credential security non-negotiable.

“Encryption at rest” and “encrypted columns” are not sufficient defenses against the attacks that dominate cloud breaches today. A token vault is the correct primitive because it is designed to assume compromise and still protect what matters most.

That is why MCPTotal uses Piiano Vault as its token vault: to store OAuth tokens and API keys and other sensitive custom environment variables for AI agents and MCP servers in a way that remains defensible when (and not if) something goes wrong!