If you're running AI agents that call external APIs, you probably have API keys scattered across .env files, config directories, and maybe a Slack DM or two. It works — until it doesn't.
When running agents across OpenAI, Anthropic, AWS, and GitHub simultaneously, there are some difficult questions that cannot be answered: Which agent has access to which key? Has anything expired? When one agent delegates a key to another agent in a chain, who's actually accountable?
As an experiment, I built ID Wispera — an open-source tool that treats agent credentials like passports.
The idea
Every credential gets a structured "passport" with:
- Scope and classification — is this an access-level key or a privileged admin credential?
- Expiry tracking — when does it expire, and who gets notified?
- Delegation chain — if Human → Agent A → Agent B, that chain is recorded with optional scope narrowing at each hop
- Audit trail — every access, share, revoke, and policy check is logged
The passport/visa metaphor sounds weird at first, but it maps well. Passports have issuers, validity periods, visa classifications, and stamps showing where they've been used. Agent credentials need the same things.
What it actually does
Credential detection — Point it at a project directory and it scans for API keys across 47 vendor-specific patterns. It detects OpenAI keys (sk-proj-*), Anthropic keys (sk-ant-*), AWS access keys (AKIA*), GitHub tokens (ghp_*, gho_*), JWTs, connection strings, private keys, and more. Each match gets a confidence score so you can filter out noise.
idw detect ./my-project --min-confidence 0.8
Encrypted vault — Credentials are stored in AES-256-GCM encrypted vaults with Scrypt key derivation. Not plaintext. The vault format is cross-SDK compatible, so you can write in TypeScript and read in Python or Go.
Policy engine — Declarative rules inspired by Cedar. Set constraints like "no credential with admin scope can be delegated more than 2 hops" or "require a named human owner on every passport."
import { evaluatePolicy } from '@id-wispera/core';
const decision = evaluatePolicy(passport, 'exec');
if (!decision.allowed) {
console.log('Blocked by:', decision.rules);
}
Subprocess injection — idw exec wraps any command and injects the right credentials as environment variables, matched to each platform's expected variable names. Your agents never see the raw key.
idw exec --platform openai -- python my_agent.py
MCP server — For Claude and other MCP-compatible clients, there's a dedicated MCP server with 5 tools. Instead of reading .env files directly, Claude calls get_credential through the governance layer.
npx @id-wispera/mcp-server
The stack
- TypeScript, Python, and Go SDKs — same type system, same vault format, same patterns across all three
- 13 CLI commands (init, add, detect, import, exec, share, audit, provision, etc.)
- 8 provisioning providers — can auto-create scoped credentials on OpenAI, AWS, GCP, Azure, GitHub, Twilio, SendGrid, and Anthropic
- MIT licensed
Install
# TypeScript
npm install @id-wispera/core
# Python
pip install id-wispera
# Go
go install github.com/gecochief/id.wispera/packages/go/cmd/idw@latest
# MCP Server
npx @id-wispera/mcp-server
Where it's at
This is a v0.1. The core modules (detection, vault, policy, audit, delegation, and sharing) are tested and working. The provisioning providers connect to real APIs. The MCP server works with Claude Desktop.
It's not perfect — there are rough edges, the LangChain integration is thin, and I haven't set up Homebrew yet. But the foundation is solid and I'm iterating based on feedback.
Website: id.wispera.ai
Repo: github.com/gecochief/id.wispera
Docs: docs.id.wispera.ai
npm: @id-wispera/core
PyPI: id-wispera
If you're dealing with credential sprawl across your agent workflows, I'd genuinely appreciate feedback on whether this approach makes sense or if I'm overcomplicating things.
Top comments (0)