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.

illustrativethe same call, two rules
# 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.

step 1jentic one host machine
# On the machine that will host your Jentic One instance:curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
step 2agent machine
# 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.