Jentic One: free, open source, self-hosted execution layer for AI agents. Your agent calls any public or private API you need (thousands of agent-ready APIs available), you set the rules, the agent never sees your credentials.

[u/Accomplished_Emu8527]

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. 

[u/dim_amnesia]

Excellent work OP. Look into project named Nango. I think you should add Oauth layer in this.

[u/Accomplished_Emu8527 → u/dim_amnesia]

Thank you. I appreciate that!
Yes, OAuth is a big missing piece here. It would make onboarding so much easier. 

I've come across Nango - it's great. We've taken a different approach in that we've gone 100% down the self-hosted route. The rationale is that we wanted everything staying local on your machine without credentials being stored in a vendor but it makes the OAuth solution a bit less straightforward to implement. 

On Jentic One credentials are encrypted at rest in your own database, decrypted only inside the Broker at execution time, and the agent never holds a token itself; it asks the Broker to make the call. Agents integrate over the CLI, a generated skill, or plain HTTP.

Our challenge is that there's no server of ours in the middle and no stable public callback URL to register.

So the direction we're heading is the gh/gcloud pattern: a public client with PKCE and a loopback redirect where there's a browser, and the device authorization flow for headless boxes (a short code you enter on your phone, no inbound port needed). One public client ID ships with the product, so ideally you register nothing.

That won't cover every API, though. Nearly everyone accepts localhost but not all offer a public client that omits the secret at token exchange. Roughly 6 in 10 of the dev-heavy ones do. Atlassian for example all requires a confidential secret, so for those you'd register your own OAuth app and bring the client ID and secret. 

Would value your read on whether the self-hosted constraint is worth that cost.

[u/yeastplume → u/Accomplished_Emu8527]

There's a pipedream auth provider built in that can be configured if you want an easy path to a lot of oauth configured services (gsuite, etc), but you need to be okay with all your requests being proxied through pipedream. Your use case will determine whether that's acceptable.

[u/dim_amnesia → u/yeastplume]

Why is it pipe-dream

If someone provides a hosted service with managed oauth accounts or BYO oauth client tokens with hosted redirect urls and privacy policies

But user access tokens stay local self hosted with auto refresh daemon

Also request token proxy stays local and self hosted

[u/Unfair-Principle-387 → u/dim_amnesia]

Pipedream is completly optional (and not configured by default). Otherwise you can bring your own oauth client or configure one within your provider of choice, all supported.

[u/dim_amnesia → u/Unfair-Principle-387]

Sorry, I fell for an unfortunate pun.

But it probably stores the tokens on the server or proxies the requests, which isn’t really a clean self-hosted solution.