Hey — really like what you've done with JitAPI. The dependency graph for resolving endpoint chains is a smart approach.
We built Hermetic — it's a credential broker daemon for AI agents. Credentials stay in an encrypted vault, and when an agent needs to hit an API, the daemon makes the call itself and returns only the response. The token never touches the caller's memory.
Noticed your README calls out the plaintext auth.json situation. That's exactly the problem we solve.
The idea: add an optional auth_type="hermetic" to set_api_auth. Instead of storing a token, JitAPI stores a vault name. At execution time, it shells out to hermetic request instead of calling httpx directly.
python# today — token on disk
set_api_auth(api_id="github", auth_type="bearer", credential="ghp_abc123")
with hermetic — just a reference
set_api_auth(api_id="github", auth_type="hermetic", vault_name="github_token")
token stays in hermetic's vault, jitapi never sees it
It's a small change — one new file (hermetic_backend.py, ~50 lines), minor edits to http_executor.py, tools.py, and auth_store.py. Your ingestion and retrieval code stays completely untouched. If hermetic isn't installed, everything falls back to the existing httpx path. No breaking changes.
This gets interesting with cross-API workflows — if a workflow hits 3 different APIs, each step uses a separate hermetic secret with its own domain binding. A prompt injection can't redirect one API's credentials to another endpoint.
We're happy to write the PR if you're open to it. Just want to make sure the auth_type + vault_name contract works for you before we start.
hermeticsys.com · GitHub · dev@hermeticsys.com
Hey — really like what you've done with JitAPI. The dependency graph for resolving endpoint chains is a smart approach.
We built Hermetic — it's a credential broker daemon for AI agents. Credentials stay in an encrypted vault, and when an agent needs to hit an API, the daemon makes the call itself and returns only the response. The token never touches the caller's memory.
Noticed your README calls out the plaintext auth.json situation. That's exactly the problem we solve.
The idea: add an optional auth_type="hermetic" to set_api_auth. Instead of storing a token, JitAPI stores a vault name. At execution time, it shells out to hermetic request instead of calling httpx directly.
python# today — token on disk
set_api_auth(api_id="github", auth_type="bearer", credential="ghp_abc123")
with hermetic — just a reference
set_api_auth(api_id="github", auth_type="hermetic", vault_name="github_token")
token stays in hermetic's vault, jitapi never sees it
It's a small change — one new file (hermetic_backend.py, ~50 lines), minor edits to http_executor.py, tools.py, and auth_store.py. Your ingestion and retrieval code stays completely untouched. If hermetic isn't installed, everything falls back to the existing httpx path. No breaking changes.
This gets interesting with cross-API workflows — if a workflow hits 3 different APIs, each step uses a separate hermetic secret with its own domain binding. A prompt injection can't redirect one API's credentials to another endpoint.
We're happy to write the PR if you're open to it. Just want to make sure the auth_type + vault_name contract works for you before we start.
hermeticsys.com · GitHub · dev@hermeticsys.com