jentic> give your agent --everything-it-needs --never-the-keys
Connect Your Agent to Any API
Jentic One is a self-hosted execution layer for AI agents: your agent calls any public or private API you need, you set the rules, and it never sees your credentials.
# default deny · first match wins✓ agent_billing · POST /v1/invoices → 201 completed · 842ms · logged✗ agent_billing · POST /v1/refunds → denied by rule tpr_02 · never left the broker
open source, Apache-2.0, and in public beta · feedback is welcome on github · every call logged, on your instance
Thousands of APIs in the Jentic API Directory.
every one of them scoped and logged before your agent calls itjentic> open --directory →jentic> inspect --the-problem
Handing an Agent Your Keys Is Risky
- 01
Keys scattered across configs and env files, with no clean way to revoke access.
credential sprawl - 02
Once an agent has a key, it can do anything that key can do.
no way to constrain an agent - 03
You cannot see, after the fact, what your agent actually did.
no audit trail
Jentic One is the layer that fixes all three.Connection is the part you set up first; control, credential handling, and audit ride underneath it.
jentic> describe --what-it-does
Four Things Jentic One Handles
One Connection Path
Install once, add any API from the Jentic API Directory, and store each credential once. No hardcoded integrations per API, region-picking, or retry plumbing by hand.
Permission Scoping
Write rules that bound an agent to the operations it needs, and nothing else. How granular this gets depends on the API. Writes are never allowed by default.
Credential Handling
Credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
Discovery by Intent
Agents find what they need by intent, like "send a webhook" or "create an invoice", and get the right operation with its input schema.
jentic> install --two-machines
Install and Connect
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
# On the machine that will host your Jentic One instance:curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
# On the machine where your agent runs (keep this separate from the instance):curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | shjentic register # connects your agent to your Jentic One instance
Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide (opens in a new tab) for the tiers.
jentic> audit --why-trust-it
Built for Security From the Start
Self-hosted. Runs on your own infrastructure; credentials stay local.
Open source, Apache-2.0. Public repo on GitHub.
Encrypted at rest. AES-256-GCM, injected only at execution time.
Two-machine design. The agent cannot read the instance's stored credentials directly.
Every call is logged. An audit trail of what the agent did.
Backed by the Jentic API Directory. Thousands of validated OpenAPI specs to search and call.
jentic> start
Start With Jentic One
Jentic One is in public beta. Issues and feedback are welcome on GitHub.