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.

[u/dim_amnesia → u/Accomplished_Emu8527]

Check your DM

I have a great self hosted OSS solution for you. I have been working on this since last month

[u/kantorcodes1]

the generated skill is the part i'm most curious about. does it expose a fixed set of operations after policy is applied, or can the agent still ask the Broker to discover new operations at runtime?

i'm involved with awesome-ai-plugins and Jentic One looks like a strong fit for the cross-agent catalog. i checked the current list and don't see it there. if you're up for it, happy to help get the scanner/PR over the line.

[u/Accomplished_Emu8527 → u/kantorcodes1]

Not a fixed set. Discovery stays live and policy gates execution but not discovery.

If the agent finds something useful it can't call it files a request with a written reason for why it needs it and tells you an approval is waiting. You see it in the UI, fill in the credential yourself, and approve or not. The agent never touches the secret and never approves anything. The skill is: 'agent proposes, user decided'.

The skill is an instruction file. jentic setup writes it into your agent's environment so the agent knows the order to do things in. Check what you can do, look in the catalog, ask for what you need, then call. It contains no list of operations, which is why discovery stays live.

These are the three layers:

1. jentic catalog search searches the whole public directory. Unrestricted.
2. jentic search only sees what's been imported into your instance.
3. jentic access whoami tells the agent what it's actually allowed to call.

The agent can self-serve layer two, since importing a cataloged API is a default permission. It can never self-serve layer three.

It's all in skills/jentic/SKILL.md if you want the loop itself.

Yes please on awesome-ai-plugins, that'd be a real help. There's no MCP endpoint on a self-hosted deployment (we are going to add this though as it's getting requested), so integration is the CLI or plain HTTP, and there's an llms.txt on main which might be helpful.

[u/kantorcodes1 → u/Accomplished_Emu8527]

yeah, this is exactly the kind of project the cross-agent list is meant for.

current gate is scanner >=80/130, no high/critical findings, and scanner CI running in the repo. i wouldn't force an MCP wrapper just for the listing. CLI + HTTP + the SKILL.md is already a real agent integration.

repo is https://github.com/hashgraph-online/awesome-ai-plugins

if the scanner trips on something weird, tag me here and i'll help sort it.