Jentic One: Secure Agent API Execution, Tested

The verdict — if you’re trying to let internal agents call a few external APIs without putting long-lived keys in prompts, Jentic One is worth a sandbox pilot on a separate host, not production. The architecture is the right shape: a broker injects credentials at execution time, access is default-deny, and the project’s own security guide is refreshingly clear that a same-user agent can still read host-resident secrets. But the 21 August 2026 hands-on run exposed release/docs drift, a default-port collision that made health checks misleading, and an onboarding gate that stopped an end-to-end call without credentials. Don’t use it as proof that your agents are production-ready.

Jentic One is a self-hosted execution layer between your agents and external APIs. The vendor describes two planes: an App control plane (registry, admin, control) and a stateless Broker data plane that injects stored credentials into outbound requests. It’s Apache-2.0 and labelled public beta; the README says APIs, schemas, and CLI commands may change without a major-version bump. Jentic One README (captured 21 August 2026 in mining/jentic/repo-docs/README.md).

The problem: agents need constrained API work, not more keys

Picture a small platform group: a support triage agent that only reads tickets, a billing assistant that creates invoices but never refunds, an operations assistant that delivers webhooks to specific endpoints. Today each integration is an environment variable or a secret-manager lookup inside the agent runtime. After a bad prompt, you can’t answer the practical question: which upstream request actually left, under which policy, with which credential?

Jentic’s landing page answers that leak: the agent discovers an operation, the broker checks rules, injects a stored credential at execution time, and logs the call. Writes are never allowed by default. Those are vendor claims, not results from this run. mining/jentic/landing.md, captured 21 August 2026.

The real decision isn’t “do we want an API catalog?” It’s whether you’ll operate a stateful authorization and credential service. Jentic’s own hardening guide makes the boundary concrete: injecting credentials over the network path doesn’t stop an agent running as the same OS user from reading the database or encryption key off disk or memory. For real credentials, its recommended tier is a separate host or private network. security hardening guide.

That warning earns more trust than a “never sees credentials” headline. It also changes the pilot design: a laptop-local demo validates the control flow, but not the promised host isolation.

How it’s supposed to make a call visible

The repo divides the work across four surfaces: the Broker receives a request, injects the credential, forwards it, and returns the upstream response; the Registry holds API specs and operations; Control stores credentials; Admin owns permissions, audit, and execution telemetry. mining/jentic/repo-docs/README.md, captured 21 August 2026.

The documented self-hosted flow is deliberately more restrictive than “paste a key and call an endpoint”:

1. Install jenticctl and jentic, deploy the local stack.
2. Create the first administrator.
3. Register an agent identity — an Ed25519 keypair, dynamic client registration, then wait for operator approval.
4. Import an API spec and store its credential once.
5. Request agent access; an operator grants the binding and rules.
6. Execute the operation through the Broker.

The repo’s agent instructions use GET:https://httpbin.org/get --json as the non-sensitive first call, but only after import, access request, and grant. That gives you a clean acceptance criterion: an allowed GET should complete and land in history; a disallowed method or path should fail before it reaches upstream. mining/jentic/repo-docs/AGENTS.md, captured 21 August 2026.

Component	Operator job	Evidence status
Broker	Inject and forward credentials	Vendor/source-described; not live-verified
Registry	Hold API specs and operations	Vendor/source-described; not live-verified
Control	Store credential objects	Vendor/source-described; no secret stored
Admin	Approve identities and access	Setup gate observed; no admin created

A Stripe key sitting in the agent process can refund if the key can refund. A Jentic policy is meant to separate “can authenticate to Stripe” from “may call this operation.” Unverified: this evaluation created no Stripe credential, policy, or deny rule, so it proves nothing about rule evaluation, audit retention, or encryption.

What actually ran on 21 August 2026

I ran Jentic’s published bootstrap on an Ubuntu 25.04 test host inside tmux, the way the installation pathway specifies:

curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Bootstrap finished with exit 0 in 6.224 seconds. It resolved jentic/[email protected] (commit 8e235f5), built both jenticctl and jentic, and installed them. The installed binaries then reported dev (commit none, built unknown) — not a release version. mining/jentic/evidence/install-log.md.

Context for the host: Docker 29.2.1, 60 GiB RAM (46 available at the first snapshot), 707 GiB free disk. The initial command used an already-downloaded Go 1.26.2 toolchain, so this isn’t a first-time download measurement.

The piped install had no TTY, so the installer skipped its wizard and printed jenticctl install --defaults as the follow-up. Running it produced a Docker/Postgres manifest for source v0.31.1 — but status reported the expected control plane and Broker offline. mining/jentic/evidence/stack-install-log.md.

That’s not a clean “stack works” receipt. The host already had unrelated workloads on the documented loopback defaults: a probe to 127.0.0.1:8000/health returned HTTP 200 from uvicorn, while Jentic’s components weren’t listening there. Existing Jentic Docker containers were bound to a non-loopback address and different ports, so they weren’t a safe stand-in. mining/jentic/evidence/cli-and-probes.md; mining/jentic/evidence/stack-inspection.md.

Failure modes that changed the decision

Three breakpoints mattered. None is a claim about every deployment, but each is reproducible enough to belong on a pilot checklist.

Failure mode	What happened	Operator impact	Receipt
Release/docs drift	--answers was unknown	Documented isolation path failed immediately	evidence/isolated-stack-evidence.md
Default-port collision	Port 8000 answered another Uvicorn app	Doctor could treat wrong service as reachable	evidence/cli-and-probes.md
First-admin gate	Setup requires email and password	No governed call without operator-owned credentials	evidence/isolated-stack-evidence.md

Release/docs drift. The current source docs say unattended install supports --defaults or --answers <file>, including custom ports in the answer file. The freshly installed CLI’s install --help listed neither — it offered --fresh-secrets, --no-start, --no-wizard, --out, and --skip-build. An isolated port plan died in 0.00 seconds with error: unknown flag: --answers. That is the kind of breakage the public-beta warning already tells you to expect. mining/jentic/evidence/isolated-stack-evidence.md; CLI source documentation, captured in mining/jentic/repo-docs/cli__README.md.

Port collision and false confidence. The default control-plane port answered with HTTP 200 from some other Uvicorn service, while Jentic’s status said its service was offline and the isolated-home doctor reported that same endpoint “running.” A health check that only proves “something returns 200 here” isn’t enough on a shared host. Before onboarding an agent, verify Jentic-specific response content, the Docker Compose project and container identity, and the configured bind address — not just an open port. A host-layout lesson, not evidence of a Jentic vulnerability.

Operator setup is a real gate. jenticctl setup --help says it creates the first administrator only while no users exist, and requires an operator email and password. jentic register --help says agent registration waits up to five minutes by default for operator approval before minting tokens. I didn’t supply an email, password, API key, or third-party credential, so I didn’t bypass the gate. This also explains why Jentic’s cloud docs can’t serve as a self-hosted quickstart receipt: the docs-site quickstart requires a free Jentic account at app.jentic.com. That path wasn’t attempted. mining/jentic/docs-quickstart.md, captured 21 August 2026.

What this test establishes — and deliberately does not

The positive receipt is small but useful: the published bootstrap fetched a release ref, built both CLI binaries, and completed without an account, API key, payment screen, or email gate. You can get to the local lifecycle tooling from the published command. It does not prove that the resulting server was the service receiving traffic on the default port (a different Uvicorn process was already there), nor that the installer’s version string, docs, and stack release were aligned — the binary said dev, the manifest said v0.31.1.

The negative receipts are more useful than an installer screenshot. The installed CLI rejected a documented --answers option: you can’t safely copy a main-branch recipe into an environment with port conflicts and assume the binary understands it. Don’t improvise flags or hand-edit generated, secret-bearing config until it works. Pin the exact release tag, archive the --help output with the config, and use a disposable host.

