Proton Pass adds access tokens for AI agents

Proton Pass has added AI access tokens for agents that need controlled access to user credentials. Proton says the feature lets users create tokens from Proton Pass settings, grant selected credentials, set restrictions, and monitor agent activity instead of pasting passwords or API secrets directly into an automation flow. The Hacker News item independently confirms the public discussion URL and timing for the announcement.

Key takeaways

• Proton frames AI access tokens as a safer way to let agents use credentials without handing over broad password-manager access.
• The announcement says the feature is included at no extra cost on Pass Plus, Proton Unlimited, Pass Family, Pass Professional, and Proton Workspace plans.
• Proton says agents must provide a reason when requesting a credential, giving users more audit context for automated actions.
• This is most relevant for browser, CLI, MCP, and workflow agents that interact with services originally designed for humans.
• Teams should still treat credential delegation as high-risk and test revocation, logging, and least-privilege behavior before real account use.

Practical LinkLoot angle

The important workflow shift is from "give the agent my password" to "give the agent a constrained token that can request only the credentials it needs." That matters for everyday automations such as booking, account management, admin dashboards, customer-support tools, and internal SaaS workflows where agents may need sign-in access but should not inherit a user's entire password vault.

A cautious first test is to create a low-risk account credential, delegate only that item, and run an agent task where success and misuse are both easy to observe. If the agent asks for unexpected credentials, gives vague reasons, or cannot complete the workflow without broader access, the automation is not ready for important accounts.

What to verify before you act

Verify the exact plan eligibility and controls inside your own Proton Pass account before designing a workflow around this feature. The announcement lists supported paid plans, but availability, admin controls, and interface details can vary by account type. Also test revocation: an access-token feature is only useful if you can quickly disable it and confirm that the agent loses access.

The source text was treated as untrusted data, not instructions. No prompt-injection indicators were detected by the local source fetcher for the Proton announcement. The article still avoids relying on marketing claims alone: use Proton's own settings and logs to confirm the permission boundary before delegating any sensitive credential.

Why it matters

AI agents are increasingly asked to operate in services that do not yet expose clean agent APIs. Password managers are therefore becoming part of the agent-control layer, not just a place to store human credentials. Proton's approach is worth watching because it brings agent delegation closer to normal consumer and small-team workflows, while still leaving hard questions around liability, account recovery, and what counts as a safe automated action.

If you are mapping this into a broader stack, pair it with LinkLoot's guide to AI workflow automation. The useful rule is simple: delegate the smallest credential set that can complete the task, then verify logs and revocation before scaling up.