OneCLI's Credential Gateway: How to Keep Secrets Out of Agent Context Without Breaking Tool Execution

Traditional secret vaults hand credentials to callers and trust them to keep secrets safe. That model breaks when the caller is an LLM agent that logs every token, serializes state to disk, and can be tricked into echoing context back to an attacker. OneCLI solves this by never giving secrets to agents at all. Instead, it intercepts tool calls, injects credentials server-side, executes the action, and returns only the result.

The project hit 110 points on Show HN with a clear pitch: agents should never see OAuth tokens, API keys, or database passwords. OneCLI acts as a credential gateway that sits between the agent and external APIs. The agent requests an action (send email, create GitHub issue, query Notion), the gateway checks approval rules, injects the credential, makes the call, and hands back sanitized output.

The Interception Architecture

OneCLI runs as a local daemon or remote service. Agents communicate through a sandboxed harness that exposes tool definitions but not the underlying secrets.

Flow:

Agent generates a tool call (e.g., github.create_issue(repo="onecli/onecli", title="Bug report")).
Harness intercepts the call before execution.
Gateway looks up the credential mapping for that tool and user.
If approval is required, the call blocks and notifies the human via chat interface.
On approval, gateway fetches the OAuth token from its vault, injects it into the API request, and executes.
Response is sanitized (no token leakage in headers or error messages) and returned to the agent.

The agent never receives the token. It only sees the tool definition and the result.

Key components:

Harness: Sandboxed execution environment that wraps agent runtime.
Gateway: Credential injection layer with approval logic.
Vault: Encrypted storage for OAuth tokens, API keys, and connection strings.
Approval Queue: Human-in-the-loop gate for sensitive actions.

OAuth Flow Without Token Exposure

OneCLI handles OAuth on behalf of the agent. When a user connects a service (GitHub, Gmail, Notion), the OAuth flow happens outside the agent’s context.

Setup flow:

User initiates OAuth via OneCLI UI or CLI.
OneCLI redirects to the provider’s authorization endpoint.
User grants permissions.
Provider redirects back to OneCLI with authorization code.
OneCLI exchanges code for access and refresh tokens.
Tokens are stored in the vault, scoped to the user and service.

Runtime flow:

Agent requests a tool that requires GitHub access.
Gateway retrieves the user’s GitHub token from the vault.
Gateway makes the API call with the token in the Authorization header.
Response is returned to the agent without the token.

If the token expires, OneCLI uses the refresh token to get a new access token. The agent never knows this happened.

Approval Gates and Failure Modes

OneCLI supports synchronous and asynchronous approval patterns. For high-risk actions (delete operations, financial transactions), the gateway can block execution until a human approves.

Approval patterns:

Pattern	Use Case	Latency	Failure Mode
Auto-approve	Read-only operations, low-risk writes	None	Agent proceeds immediately
Sync approval	Interactive chat sessions	Seconds to minutes	Agent waits, times out if no response
Async approval	Background tasks, scheduled jobs	Minutes to hours	Task queued, retried on approval
Deny by default	Sensitive operations, untrusted agents	N/A	Call fails, agent receives error

Failure scenarios:

Agent hallucinates a tool call: Gateway rejects unknown tools. Agent receives a structured error.
Agent requests a credential it shouldn’t have: Gateway checks user-to-service mappings. If no mapping exists, call fails closed.
Token revoked mid-session: Gateway catches 401 responses, attempts refresh, and fails the call if refresh fails. Agent sees a retryable error.
Approval timeout: Configurable timeout (default 5 minutes). Call fails with timeout error. Agent can retry or escalate.

OneCLI fails closed. If the gateway can’t verify credentials or approval, the tool call does not execute.

State Management and Credential Scoping

OneCLI stores credential mappings in Postgres. Each mapping ties a user, service, and scope together.

Schema (simplified):

CREATE TABLE credential_mappings (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  service TEXT NOT NULL, -- 'github', 'gmail', 'notion'
  scope TEXT[], -- ['repo', 'read:user']
  access_token TEXT ENCRYPTED,
  refresh_token TEXT ENCRYPTED,
  expires_at TIMESTAMP,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
);

