Make the definition testable.
These principles are proposed by VaultProof. They are a framework for evaluating implementations, not an external certification. A product should substantiate how it meets each principle and where its limits are.
Separate
Keep the original key outside the caller.
The normal protected integration should let the application use a provider without retrieving its original API key. Distinguish this from fetching a raw secret into the application at startup.
Can the caller retrieve the original provider key through any normal integration endpoint?
Evidence to request
A request-flow diagram and an inspection of application configuration, credential-returning endpoints, diagnostic output, and documented exceptions.
Mediate
Put an authenticated control point in the request path.
The protection layer should authenticate the caller and check access before it sends a request to the provider. The architectural boundary should be explicit, including routes that can bypass it.
What checks run before a provider request, and what happens when a check fails?
Evidence to request
Evidence of rejected unauthorized requests, tenant or project isolation, documented failure behavior, and a clear account of bypass paths.
Constrain
Define what permitted access can do.
Access should have enforceable, documented limits. The exact controls vary: provider or route restrictions, request rates, environments, or identity-based permissions are examples to investigate.
Which restrictions are enforced on a request, and which are only monitoring or alerts?
Evidence to request
Configuration paired with allowed and denied request examples. Ask how restrictions interact, how changes propagate, and which operations remain unrestricted.
Observe
Record useful activity without recording secrets.
Operators need enough information to understand use and investigate unexpected activity. The system should define the metadata it collects and prevent raw credentials from becoming activity-log content.
What can an operator learn from an activity record, and what sensitive data is excluded?
Evidence to request
Redacted sample records, access and retention policies, error-path logging behavior, and evidence that credentials are excluded from normal logs.
Revoke
Make mediated access withdrawable.
An operator should be able to disable access through the protection layer. The scope of revocation, propagation delay, caching behavior, and treatment of in-flight requests must be documented.
After access is revoked, when will subsequent requests stop reaching the provider?
Evidence to request
A before-and-after request test, the documented enforcement window, and an explanation of original-key rotation and direct-provider access.
Evaluate the whole protection layer.
A stronger credential boundary is useful only when its operational assumptions are understood. Bring these questions into a technical review.
Trust and isolation
Who can change policy, retrieve stored material, or operate the runtime? How are customers and projects separated? Which infrastructure components can handle a complete provider key?
Failure and availability
What happens during an outage, timeout, or policy-service failure? Does the path reject requests when checks cannot be completed? What recovery or redundancy arrangements are documented?
Migration and remaining copies
Which providers and request types are supported? Where do original keys still exist after setup? How will the team remove old copies and rotate credentials that were previously exposed?
Revocation and bypass
Can requests continue through a cached decision or an alternative route? What is the measured enforcement window? Revoking a managed credential and revoking an original provider key are separate operations.
A shared language for scrutiny.
The framework builds on established credential-management and access-control practices. Use it to ask precise questions, compare evidence, and make the protection boundary understandable to everyone operating it.
Context: OWASP’s secrets-management guidance includes least privilege, auditing, rotation, and revocation.