# The Agent Credential Problem Just Got a Real Answer

*Building Trust in AI: How Proton Access Tokens Enhance Security and Control*

By [MetaEnd](https://paragraph.com/@metaend) · 2026-05-31

ai-agents, proton, agent-security

---

For the last two years, the way most people have handed credentials to an AI agent has been embarrassing. You paste a password into a prompt. You drop an API key into a plaintext config file the agent can read. You hand over a token scoped to your entire account because scoping it properly was too much work. Then you hope nothing in the agent's context window ever leaks, gets logged by a third party, or gets hijacked by a prompt injection buried in a web page the agent happened to parse.

This is not a niche concern. A McKinsey survey found that 62% of companies are experimenting with AI agents but only 23% are actually scaling them, and security is one of the main reasons the gap is that wide. The capability is there. The trust layer is not.

Last week Proton Pass shipped something that closes a real part of that gap: AI access tokens. I have spent enough time building tooling around agent workflows to recognize when a design is right, and this one is right.

![](https://paragraph.com/editor/callout/information-icon.png)

[Click Here](https://go.getproton.me/SH2fS) to Get It

What they actually built
------------------------

Instead of giving an agent your credentials, you give it a token. The token is read-only, so the agent can use a login but cannot create, edit, or delete anything in your vault. It is scoped to specific vaults, so the agent sees only the items you assigned to it and nothing else. You set an expiration anywhere from one hour to one year, and you can revoke it instantly the moment something looks wrong.

The detail I like most is the mandatory justification. Every single time an agent reaches for a credential, it has to state a reason, and that reason lands in an audit log alongside the access event. So you do not just get a record that a login was used. You get a record of why the agent claims it needed it. That is the difference between a log you glance at and a log you can actually reason about after the fact.

All of it sits on Proton's end-to-end encryption, which means the underlying secrets stay encrypted and only you hold the keys. The token is a controlled, observable window into your vault, not a copy of its contents.

The part developers will care about
-----------------------------------

The tokens are not limited to chat-style agents. They work with the Proton Pass CLI, which means you can wire them into your own scripts, automation, and CI/CD pipelines using the same least-privilege, audited model. If you are the kind of person who has a cron job that needs one specific credential and you have been doing unspeakable things with environment variables to make that happen, this is a cleaner path.

You create the token in settings, copy the setup instructions to your agent, and then just ask it to do work that touches the shared items. Setup is minutes, not an afternoon.

Why this matters beyond the feature
-----------------------------------

Here is the part worth sitting with. The right mental model for an agent is privileged software. It can act on your behalf, which means it can also make mistakes on your behalf or be turned against you by someone who manages to influence its inputs. You treat privileged software a specific way: you scope what it can touch, you log what it does, and you keep a kill switch within reach.

That is exactly the shape of what Proton shipped. Scope, log, revoke. It is the credential slice of a much larger agent security stack, and it is genuinely well executed.

It is also worth being honest about what one feature does and does not cover. Credential scoping and access logging are solved here. The other layers are still yours to build: sandboxing the execution environment so a compromised agent cannot reach beyond its task, enforcing policy on what actions are even permitted, and making your audit trail tamper-evident so a record cannot be quietly rewritten after an incident. Those problems do not disappear because your secrets are scoped. But a system that gets the credential layer this right is the kind of foundation worth building the rest on top of, instead of fighting against.

For the broad category of people who were avoiding agents entirely because handing over credentials felt reckless, the calculus just changed. You can give an agent real work, watch exactly what it does with your accounts, and shut it off in one click. That is a reasonable trade, and a week ago it mostly was not on the table.

If you want to try it
---------------------

AI access tokens are included at no extra cost on Pass Plus, Pass Family, Pass Professional, Proton Unlimited, and Proton Workspace, so there is no separate add-on to buy. If you want to set up Proton Pass, you can do it here:

[https://go.getproton.me/SH2fS](https://go.getproton.me/SH2fS)

(That is a referral link. I would not point you at a credential model I thought was sloppy, and I am telling you it is a referral link so you can decide what to do with that.)

Build your agents like privileged software. Now at least the keys are under control.

metaend

---

*Originally published on [MetaEnd](https://paragraph.com/@metaend/agent-credential-problem-just-got-a-real-answer)*