CREATE TABLE approval_rules (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  service TEXT NOT NULL,
  action_pattern TEXT, -- 'github.delete_*', 'gmail.send'
  approval_required BOOLEAN,
  approvers UUID[] -- list of user IDs who can approve
);

When multiple agents share the same integration, each agent’s tool calls are scoped to the user who initiated the session. OneCLI does not support cross-user credential sharing by default. If an agent needs to act on behalf of multiple users, each user must connect their own OAuth flow.

Rotation:

Access tokens are rotated automatically using refresh tokens.
Refresh tokens are rotated when the provider issues a new one (GitHub, Google).
If a user revokes access via the provider’s UI, OneCLI detects the 401 and marks the credential as invalid.

Observability and Audit Logs

OneCLI logs every tool call, approval decision, and credential access. Logs are structured JSON, suitable for ingestion into a SIEM or observability platform.

Log fields:

timestamp: ISO 8601
user_id: UUID
agent_id: UUID or session ID
service: github, gmail, etc.
action: create_issue, send_email
approved_by: UUID or auto
result: success, denied, timeout, error
error_message: If result is error

Logs do not include credential values or token fragments. They do include the tool call parameters (sanitized) and the response summary.

Metrics to track:

Tool call latency (p50, p99)
Approval wait time
Token refresh rate
Failed calls by error type
Credential revocations

Deployment Shapes

OneCLI supports three deployment modes:

Local daemon: Runs on the developer’s machine. Credentials stored in local encrypted vault. Suitable for single-user, development workflows.
Self-hosted service: Deployed as a Docker container or Kubernetes pod. Postgres backend for multi-user credential storage. Suitable for teams.
Managed cloud: OneCLI hosts the gateway. Users connect OAuth flows, and the gateway runs in OneCLI’s infrastructure. Suitable for teams that don’t want to manage infrastructure.

Local daemon setup:

# Install OneCLI CLI
curl -sSL https://onecli.sh/install.sh | sh

# Start the gateway
onecli start

# Connect a service
onecli connect github

# Run an agent with OneCLI harness
onecli run --agent my-agent.py

Self-hosted setup:

# docker-compose.yml
services:
  onecli-gateway:
    image: onecli/gateway:latest
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/onecli
      ENCRYPTION_KEY: <generate-with-onecli-keygen>
    ports:
      - "8080:8080"
  
  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: onecli
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Security Boundaries

OneCLI’s threat model assumes:

The agent runtime is untrusted. It may log context, serialize state, or be compromised by prompt injection.
The gateway is trusted. It runs in a secure environment with encrypted storage.
The human approver is trusted. They understand the action being approved.

Attack surfaces:

Prompt injection: Agent is tricked into requesting a malicious tool call. Mitigated by approval gates and deny-by-default rules.
Gateway compromise: Attacker gains access to the gateway’s database. Mitigated by encryption at rest and access controls.
Token leakage in logs: Agent logs the tool response, which includes sensitive data. Mitigated by sanitizing responses and configuring log retention.
Replay attacks: Attacker captures a tool call and replays it. Mitigated by short-lived tokens and approval expiration.

OneCLI does not prevent an agent from exfiltrating data it legitimately accessed. If an agent reads a Notion page and logs the content, that’s outside OneCLI’s scope. The goal is to prevent credential leakage, not data leakage.

Technical Verdict

Use OneCLI when:

You’re building agents that need to call external APIs with OAuth or API keys.
You want to enforce human-in-the-loop approval for sensitive actions.
You need multi-user credential management without sharing tokens across agents.
You’re deploying agents in environments where logging and state serialization are unavoidable.

Avoid OneCLI when:

Your agent only needs read-only access to public APIs (no credentials required).
You’re building a single-user prototype and can manage secrets manually.
Your orchestration platform already has a credential injection layer (e.g., Temporal with encrypted payloads).
You need sub-second latency for tool calls (approval gates add latency).

OneCLI solves a specific problem: keeping secrets out of agent context without breaking tool execution. It’s not a general-purpose secret manager. It’s a gateway designed for the agent use case, where the caller is untrusted and the action needs human oversight.

Agentic AI, minus the noise.