A second boundary is authorization. Jentic’s model is more than an API key: first admin, agent identity, dynamic client registration, approval, imported API, access request, binding, rule. That ceremony is the reason to consider the product — it creates review points that plain environment variables lack. It’s also a cost, so write down who owns each step before the pilot: the infra operator owns the server and key path, an integration owner owns each upstream credential, and a policy owner approves what the agent may call. The self-hosted connection-maintenance case argues the same direction for credentials generally: the durable cost of a credential system is its maintenance loop, not its setup.

One more constraint is easy to miss: Jentic One is a governed one-upstream-call execution layer, not a workflow orchestrator. Its agent instructions say to compose multi-step work outside the Broker. “Find the ticket, fetch the customer, create a follow-up, notify Slack” is not one broker transaction — it’s a sequence that needs its own retries, idempotency, state, and compensation. The automation-choice guide makes the parallel point: an automation is only cheap while its failure is cheap. Jentic can decide whether a particular HTTP operation is allowed and inject its credential; the durable multi-step state belongs to your runner, not the broker.

A practical deployment boundary

For a no-risk demo, a local same-user install is fine: nothing sensitive enters the machine. The moment you add even a low-value sandbox credential, the choice changes. Jentic’s hardening guide calls local same-user use T0, sandboxing the agent T1, separate users on one host T2, and a separate private host/network the recommended T3 posture. Those labels come from Jentic’s guide, not an independent certification.

Posture	Suitable work	Principal caveat	Pilot decision
Same user	Credential-free UX demo	Agent can read key/DB	Don’t add real secrets
Separate user	Small local sandbox	Shared kernel remains	Only with sandbox controls
Separate host	Team pilot, sandbox credentials	Requires private routing	Preferred test shape
Public endpoint	None by default	Expands exposure unnecessarily	Don’t use for pilot

The recommended shape means a dedicated non-root service identity, a private route between agent and broker, TLS termination for that route, and durable audit collection. Jentic lists those controls in its hardening checklist, including keeping the encryption key out of committed files. None were configured or verified in this run, so don’t read the guide’s existence as implementation proof.

Test the failure path outside Jentic too: if the Broker is unreachable, what does the agent do? Usually fail closed for a privileged API, record the job as blocked, ask a human — not quietly fall back to an environment variable. Unverified: no broker outage was exercised here; it’s on the pilot list because it follows the boundary, not because the docs promised an SLA.

When not to use it

Don’t deploy Jentic One just because agents use APIs. First ask whether a provider-issued scoped token in a conventional service boundary covers the need. If the agent doesn’t need dynamic discovery, multi-API cataloging, operator approval, or centralized audit, a new control plane adds more operational surface than it removes.

Don’t put real production credentials into a same-user local evaluation — the project’s own Tier 0 guidance calls that try-it-out only, and warns against high-value credentials. Don’t expose the instance publicly for laptop-CLI convenience; the hardening guide recommends private networking, VPN, private DNS, or an authenticated proxy.

Finally, don’t choose it today if your pilot can’t pin and validate one release artifact. The installation result and main-branch docs disagreed on flags. That doesn’t make the project unusable; it means you need a release-pinned runbook, a checksum verification step, and a rollback plan before it becomes a security dependency.

Bottom line

Jentic One deserves a sandbox pilot when the actual problem is controlled API execution by agents — not just secret storage. The architecture, and the explicit same-user warning, show a product that understands the trust boundary it’s trying to enforce. The receipts show why it should stay in a release-pinned, isolated evaluation: the bootstrap worked, but a documented install option was missing from the installed CLI, a default health probe collided with another service, and the onboarding gate blocked a credentialed execution test.

Keep it for a controlled, separate-host pilot. The moment you put real credentials behind the gate, verify the gates yourself: an allowed call that logs, a denied call that never reaches upstream, and a revocation that actually fails the old token. Until those are proven with your own receipts, treat the broker, audit, policy, and encryption claims as vendor-described, not production-verified.