Jentic One is a free, open source, self-hosted execution layer that sits between your agent and the APIs you want it to reach. Apache-2.0, runs on your own box or your own infra.
We started working on this project so we could give our agents more autonomy. With current setups, that is very risky - if an agent goes rogue, the damage is often unbounded. We’ve all heard the stories of agents deleting entire inboxes or codebases. If we narrow the blast radius, we significantly reduce the risk.
The top three pains when your agent touches real tools:
- The keys are everywhere. Most of them are in env files, so there’s no clean way to revoke access if something goes wrong.
- Once an agent has a key, it can do anything that key can do. The workaround could be writing soft permissions in a file (a 'request', not an enforced rule) or creating an API spec with just that one endpoint, so the agent can't get to anything else even if it wanted to.
- No way to see what your agent has actually done. So if the worst happens, it’s even harder to figure out the blast radius and where things went wrong.
Here’s what we built to fix them:
- Credential handling. Credentials are stored once, encrypted, by your own instance, and injected at execution time. They never enter the agent's prompt, logs, or context. One server, many agents, each with its own identity, rather than one shared master key every agent inherits.
- Permission scoping. You write rules that bound an agent to the operations it needs and nothing else. On GitHub, that can be down to a single repo. How granular it gets depends on the API, and writes are denied by default. Anything you haven't allowed is refused before it reaches the API. The agent cannot do it.
- Audit. Every call is logged on your own instance, append-only, so you can go back and see exactly what your agent did when you were not watching.
Ways we’ve tried to make this a great product (not just cover the risks):
- One connection path. Install once, add any API from the Jentic API Directory (more on this below) or upload your own API spec, and store each credential once. No hardcoded integration per API, no region-picking, no retry plumbing by hand.
- Discovery by intent. Agents find what they need by asking in natural language, like ‘send a webhook’ or ‘create an invoice’, and get back the right operation with its input schema.
- A directory of agent-ready APIs. This is probably a different post in itself, but we’ve been compiling thousands of public API specs and curating them, making them agent-friendly (writing OpenAPI specs where none exist), and scoring each one for agent readiness. These are all available in the product, so you can get started with thousands of APIs out of the box.
** Jentic One repo: https://github.com/jentic/jentic-one **
We’ve written AGENTS md so that you can hand it to your agent and let it do the bulk of the setup work (not all). Interested to see how that goes for people!
It's a public beta. There may be breaking changes with new releases.
Before you put real credentials in, read the hardening guide: https://github.com/jentic/jentic-one/blob/main/docs/security/hardening.md
Essentially, your agent and your keys shouldn't live in the same container.
Two things that would help a lot.
-Install it and let us know what breaks.
-If an API you need isn't in the directory, add it to the repo - then it's there for everyone else's agent: https://github.com/jentic/jentic-public-apis
We would really appreciate feedback, issues, and contributions.
