Prompt exposure
Prompt context can repeat secrets.
A credential copied into prompt context can be repeated, transformed, logged, or leaked by a compromised model path.
§ 01Credential risk
Secrets become dangerous
when agents can see them.
Agent systems do not only call models. They touch APIs, tools, servers, accounts, files, workflows, and customer systems. If credentials are placed into model context or tool-visible memory, a prompt injection, compromised tool, or unsafe continuation can turn access material into exfiltration material.
Tool exposure
Tool paths can leak access.
A tool that receives raw credentials can pass them through logs, callbacks, retries, error messages, or unsafe downstream calls.
Runtime exposure
Broad access raises impact.
An agent runtime with broad credential access can convert a small instruction into a high-impact action.
§ 02Protected access objects
Vault turns secrets into
protected access objects.
Vault is designed to represent the access material agents and AI workflows need to use without seeing raw: API keys, service tokens, SSH keys, certificates, license keys, payment credentials, environment variables, usernames and passwords, server logins, remote access credentials, identity forms, sensitive documents, financial account data, address and profile data, named credential slots, and operation-scoped material where supported.
Each object carries enough identity to be requested safely: a name, owner, scope, system, or workflow reference. The protected value remains masked, encrypted, or released only in governed form.
Provider accessencrypted
API key
ProviderOpenAI
Slotprovider.openai.primary
Valuesk-•••• •••• •••• 9F2A
Releasegoverned use only
Service accessencrypted
Service token
ServiceGitHub Actions
Slotservice.github.deploy
Tokenghp_•••• •••• •••• 41C7
Scoperepo.deploy
Runtime configencrypted
Environment variable
NameDATABASE_URL
Envproduction
Valueenc:vault:9c7a••••
Useruntime injection
Login accessencrypted
Username and password
Userjane.doe@example.test
Systemadmin.portal
Password••••••••••••
Approvalrequired
Secure shellencrypted
SSH key
Hostprod-web-01
Userdeploy
KeySHA256:8F••••A91
Usesigned session
Software accessencrypted
License key
ProductDesign Suite
Ownerteam.creative
KeyLIC-••••-••••-73Q
Scopeseat-managed
Paymentencrypted
Payment credential
HolderA. Example
Usevendor.billing
Card•••• •••• •••• 1842
Approvalelevated approval
Document accessencrypted
Sensitive document
Documentidentity.pack
Owneruser.private
Blobenc:vault:42b9••••
Releasepolicy-bound
Trust materialencrypted
Certificate
Domainapi.example.test
Slotcert.api.primary
FingerprintSHA256:42••••B7
Renewaltracked
Infrastructureencrypted
Server login
Hostops-db-01
Useroperator
Secret••••••••••••
Approvalrequired
Identityencrypted
Identity form
Formkyc.identity
Owneruser.private
Blobenc:vault:71d2••••
Releasepolicy-bound
Financialencrypted
Financial account
Accountoperating.account
Institutionbank.example
Number••••••4821
Approvalelevated approval
Illustration only. Access objects show safe identifiers and masked or encrypted values. Raw secrets are not displayed to the agent.
§ 03Encryption boundary
Store ciphertext on the server.
Keep decryption at the edge.
Vault’s architecture targets zero-knowledge server storage: encrypted ciphertext on the server, decryption controlled by device-bound keys, and no plaintext credential value stored server-side.
Encrypted at rest
Credential values become encrypted material.
Credential values are represented as encrypted material rather than server-readable plaintext.
Device-bound keys
The key boundary stays near the trusted edge.
The decryption boundary is kept close to the trusted device or runtime that holds the key material.
No plaintext receipts
Evidence must not become the secret.
Receipts record access decisions and outcomes, not the credential value itself.
§ 04MCP Access Pass
MCP Access Pass gives agents
a controlled way to ask.
MCP Access Pass is the agent-facing interface to Vault where supported. Agents request credential use through named tools, submit approval codes when required, and receive governed material instead of raw secrets.
The agent never bypasses Vault.
MCP Access Pass is designed so agent-access tools follow the same request, approval, release, and receipt path instead of exposing a direct route to raw credentials. The access pass identifies the slot and requested use; Vault keeps the protected value behind the boundary.
Discoveryaccess_pass.list_slots returns envelopes only.
Requestaccess_pass.request_access declares slot, action, origin, and justification.
Approvalaccess_pass.submit_approval carries a time-limited approval code when required.
Evidenceaccess_pass.get_receipts returns status and receipt metadata, not credential values.
§ 05Access approval flow
Access starts with intent.
Not with the secret.
Vault treats credential use as an authorization event. The requester must declare what it wants to access, where the request came from, which tool or workflow will use it, and why the access is needed.
01 Request
Credential slot
The agent or workflow requests a named credential slot and declares intent, origin, tool, workflow, and scope.
02 Policy
Policy check
Vault checks origin constraints, allowed use, scope, policy state, and risk signals before release.
03 Approval
Approval gate
High-risk access can require a time-limited approval challenge or human confirmation where configured.
04 Release
Governed release
Vault releases governed material for the specific use, not a raw credential placed into model context.
05 Receipt
Receipt record
The access decision is recorded without including the credential value.
§ 06What the agent receives
The agent gets usable access.
Not the raw secret.
When access is allowed, Vault can provide a governed form of use: encrypted material, a short-lived derived token, or a signed payload for a specific operation. The point is to let the work continue without turning the credential into model-visible text.
Material type 01
Encrypted material
An encrypted form of credential material can be released for the runtime that is allowed to use it, without turning the value into prompt-visible text.
Material type 02
Short-lived token
A derived token can be scoped to a short window and specific context so access does not become a standing credential in the agent path.
Material type 03
Signed payload
A signed payload can authorize a specific operation while keeping the underlying credential outside model context.
§ 07Gateway and Sentinel integration
Credential access belongs
inside the governed path.
Vault should not sit beside Gateway and Sentinel as an unmanaged side channel. Credential requests, provider access, sensitive-data screening, and execution decisions need to line up across the same operating path.
Vault + Gateway
Provider access meets execution rights.
Gateway gives model-provider calls one operating layer. Vault adds protected access to the credentials and execution rights those calls may require.
Vault + PriviShield
Sensitive data gets screened.
PriviShield reduces sensitive-data exposure before credential-backed context or provider-bound content moves further through the runtime.
Vault + Sentinel
Risk checks can gate release.
Sentinel can evaluate access risk, pathway context, and control state before sensitive material is released or an action continues where enabled.
§ 08Evidence and custody
Record the access decision.
Do not record the secret.
Vault evidence should explain what happened without becoming the thing it is protecting. Receipts can show that access was requested, approved, denied, expired, or released in governed form, without storing the credential value itself.
Evidence should let an operator understand who requested access, which slot was involved, what policy or risk state applied, what material type was released, and which outcome was recorded.
The receipt boundary is deliberately narrow: explain the access decision without storing or displaying credential values.
Vault access record
illustration only
Request
requester_refagent.ops.assistant
credential_slotservice.github.deploy
workflow_refworkflow.release-review
origindesktop-runtime
Policy
scoperepo.deploy
approval_requiredtrue
risk_checksentinel.enabled
decisionapproved
Release
material_typesigned_payload
ttl45s
raw_secret_exposedfalse
Evidence
receipt_refvault.demo.019
credential_value_in_receiptfalse
outcomereleased_governed_material
Illustration only. Shows Vault access metadata and control evidence. Credential values are not shown or implied.
Credentials outside model context.
Vault is built for agent systems where access is needed but raw secrets should not become model-visible text. Agents request capability. Vault protects the credential. Sentinel controls the decision path.