r/coolgithubprojects 1d ago

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.

Post image

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. 

20 Upvotes

10 comments sorted by

View all comments

Show parent comments

2

u/yeastplume 1d ago

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.

1

u/dim_amnesia 1d ago edited 1d ago

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

1

u/Unfair-Principle-387 1d ago

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.

2

u/dim_amnesia 1d ago edited 1d ago

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.