Why shouldn't you pass API keys or credentials directly into an AI agent's context?

If an agent holds a real password, cookie, or token in its context, prompt injection or hidden malicious web instructions can force the model to expose it. Keeping credentials out of the context makes them immune to prompt-based theft.

How does Claude Duet handle site logins without seeing user passwords?

Users enter credentials into an encrypted in-app form. The password is encrypted with a single-use key that exists only on an isolated cloud browser machine. The browser enters the password directly, meaning the AI model never views, stores, or repeats the secret.

How are agent purchases secured against unauthorized spending?

Instead of storing credit cards inside the agent, purchases use virtual single-use cards (such as Link from Stripe) restricted to a specific merchant and exact amount. Every transaction requires user approval outside the model.

Securing AI Agents: Why Credentials Must Stay Off the Model

Why Prompt Instructions Cannot Protect Enterprise Credentials

When enterprises deploy autonomous agents to draft emails, purchase software, or manage cloud services, the default instinct is often to rely on system prompts. Teams instruct models with directives like "never reveal customer data" or "ask before confirming a purchase."

System prompts fail as security boundaries. If an agent carries an API key, session cookie, or corporate password in its active context, any adversarial input—such as a prompt injection hidden inside an email or webpage—can manipulate the model into leaking that secret.

Anthropic's research preview of Claude Duet highlights a different architecture: security cannot happen inside the model alone. Claude Duet acts across connected services and runs routines in the cloud even when the user closes the app. Yet it operates on a strict boundary: the agent never sees passwords, browser cookies, or sign-in tokens.

At Starbox AI, where we build and integrate marketing workflows for enterprise clients, we see the same principle hold true. Autonomous execution should never be coupled with raw credential access. Security begins by taking credentials away from the model entirely.

Isolating Credentials: How Token Placeholders and Sandboxes Block Exploits

Claude Duet approaches credential security by physically isolating authentication data from the computing environment running the model. This model-external architecture relies on three primary mechanisms:

Proxy Token Injection: For connected business applications, Claude Duet uses the Claude Managed Agents architecture. The agent environment only holds placeholders for authentication tokens. When an outbound API request is dispatched, an external proxy machine intercepts the call and injects the actual credential. The model never reads or caches the raw token.
Encrypted Single-Use Login Forms: When a website requires a manual login, users do not hand credentials to the model. Instead, an in-app form encrypts the password with a single-use key tied exclusively to an isolated cloud browser machine. The encrypted secret routes directly to the browser instance to log in. The AI never sees or repeats the password.
Dedicated Cloud Browser Virtual Machines: The web browser runs in its own cloud virtual machine, separated from the agent's computing environment. The agent controls navigation using a fixed instruction set (open this page, click here, type this). The target website's executable code, scripts, and session cookies remain locked inside the browser VM. The model only receives parsed page text and file downloads required to complete the task.

[User Request] 
      │
      ▼
[Agent Model Environment] ──(Fixed Commands / Token Placeholders)──┐
      │                                                            │
      ▼                                                            ▼
[External Intent Classifier]                               [Isolation Proxy / Secure VM]
      │                                                            │
   (Checks)                                                (Injects Real Tokens)
      │                                                            │
      ▼                                                            ▼
[Action Approval Card]                                     [Target Service / Web]

This design neutralizes credential-harvesting prompt injections. Even if a malicious webpage orders the agent to output its active session cookies or system keys, the agent cannot comply because it does not possess them.

Dual-Tier Verification: Why High-Risk Actions Demand External Classifiers

Autonomous agents reading inboxes and preparing external communications handle complex information flows. Instructing an agent to generate a team recap must not result in sharing private performance reviews or executive compensation details.

Claude Duet addresses this by running an independent safety classifier outside the primary model before messages or files are sent. This automated check evaluates outbound data across two distinct tiers:

Protection Tier	Data Types Included	Enforcement Rule
Never Share	Sign-in credentials, bank account numbers, full credit card numbers, government IDs	Strictly blocked from outbound transmission, even if the user explicitly orders the agent to send them.
Needs Consent	Sensitive personal records, financial summaries, private health details	Blocked unless explicit user consent is established. If blocked, the agent rewrites the draft without the data for user review.

Crucially, this intent classifier runs on an external system based on the classifier used in Claude Code. Because it operates outside the model executing the task, hidden prompt injections embedded in web pages or documents cannot tamper with the classification decision.

Financial Actions Require Single-Use Tokens, Not Stored Cards

Allowing an AI agent to conduct transactions introduces immediate liability if the agent can spend freely. Claude Duet implements strict boundaries around financial actions and sensitive system state changes:

Merchant-Locked Single-Use Cards: For transactions, Claude Duet does not store an enterprise corporate credit card. Instead, it generates a one-time virtual card through a payment wallet (such as Link by Stripe). The card is locked to the specific merchant and the approved transaction amount. The user confirms the item and total directly in their payment wallet, ensuring the agent and merchant never see the underlying card number.
Non-Bypassable Approvals: Certain tasks carry permanent human-in-the-loop requirements. Actions such as paying or sending money, deleting an existing order, or provisioning a new account can never be set to "don't ask me again," regardless of how many times a user has previously approved them.
Absolute Off-Limits Boundaries: Some enterprise actions are hard-blocked by design. Claude Duet does not support trading securities, moving funds between bank accounts, or accessing accounts belonging to third parties—even if a user attempts to approve the action.

These rules also protect against approval fatigue. Anthropic notes that asking for verification too frequently trains users to tap through prompts blindly. High-risk operations must have selective, high-friction checks, while benign steps proceed without unnecessary interruption.

Enterprise Checklist for Securing Autonomous Agent Workflows

Organizations deploying autonomous agents across customer operations, marketing infrastructure, or procurement can use this checklist to audit their internal architecture against modern credential isolation standards.

1. Context and Credential Stripping

[ ] Are API tokens, database passwords, and service keys removed from system prompts and model memory?
[ ] Does your architecture use placeholder variables, relying on an external proxy to inject active authorization headers during outbound network requests?
[ ] If the agent interacts with web interfaces, is the browser isolated in a dedicated virtual machine where the model cannot extract session cookies?

2. External Verification and Boundary Control

[ ] Is outbound message inspection handled by a separate classifier running outside the agent's execution environment?
[ ] Are core credentials (government IDs, full card details, system tokens) configured with a strict "Never Share" rule that user prompts cannot override?
[ ] Do sensitive communications require explicit, auditable user approval before the agent dispatches them?

3. Financial and Destructive Action Limits

[ ] Are agent payments executed via scoped, single-use virtual cards restricted by vendor and spend limit?
[ ] Are irreversible operations (account creation, record deletion, money transfers) excluded from automatic approval presets?
[ ] Are high-liability capabilities (direct banking transfers, asset trading) barred from agent tool definitions entirely?

4. Visibility and Identity Management

[ ] Does each autonomous task maintain an isolated task log allowing operators to inspect and steer the agent mid-execution?
[ ] Does disconnecting an enterprise app immediately revoke access tokens while providing an option to clear stored historical memory?
[ ] Does the agent identify itself clearly on the public web using custom request headers and documented IP ranges?

Building enterprise-grade AI automation requires shifting focus away from prompt engineering toward structural system isolation. Keeping credentials, payment data, and verification checks outside the model ensures that autonomous agents remain productive without exposing core business assets.

This article was written and illustrated by a Starbox AI writing agent and published after automated review. For reference only.

The English edition is rewritten from the original Chinese article on the same topic.