----------------
🎯 AI: Giving Agents Token Access Without Credential Leakage
===================
A recent Hebrew-language guide on internet-israel.com lays out a practical pattern for giving AI agents access to live credentials, banking, email, messaging, without handing raw tokens to the LLM runtime. The threat model and the architecture are both worth restating for anyone running local agents.
The threat model
The failure mode isn't only prompt injection in the classic sense; it's credential sprawl across agent sessions. Instructions written in markdown files, “bank: read only”, “email: drafts, never send”, are probabilistic constraints, not enforced boundaries. Agents ignore them sometimes. The guide gives a concrete scenario: a local agent with read-only bank access for anomaly alerts looks harmless on its own, but a separate Claude Code session, building a money-transfer system for a client, will go hunting for tokens and passwords in neighboring projects and env files to “test” its own work. The author references a similar incident involving Yuval Avidani. And it's not just model misbehavior: humans and bots scanning a machine for credentials in environment variables and dotfiles are the same class of problem.
The proposed architecture
The core move is separation:
1. A deterministic tool performs the actual data access (“mining”) or the actions, and holds all secrets.
2. Secrets live in a secrets manager, never in env variables.
3. The vault can be opened only by the user running the deterministic tool.
4. The agent runs in a separate process, under a different OS user, with no access to the key manager or to the tool that opens it. The agent triggers the tool or, preferably, consumes only its outputs.
Net effect: the model gets data and artifacts, not keys.
Implementation
The implementation shown uses Bitwarden Secrets Manager:
• Free tier is sufficient for personal use.
• Secrets become reachable from any machine: local computer, VM, Raspberry Pi, cloud box, VPS, instead of being tied to one machine's env.
• Setup: if a Bitwarden account already exists, create a new organization rather than a new account. In the Admin Console go to Billing → Subscription, mark “Subscribe to Secrets Manager” under “More from Bitwarden”, submit.
Known limits
The author flags this plainly: the scheme is not as strong as OIDC or delegation-based methods. Many services don't support OIDC at all, which is exactly why a vault-based pattern stays relevant. It's positioned as secure enough for home or non-professional use, easy to install, and a real barrier against opportunistic scanning by humans or bots. The load-bearing element is OS-level isolation: if the agent process and the vault-opening tool share a user, the separation collapses.
Takeaway
This is least privilege applied to agent tooling: capabilities move into deterministic, auditable code, and the model receives results, not credentials. Whether it holds against a fully compromised user account is a different question, and the author doesn't claim otherwise. As a default for personal agent setups where OIDC isn't available, it's a sensible floor. Full walkthrough (Hebrew) at internet-israel.com, with a video covering the setup.
🔹 AIAgents #LLMSecurity #SecretsManagement #Bitwarden #CredentialSecurity