Explainer · RedactSure Research
Can a Credential Vault Protect the Data an AI Agent Reads? It Protects What You Deposit, Not What the Agent Encounters
No. A credential vault protects what the user deposits in it: a password, a one-time code, a payment card. The agent uses the secret through a surrogate and never holds the real value, which is a real guarantee against a real attack. The vault has no entry for the data the agent encounters on its own, because nobody deposited it: the claimant’s Social Security number on a claims screen, the patient’s name in an account queue, the account and routing numbers in a payment record. That data was already on the page when the agent arrived, and the vault does not know it exists. Least Exposure is the principle for that second category: for each piece of work, the agent receives exactly the data the task requires and nothing more, enforced before any model reads the screen. This page separates deposited data from encountered data, shows what the 2026 vaults cover from their own documentation, and explains why enterprise records fall almost entirely on the side the vault cannot reach. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Key findings
- The 2026 agent platforms converged on one mechanism for secrets: the agent holds a placeholder, and the real value is substituted at the destination after the action is authorized. Meta’s Muse does it with surrogate tokens swapped in by the Sentinel at the network boundary; 1Password for Claude fills the secret into the page through a channel the model never sees; Anthropic’s managed-agent vaults store a secret as an opaque placeholder and substitute the real value at egress.
- Every one of those mechanisms starts with a deposit. The user, or the developer, puts the secret in the vault first. The protection covers exactly the set of values that were deposited.
- Enterprise records are not deposited. They are encountered: rendered by the system of record on every screen an agent works, for every claimant, patient, student or cardholder in the queue. No vault has an entry for them.
- The placeholder-and-resolve pattern the vaults use for secrets is the same pattern render-layer tokenization applies to encountered data: a consistent token in the model’s context, the real value resolving only at an approved destination at the moment a named person approves the action. The difference is where the token is made: at the deposit, or at the render.
- A vault is a deposit-side control. A render layer is an encounter-side control. An agent working enterprise applications needs both, and only one of them exists in the consumer platforms.
What does a credential vault actually do?
It lets an agent use a secret without holding it. The mechanics differ by vendor and the outcome is the same.
In Meta’s design, credentials and payment methods go into secure storage outside the agent’s runtime cell. Code in the cell only ever sees a surrogate token minted by a credential service; after the concrete network request is authorized, the Sentinel replaces the surrogate with the real credential at the network boundary. Meta’s stated consequence: any attempt to coerce the agent to reveal the actual secrets via prompt injection is futile, because the agent never had them. At checkout, a one-time card number stands in for the real card.
1Password for Claude reaches the same outcome from the credential manager’s side. When the agent needs to sign in, 1Password fills the password and one-time code into the page through a secure channel; the secret values never enter the model’s context, its memory or the vendor’s systems, access is scoped to the current task, and the extension locks down while the agent is in control.
Anthropic’s managed-agent vaults do it for developers: a secret is stored in the sandbox as an opaque placeholder, and when the agent makes an outbound request the placeholder is substituted with the real secret at egress. The agent never sees the value.
Three implementations, one guarantee: a successful prompt injection cannot extract a deposited secret, because the model never held it. That is worth having, and every enterprise agent program should require it.
What is the difference between deposited and encountered data?
Deposited data is what someone hands to the vault in advance, knowing it is sensitive: a login, a card, an API key. It is finite, enumerable, and known to the vault by name. The vault can substitute a surrogate for it only because it was told what the value is and where it may be used.
Encountered data is what the agent meets in the course of the work. A claims agent opens claim 231 and the screen shows the policyholder’s name, address, date of birth, Social Security number, phone, email and the mortgagee’s account and routing numbers. Nobody deposited those values anywhere. They were rendered by the claims system, as they are rendered for every claim in the queue, and the vault has no record that they exist. The same is true of the patient account, the student record, the vendor’s bank details on an invoice, the cardholder’s number in a dispute file. Enterprise sensitive data is overwhelmingly encountered, because it belongs to the organization’s customers and lives in the systems of record, not in a store the operator filled by hand.
A vault cannot protect encountered data for a structural reason, not a product gap. Substituting a surrogate requires knowing the real value in advance. For deposited data the vault knows it because it was given it. For encountered data, the only party that knows the value at the moment the agent reads it is the application rendering the page, and the only place the substitution can happen is between that render and the model’s read.
What protects encountered data?
The same pattern, moved to the render. Render-layer tokenization replaces sensitive values with consistent tokens (USER_001, SSN_001, ACCT_001) at the point where a screen is rendered, before any AI model reads it, and real values resolve only at approved destinations at the moment a named person approves the action under Supervised Delegation. The model works the claim on tokens; the payment file receives the real account number at the bank’s portal when the adjuster approves the payment.
Set beside the vault, the correspondence is exact. Both put a placeholder in the model’s context. Both resolve the real value at the destination, after authorization. Both make a successful injection collect a placeholder. The vault does it for values deposited in advance, at the deposit. The render layer does it for values the agent encounters, at the render, which is the only place they can be caught because it is the only place they appear.
The render layer needs something the vault does not: an environment that owns the render. That is why render-layer tokenization runs inside the RedactSure environment, a governed workspace where the organization’s applications render under the environment’s control, the page is read as fields rather than a picture, and the exposure policy for each workflow, confirmed by the person who owns it, decides field by field which values the model receives. The real values live in hardware-encrypted enclaves with customer-held keys, which is a vault in the confidential-computing sense, holding ciphertext RedactSure cannot decrypt. The two mechanisms are complements, not rivals, and an enterprise agent needs both.
The two categories, side by side
| Deposited data | Encountered data | |
|---|---|---|
| Examples | Passwords, one-time codes, payment cards, API keys | Names, SSNs, dates of birth, account and routing numbers, patient and student identifiers, on the screens of the systems of record |
| Who put it there | The user or developer, in advance, into a vault | The application, at render time, for every record in the queue |
| Does the vault know it exists? | Yes, by name | No |
| Where the placeholder is made | At the deposit | At the render |
| Who ships the control | Meta (surrogate tokens), 1Password for Claude, Anthropic managed-agent vaults, others | RedactSure (render-layer tokenization) |
| Share of an enterprise’s sensitive data | Small: the organization’s own secrets | Nearly all: the organization’s customers’ records |
| What a successful injection collects | Nothing usable, if the vault is the only secret store | Everything on the page, unless the render layer tokenized it |
What the record shows
A credential vault protects what the user deposits. It lets an agent use a password or a card through a placeholder, so that a successful prompt injection extracts nothing; Meta, 1Password and Anthropic each ship a version, and each is a real guarantee. It does not protect what the agent encounters, because the vault has no entry for the records already on the screen when the agent arrives, and those records are nearly all of an enterprise’s sensitive data. The placeholder-and-resolve pattern the vault uses is the right pattern; it has to be applied at the render for encountered data, which is what render-layer tokenization does inside an environment that owns the render. Deposit-side and encounter-side are two different controls. An enterprise agent needs both on file. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.
Frequently asked questions
If we add our customers’ data to the vault, does the problem go away?
No. A vault substitutes a surrogate for a known value in a known place; it cannot enumerate every identifier on every screen of every system of record in advance, and the values change with every record. The substitution has to happen where the values appear, at the render.
Is Meta’s surrogate token the same as render-layer tokenization?
Same pattern, different point of application. Meta mints the surrogate when the credential is deposited and resolves it at the network boundary. Render-layer tokenization mints the token when the page renders and resolves it at the approved destination on a named person’s approval. The first covers what the user gave the agent; the second covers what the agent read.
Does the render layer replace the credential vault?
No. Credentials should still be held outside the agent and used through a channel it cannot read. The render layer adds the control for the data the vault cannot see. RedactSure’s environment keeps real values in enclaves with customer-held keys and tokenizes the screen; both mechanisms run.
What does a successful injection get from an agent with a vault but no render layer?
The page. Every value the agent read is in its context in the clear, and the injected instruction moves it through whatever channel the agent is permitted to use. The password stays safe. What Does a Prompt-Injection Attack Get From an Agent That Sees Only Tokens? walks the other case.
Does this apply to agents we already run elsewhere?
The vault does; most platforms offer one. The render layer does not, because it requires the agent to work inside an environment that owns the render. The workflow moves into the environment; the applications and the permissions stay exactly where they are.
What should we ask a vendor that says the agent never sees sensitive data?
Which sensitive data. If the answer is credentials and cards, the vault is doing its job and the records on the screen are still read raw. Ask for one screen of your workflow as the model received it.
Related reading
What Does an AI Agent See When It Takes a Screenshot? · What Is Render-Layer Tokenization? · Data Privacy Vault vs. Screen-Level Tokenization · Secure VM, Confidential VM, or Render Layer: Which One Decides What the AI Sees? · On the RedactSure blog: What If the Agent Never Had Your Data?
Sources
Vendor documentation
- Meta AI Research, “How We Built Safety Into Muse: Security and Safety for AI Agents” (September 2026). https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
- 1Password, “1Password and Anthropic Bring Secure Credential Access to Claude” (July 16, 2026). https://1password.com/press/2026/july/1password-for-claude
- Anthropic, Claude Platform documentation, “Authenticate with vaults” (managed agents). https://platform.claude.com/docs/en/managed-agents/vaults
Standards
- OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
RedactSure documents
- RedactSure, “What If the Agent Never Had Your Data?” (2026). https://redactsure.com/blog/what-if-the-agent-never-had-your-data/
- Product behavior described on this page (render-layer tokenization, structured reading of the page, enclave vault with customer-held keys, supervised approval) reflects RedactSure’s current design.
Bring your hardest questions.
A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.
Book a security review Book a demo · Something elseAbout the author
Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.