Traditional secret vaults hand credentials to agents on demand, trusting them not to leak. OneCLI replaces that trust boundary with a proxy architecture: it executes privileged commands without ever exposing secrets to agent memory, logs, or context windows.
This matters because prompt injection and context exfiltration attacks target the agent’s reasoning layer. If an agent never sees the credential, it cannot be tricked into revealing it.
The Vault Problem for Agents
Standard vault patterns (HashiCorp Vault, AWS Secrets Manager, Doppler) solve human access control. An agent requests a secret, the vault checks policy, and the secret lands in the agent’s memory. From that point forward:
- The credential sits in the agent’s context window
- It appears in tool call parameters
- It may leak through prompt injection
- Logs and traces capture the plaintext value
- The agent can accidentally echo it in responses
You can scrub logs and limit context retention, but the fundamental issue remains: the agent holds the secret.
OneCLI’s Execution Proxy Model
OneCLI sits between the agent and the target service. Instead of returning a credential, it accepts a command template and executes it with injected secrets.
Flow:
- Agent decides it needs to run
aws s3 ls s3://bucket-name - Agent calls OneCLI with the command structure (no credentials)
- OneCLI retrieves the AWS key from its internal vault
- OneCLI executes the command with credentials injected
- OneCLI returns stdout/stderr to the agent
- Credentials never enter agent memory
The agent sees the result, not the secret.
Architecture Components
| Component | Role | Security Boundary |
|---|---|---|
| Agent runtime | Reasoning, tool selection | Untrusted (prompt injection risk) |
| OneCLI gateway | Command execution, credential injection | Trusted (isolated from agent context) |
| Internal vault | Secret storage (file, env, or external vault) | Trusted (OneCLI-only access) |
| Target service | AWS, GitHub, database, etc. | Receives authenticated requests |
| Audit log | Command templates + results (no secrets) | Safe to store and analyze |
The security boundary moves from “agent has secret” to “gateway has secret, agent has execution capability.”
Implementation: Command Interception
OneCLI defines a command registry. Each entry maps a tool name to a command template with placeholder slots for secrets.
Example registry entry (conceptual):
tools:
- name: aws_s3_list
command: "aws s3 ls {bucket}"
credentials:
- type: env
key: AWS_ACCESS_KEY_ID
source: vault://aws/prod/access_key
- type: env
key: AWS_SECRET_ACCESS_KEY
source: vault://aws/prod/secret_key
allowed_params:
- bucketWhen the agent calls aws_s3_list with bucket=s3://my-data, OneCLI:
- Validates the tool name and parameters
- Retrieves credentials from the vault
- Injects them as environment variables
- Executes
aws s3 ls s3://my-datain an isolated subprocess - Returns output to the agent
The agent never sees AWS_SECRET_ACCESS_KEY.
State Management and Session Handling
Single-call model:
OneCLI does not maintain session state by default. Each tool call is stateless: retrieve credentials, execute, discard. This limits the blast radius of a compromised agent but requires re-authentication for every command.
Session token caching (optional):
For services that issue short-lived tokens (OAuth, OIDC), OneCLI can cache tokens internally and reuse them across calls. The agent still never sees the token. The cache lives in the gateway’s memory, not the agent’s.
Multi-step workflows:
If an agent needs to run three authenticated commands in sequence, it makes three separate calls to OneCLI. Each call is independently authorized. The agent cannot compose a malicious command sequence using a cached credential because it never holds the credential.
Observability Without Credential Leakage
Traditional agent logs capture tool calls with parameters. If the parameter is a secret, the log is poisoned.
OneCLI logs:
- Tool name
- Sanitized parameters (bucket name, not access key)
- Execution result (stdout/stderr)
- Timestamp and agent identity
What you lose:
You cannot grep logs for the literal secret value to trace its usage. You must correlate tool calls by agent ID and timestamp.
What you gain:
Logs are safe to store in centralized observability platforms (Datadog, Grafana, S3) without secret scrubbing pipelines.
Failure Modes
Gateway becomes a single point of failure:
If OneCLI is down, the agent cannot execute privileged commands. You need redundancy (multiple gateway instances, load balancing) and health checks.
Command injection via parameter smuggling:
If the agent can control arbitrary parts of the command template, it might inject shell metacharacters. OneCLI must validate and sanitize parameters before execution. Use allowlists for parameter values, not denylists.
Credential rotation requires gateway restart:
If you rotate a secret in the vault, OneCLI must reload its credential cache. This requires either a restart or a hot-reload mechanism. Stale credentials lead to failed commands and agent confusion.
Limited to predefined tools:
The agent can only execute commands that exist in the OneCLI registry. You cannot give an agent arbitrary execution capability. This is a feature (security) and a limitation (flexibility).
Comparison to Vault Patterns
| Approach | Credential Exposure | Prompt Injection Risk | Flexibility | Audit Complexity |
|---|---|---|---|---|
| Traditional vault | Agent holds secret | High (secret in context) | High (agent composes commands) | High (must scrub logs) |
| OneCLI gateway | Gateway holds secret | Low (agent never sees it) | Medium (predefined tools only) | Low (logs are clean) |
| No secrets (public APIs only) | None | None | Low (limited capability) | Low |
When to Use OneCLI
Good fit:
- Agents that need to call authenticated APIs (AWS, GitHub, Stripe)
- Environments where prompt injection is a credible threat
- Teams that want clean audit logs without secret scrubbing
- Workflows with a fixed set of privileged operations
Poor fit:
- Agents that need to compose novel commands on the fly
- Low-latency requirements (gateway adds a hop)
- Single-user scripts where the user is the agent (no trust boundary)
- Environments where the gateway itself is untrusted
Technical Verdict
OneCLI solves a real problem: agents are bad at keeping secrets. By moving the trust boundary from the agent to a dedicated gateway, you reduce the attack surface for prompt injection and context exfiltration.
The trade-off is flexibility. You must predefine every privileged operation the agent can perform. If your agent needs to run arbitrary shell commands with credentials, OneCLI is not the right tool. If your agent needs to call a fixed set of APIs (list S3 buckets, create GitHub issues, query a database), the execution proxy model is a strong fit.
The architecture is simple: a command registry, a credential store, and a subprocess executor. The security benefit is concrete: credentials never enter the agent’s memory. For production agentic systems that interact with sensitive services, this is a useful primitive.