Let AI sign in without exposing the password – map access first

A password can stay invisible to an AI agent while the account remains poorly protected. That is the uncomfortable detail behind new tools that sign in on an agent's behalf: protecting the secret is not the same as protecting the signed-in session.

The first problem is technical. Passwords, one-time codes, and tokens should not enter the model context. The second is operational. After sign-in, somebody still needs to decide what the agent may read, change, send, buy, or delete.

This guide separates those questions and gives you a delegated-access map to complete before the first pilot.

What delegated access means for an AI agent

Delegated access means giving an agent temporary, bounded access for a specific task without handing it a reusable secret. Good delegation answers three different questions:

• How is the login delivered? Ideally, the secret is filled or injected outside the model's view.
• Who approves authentication? A person or explicit policy must allow the right account for the right session.
• What may the agent do afterward? Reading, drafting, writing, and irreversible actions need separate boundaries.

If all three answers sit inside one box marked “agent has access,” the map is too coarse.

1Password for Claude demonstrates a local handoff

1Password for Claude is a clear example of keeping the secret outside the agent's field of view. When Claude needs to sign in, 1Password shows which vault item it is requesting. The user can approve it, choose another account, or deny the request. After approval, 1Password fills the credential directly on the website while Claude temporarily stops reading the page. According to the documentation, passwords and one-time codes do not enter Claude's context, memory, or Anthropic's systems.

Source: 1Password Support – Use 1Password to sign in to websites with Claude

The security model requires a fresh approval for each agent session. Credentials are session-bound and short-lived, and a failed fill should be cleared before the agent regains control. 1Password also states the crucial boundary: after successful sign-in, the agent product's safeguards govern what the agent does on the site. The password manager does not guarantee behavior inside the authenticated session.

Source: 1Password Support – About the security of 1Password for Claude

This is still a beta with narrow compatibility. Claude lists paid plans and Claude Desktop on macOS. 1Password requires its Mac app and browser extension, and the current integration supports usernames, passwords, and time-based one-time codes. Passkeys and social sign-in are not supported.

Source: Claude Help Center – Get started with 1Password for Claude

Perplexity SPACE applies the same principle at platform level

Perplexity describes a different technical form in the SPACE architecture behind Computer. Credentials live outside the isolated runtime and can be filled in the browser or injected at the network layer when needed. The architecture describes hierarchical scoping, expiry, rate limits, and audit logging for access.

Source: Perplexity – Secure Sandboxes for Agents

That is a useful design pattern, not a product guarantee for every agent tool. SPACE powers Perplexity Computer, but the public architecture paper should not be read as proof that every control is sold as a separate public API feature. Always verify what the service and plan you actually use can restrict and export.

Source: Perplexity Research – Making SPACE: Secure and Efficient Runtimes for Long-Running Agents

Draw the access map in three layers

Do not begin in the product's settings screen. Start with a working document and complete three layers separately.

Layer 1: the secret

Describe how the authentication material is handled.

• Secret: Password, one-time code, API token, session cookie, or another method?
• Storage: Where does the secret live before the run?
• Delivery: Autofill, network injection, short-lived token, or manual sign-in?
• Exposure: Can the value reach model context, prompts, logs, screenshots, files, or tool output?
• Lifetime: When does the credential or session expire?

The goal is not “the AI promises not to read the password.” The goal is that the agent never technically needs the value.

Layer 2: authentication

Write down who may open which door.

• Account: Which exact user or service identity is used?
• Approver: Who may approve sign-in?
• Timing: Is approval required per run, per session, or for a time window?
• Environment: Test account, sandbox, or production?
• Revocation: Who can end the session and disconnect the integration?

Do not use an owner's personal administrator account simply because it already exists in the password manager. Prefer an account whose ordinary permissions already match the pilot task.

Layer 3: the action after sign-in

This is the layer most often missed. List actions as separate decisions:

• Read: Which pages, records, folders, or customer cases may the agent see?
• Draft: What may it prepare without sending or publishing?
• Write: Which fields or objects may it change?
• Commit: May it send, book, buy, delete, or change permissions?
• Threshold: Which amount, recipient count, or data class triggers a stop?
• Human approval: Which actions must always be shown before execution?
• Evidence: Which log, before-and-after view, or transaction identifier is retained?

“Can sign in” must never become shorthand for “may do everything the account can do.”

Copy this delegated-access map

Complete one card per website, account, and task. Do not combine several systems in the first pilot.

• Task: What should the agent deliver?
• Website or system: Where does the work happen?
• Account and owner: Which identity is used, and who is accountable for it?
• Secret path: How does the login reach the page without reaching the model?
• Approval point: Who approves, when, and with what information visible?
• Session boundary: How long does access last, and how does it end?
• Allowed reads: Exact objects and data classes.
• Allowed writes: Exact fields and destinations.
• Always forbidden: Purchases, deletion, publication, new recipients, or other stop points.
• Threshold: Amount, volume, or risk level that requires a person.
• Audit evidence: What must exist after every run?
• Revocation: How can the account, session, and integration be shut down quickly?
• Manual fallback: How is the task completed if the agent is stopped?
• Decision date: When will you stop, adjust, or expand the pilot?

Run a test that tries to break the map

A normal successful test tells you too little. Add one deliberately denied case.

1. Create or choose a test account without administrator rights.
2. Give the agent a small read task with a clear accepted result.
3. Approve exactly one login for the current session.
4. Then ask the agent to attempt a forbidden write against test data.
5. Confirm that the action is blocked or requires the approval written into the map.
6. End the session and verify that access cannot be reused.
7. Read the audit trail and confirm that it shows the account, time, allowed action, denied attempt, and final status without containing the secret.

Do not use real customer records, payments, or production administration for the first negative test. The point is to prove the boundary without creating an incident.

Approve the pilot only when both protections hold

The pilot is not approved merely because the chat history contains no password. It needs to pass two separate checks:

• Secret protection: No reusable login appears in context, logs, screenshots, or working files.
• Action protection: The account and workflow block forbidden actions even after successful sign-in.

Adjust the pilot if the approval prompt is unclear, the session outlives the task, or the audit trail cannot be tied to a decision. Stop it if the agent can switch accounts, widen its authority, or complete a forbidden step without another control.

If the map exposes unclear accounts, session limits, or write rules, the next step is not to share a password “just for the test.” Map the access in Tool Forge and build a pilot where both the login and the action can be revoked, tested, and explained.