RunEnv/ Solutions

Agent Guard

Secret management for AI agents without standing credentials

RunEnv Agent Guard lets coding agents perform approved, auditable actions without receiving general secret-read access or connector credentials. The recommended workflow is to give agents actions, not secrets.

The workflow

A clearer operating model for configuration.

Each page is grounded in a workflow RunEnv supports today. Use the examples and documentation links to decide whether the model fits your team.

Keep secret values out of the agent context

A service token in an agent configuration, prompt, or MCP tool result becomes another standing credential. Agent Guard is a separate path: the agent requests an action, a human can approve it, and RunEnv executes the allowed operation without exposing general secret-read access.

  • Use Agent Guard or a scoped MCP workflow for agent actions.
  • Do not copy a service token into an agent configuration.
  • Do not place secret values, RunEnv tokens, or connector credentials in prompts.

Connect a supported coding agent

RunEnv supports `codex`, `claude`, `copilot`, and `cursor` adapters. Start with a local scan, then preview the files that would change before applying OAuth.

  • Run `runenv agent doctor .` to scan the current workspace locally. This does not require an account.
  • Preview with `runenv agent connect codex --project <project-id>`.
  • Apply only after reviewing the preview and completing browser OAuth.

Use the Agent Guard MCP tools

The local Agent Guard MCP server exposes a bounded action surface. There is no raw secret retrieval tool. Unknown fields and unredacted credential-shaped fields fail closed.

  • Preview, request, execute, inspect, cancel, and roll back actions through the documented tools.
  • Action arguments are a JSON object with size, depth, and string limits.
  • Fields shaped like secrets, passwords, tokens, or credentials may contain only the literal `[REDACTED]` marker.

Keep humans in the approval path

Agent authorization is project-bound. Use least-privilege access packs, optional human approval for every request, and the documented rollback command when an applied adapter change needs to be undone.

How it works

Start with the boundary your team needs.

  1. 01

    Scan and choose the project

    Run `runenv agent doctor .`, sign in as the human sponsor, and select the RunEnv project the agent is allowed to use.

  2. 02

    Connect the agent through OAuth

    Preview the adapter change, apply it only after review, and complete the browser OAuth flow. Tokens stay in the operating system credential store.

  3. 03

    Preview, approve, and execute

    The agent lists capabilities, previews an action, requests a permit when required, and executes only the approved operation. Use rollback when the applied change needs to be reversed.

Continue learning

Read the implementation details.

The documentation explains the supported commands, permissions, retention boundaries, and delivery modes behind this workflow.

Explore the workflows

See how RunEnv fits your operating model.

Read the focused guides for managing environment variables, reviewing changes, delivering secrets at runtime, and connecting coding agents.

Manage shared environment variables

A practical workspace for teams that have outgrown copying .env files between laptops, chat threads, and deployment systems.

Read the guide

Version and roll back environment changes

Keep configuration changes reviewable and recovery close when a deployment depends on the right environment variables.

Read the guide

Inject secrets at runtime

Deliver the configuration a process needs at execution time while keeping the no-file boundary explicit for the runtime-injection workflow.

Read the guide