Every AI agent you build needs to reach something real: a SaaS API, an internal service, the database on your own machine. And every time, you hit the same two walls.
First, the keys. To let an agent call Stripe or Slack or your internal API, you paste the key somewhere the agent can read it: a .env file, your n8n credentials, a Cursor config, a Home Assistant secrets.yaml. Do this across a few projects and the same secret ends up in a dozen places. Rotating one key turns into an afternoon of editing config files, and you still miss one and find out a week later when something quietly returns 401.
Second, the network. Half the services you actually want an agent to use run on your own machine or inside your network. But the agent runs in the cloud, and the cloud can't reach your localhost. Now there's a networking problem stacked on top of the credential problem.
NyxID is the layer that handles both.
What NyxID is
NyxID is an open-source Agent Connectivity Gateway: it sits between your AI agents and the APIs they need to reach, holds the real credentials itself, and hands each agent only a scoped token. Your agent talks to NyxID; NyxID talks to the real API with the real key. The key is decrypted and injected at the gateway, so it never lands in the agent's context, its prompt, or its config.
It's Apache-2.0, and you can self-host the whole thing (three Docker containers) or use the hosted version. Either way, you own the trust boundary.
What it does
A few things, and they compose:
- Injects credentials so the agent never sees them. You paste an API key into NyxID once; it's stored encrypted (AES-256-GCM). From then on the agent calls through NyxID, which injects the key at request time. The agent gets the response, never the secret.
- Reaches services behind NAT, including your localhost. A small credential node runs on your own infrastructure and dials out to NyxID over an outbound connection. No VPN, no port forwarding, no hole opened in your firewall. A cloud agent can now call a service running on the machine under your desk.
- Turns REST APIs into MCP tools. Point NyxID at an API's OpenAPI spec and it surfaces each operation as an MCP tool on a single endpoint, with no hand-written MCP wrapper per service. Works with Claude Code, Cursor, VS Code, Codex, and n8n.
- Isolates every agent. Each agent gets its own scoped token. Agent A can reach Slack and Gmail; Agent B only your internal API. Revoke any agent's session without touching the underlying credentials or disturbing the others.
- Lets you decide what an agent does on its own, and what needs your yes. Turn on approval and, by default, every proxied call waits for your explicit OK: a Telegram or mobile-push prompt shows exactly what the agent is about to do (POST /v1/chat/completions, model gpt-4o, 3 messages), and the call only runs if you approve, auto-rejecting after a timeout you set. Then tune it per service: exempt the harmless ones, keep the checkpoint on the calls that touch money or production, or grant an agent a service for a set window so it stops re-prompting.
What actually changes for you
The clearest way to feel the difference is before and after.
Before: the secret lives wherever the agent can read it. It's copied across .env files and tool configs, it sits in the agent's execution memory for the length of a run, and an agent with a prompt-injection surface has the full blast radius of whatever that key unlocks. Rotation is manual and easy to get wrong.
After: the secret lives in one place behind the gateway, and the agent never holds it. You add a service once and wire a single MCP endpoint. The agent makes the call; the key stays on your side. And for the calls that actually matter, you can require a checkpoint: the agent pauses, asks, and waits for your approval before anything happens. As one early builder put it, NyxID "moves the complexity from the agent side to the infra side, where it belongs." Day to day, that means you stop tracking where your keys are, and you can hand an agent real access without that access turning into a liability.
Who it's for
Anyone wiring AI agents into a real stack: self-hosters and homelab folks who want Claude Code or Cursor to reach services behind their firewall; teams who've watched the same API key spread across n8n, Cursor, and three .env files; builders who want per-agent, revocable access instead of one master key shared everywhere. If you run self-hosted tools like Grafana, Jenkins, n8n, or Home Assistant and want an agent to use them without leaking the credentials, that's the case NyxID was built for.
Why it matters
Agents are starting to act in the real world: calling paid APIs, touching internal systems, spending money. The moment they do, two questions stop being details and become the whole risk: where does the key live and who can see it, and what is the agent allowed to do with it unsupervised. NyxID's bet is that both belong in infrastructure you control and can audit, open-source and self-hostable, with the key on your side of the line and a human checkpoint on the actions that count, rather than a master key pasted into every agent that needs a job done.
Try it
NyxID is open-source (Apache-2.0) and live at GitHub: github.com/ChronoAIProject/NyxID.
Self-host the three containers, or request hosted early access with invite code NYX-OJWGP4FZ. https://nyx.chrono-ai.fun/register
Wire your first agent with one command:
Install nyx skills from https://github.com/ChronoAIProject/NyxID/blob/main/skills/INSTALL.md
Top comments (0)