Scottpedia0/access

> "It's kind of a nifty little utility."
> — me
>
>Once in a while, an agent needs to be reminded that this exists.
> Everything below this line was drafted by the bots.
One Bearer token, all your services.
Access gives agents and scripts secure access to OAuth and API-key-backed services without handling credentials directly. Store your secrets, refresh tokens automatically, proxy requests, audit everything — through one stable interface over HTTP and MCP.
What it does
You put every credential in it — API keys, OAuth tokens, bot tokens, agent credentials, service secrets, whatever your agents and scripts need. Then you decide who gets what.
- **Per-agent and per-fleet permissioning** — each agent or group gets its own token with scoped access. Coding agents see GitHub and Linear. Comms agents see Gmail and Slack. Ops agents see AWS. Managed from the admin UI — no config files, no CLI juggling.
- **Stores everything encrypted** — API keys, OAuth tokens, bot tokens, agent-to-agent credentials, service secrets. AES-256-GCM at rest, HMAC-hashed access tokens.
- **Handles OAuth** — token refresh, consent flows, multi-account Google — your agent never participates
- **Proxies API calls** — for services with adapters, agents hit Access and get JSON back without ever seeing the underlying key
- **Serves credentials directly** — for everything else, agents pull keys via /bootstrap or /secrets/by-env/WHATEVER
- **Logs everything** — every secret access, every API call, every auth attempt, with actor and IP
- **Bootstraps sessions** — one /bootstrap call gives an agent only what it's authorized to see — env vars, docs, and context
**The happy path:** Agent sends Bearer token → Access handles auth, refresh, and proxying → Agent gets JSON or a bootstrap bundle back. That's it.
What it looks like
**Dashboard** — services, keys, agents, and audit history at a glance:
**Agent permissioning** — each agent gets its own token with scoped access grants:
**Agent detail** — trust level, token prefix, last used, and grant count:
30-second example
With MCP, your agent gets tools like gmail_search, calendar_list, drive_list — no configuration per service, no expired tokens, no credential management.
Who this is for
**Good fit:**
- Running AI agents (Claude Code, Cursor, Gemini CLI, Codex) across multiple sessions or machines
- Multi-agent setups where agents need credentials for other agents, bots, and internal services
- Self-hosted personal or small-team setups
- Multi-service workflows where agents need Gmail, Slack, GitHub, etc.
- Anyone tired of bootstrapping agent sessions with scattered .env files
**Not a fit:**
- Enterprise secrets management with compliance requirements (use HashiCorp Vault)
- High-compliance infrastructure with KMS/HSM requirements
- Large team IAM or multi-tenant access control
**How it differs from a password manager:** 1Password stores credentials for humans to copy-paste. Access stores credentials and *uses them* — proxying API calls, refreshing OAuth tokens, bootstrapping agent sessions. Your agent never sees the raw key for proxied services.
Security posture
**What Access protects against:**
- Agents seeing or storing raw credentials
- Expired OAuth tokens breaking agent sessions
- Unaudited credential access across machines
- Plaintext secrets in databases (AES-256-GCM encryption at rest)
- Brute-force token guessing (HMAC-SHA256 hashed, constant-time comparison)
**What Access does not protect against:**
- A compromised Access instance (if someone gets your server, they get everything)
- Cloud-grade key management (no KMS/HSM integration yet — see roadmap)
- Multi-tenant isolation (this is a single-owner system)
- Network-level attacks (deploy behind HTTPS, use a firewall)
Why not just use .env files?
- **OAuth tokens expire.** Google access tokens last 60 minutes. Your agent can't refresh them — Access can.
- **Credentials scatter.** Each agent session needs its own copy. Rotate a key and you're updating it in 6 places.