jentic one · execution layer

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.

Install Jentic OneView on GitHub (opens in a new tab)

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.

# one server · many agents · each with its own identity

Install and Connect

Jentic One is a server your agents connect to as clients. Install it once on a machine you control, check the agent can reach it, then register each agent from wherever it runs — never on the instance’s own machine, where a local process could read the stored keys directly.

step 1stand up the server

On the machine that will host your instance. A setup wizard stands up the server, in Docker or a plain Python environment, your choice.

$ curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
step 2reach it from the agent side

The instance is a normal HTTP server. From wherever your agent runs, check you can reach it before wiring anything.

$ curl http://<your-instance-host>:8000/health
step 3register the agent

Where your agent runs, kept off the instance’s machine so it can never read the stored keys. Install the CLIs only (no server wizard), then give the agent its own identity.

$ curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | JENTIC_NO_INSTALL=1 sh$ jentic register  # gives this agent its own identity on your instance

Just evaluating? A single local install is fine to start.Before real credentials go in, see the secure deployment guide (opens in a new tab) for the separation 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.

Install Jentic OneStar on GitHub (opens in a new tab)