Ship your first agent with a real key in under five minutes.

1. Create your workspace

Sign up free at app.secrevo.com. Login is delegated to PrysmID — pick email + password or any social provider. The Free plan gives you 3 identities, 1 workspace, 2 projects, and 7 days of audit log, permanently. No credit card.

If your organization already has a Secrevo workspace, ask the owner to invite you instead of creating a new one. They invite you from /members in their dashboard.

2. Install the CLI

The installer downloads the right binary for your OS/arch, verifies its SHA-256 against the release checksums.txt, and drops it in a user-writable directory (no sudo, no admin).

macOS / Linux

curl -fsSL https://github.com/getsecrevo/cli/releases/latest/download/install.sh | bash

Default install location: ~/.local/bin/secrevo. Override with SECREVO_INSTALL_DIR=/opt/secrevo. Pin a tag with SECREVO_VERSION=v0.3.0.

Windows (PowerShell 5.1+)

irm https://github.com/getsecrevo/cli/releases/latest/download/install.ps1 | iex

Default install location: %LOCALAPPDATA%\secrevo\bin\secrevo.exe. Override with $env:SECREVO_INSTALL_DIR.

From source (Go ≥ 1.25)

go install github.com/getsecrevo/cli/cmd/secrevo@latest

Verify

secrevo version

You should see the tag of the release you installed (for example secrevo v0.3.0). Anything ending in -dev means you are looking at a local build, not a release. secrevo enroll requires v0.3.0 or newer.

3. Authenticate your agent

Agents are how non-human callers (your scripts, CI jobs, deployed services) authenticate to the API. Every agent belongs to a human owner and inherits their grants — revoke the human and every agent they created dies with them. Create one at app.secrevo.com/agents → New agent, giving it a name that describes the process (for example summarize-bot).

There are two supported ways to hand the agent its token. Pick by where it runs.

Recommended for a headless machine or device — secrevo enroll

This is the browserless equivalent of secrevo login: the operator mints a short-lived code in the dashboard, the agent redeems it once, and the token is written to an encrypted local credentials file (DPAPI-wrapped on Windows). The secret never touches an environment variable, shell history, or your deploy config — which is why this is the right default for an autonomous agent on a machine you control.

1. Open the agent from /agents and click Generate enrollment code. You get a single-use code (15-minute TTL) plus a QR — deliver either to the machine.
2. On that machine, redeem it once:

   secrevo enroll K3M9-X2PA

3. Done. Every later secrevo call finds the persisted credentials automatically — no environment variables to set. Verify with secrevo auth whoami.

The code is single-use and expires in 15 minutes, and generating one rotates the agent's bearer — so a leaked code is low-value and short-lived. The enrolled token is stored at %APPDATA%\secrevo\credentials.json (Windows) or ~/.config/secrevo/credentials.json (POSIX). Requires CLI v0.3.0 or newer.

For CI or an ephemeral process — environment variable

When there is no persistent disk to enroll onto — a CI runner, a short-lived container — inject the token as an environment variable instead. Create the agent, copy the token shown once (it looks like agt_…; the dashboard never shows it again), and keep it in your CI secret store:

export SECREVO_API_TOKEN=agt_...
export SECREVO_WORKSPACE_ID=workspace-...

On Windows PowerShell:

$env:SECREVO_API_TOKEN = "agt_..."
$env:SECREVO_WORKSPACE_ID = "workspace-..."

SECREVO_API_TOKEN always takes precedence over an enrolled credentials file, so you can override an enrolled machine for a single invocation. The workspace ID is shown at the top of the dashboard. SECREVO_API_BASE_URL defaults to https://api.secrevo.com and only needs to be set for a self-hosted instance.

4. Run your first command

Put a real key in your workspace from the dashboard at app.secrevo.com/secrets — for example a real OPENAI_API_KEY. Then:

secrevo run --secret OPENAI_API_KEY -- python -c "import os; print(bool(os.environ['OPENAI_API_KEY']))"

You should see True. The secret was fetched from the API, injected into the subprocess's environment, and never touched disk. The child process's exit code is propagated, so secrevo run -- false exits 1.

Inject several secrets at once, or rename them on the way in:

secrevo run \
  --secret AWS_ACCESS_KEY_ID \
  --secret AWS_SECRET_ACCESS_KEY \
  -- aws s3 ls

secrevo run --secret prod-stripe=STRIPE_API_KEY -- npm test

Use a secret without ever seeing it (mediated calls)

secrevo run injects the value into a local process — fine on a host you trust, but the value does reach that process. When an agent should use a secret in an HTTP API without ever learning the value, use secrevo call. The server injects the secret server-side into an allowlisted request and returns only the response — the plaintext never enters the agent's process, logs, or output.

First, a human with secret.write allowlists the operation — from the secret's page in the dashboard (the Mediated HTTP section) or with the CLI below (deny-by-default — host + method + path, and optionally the query keys, body template, and which response fields come back):

secrevo secret proxy-target add --secret ODOO \
  --host your-org.odoo.com --method POST --path /jsonrpc \
  --response-field result

Then the agent calls it. Put {{secret}} where the value goes (a header or the body — never the URL); the agent supplies only the placeholder:

secrevo call --secret ODOO -X POST -u https://your-org.odoo.com/jsonrpc \
  -H 'Authorization: Bearer {{secret}}' -d @body.json

For the common providers the host and auth header are built in — supply only a path:

secrevo call --secret OPENAI --provider openai --path /v1/models

Multi-step flows (login → use, pagination)

When a task needs several calls with the same secret, open a short-lived session and run each step against it. The session is bound to your identity, expires (5 min by default), shares one response budget, and dies the moment the grant is revoked — every request is re-authorized and re-checked server-side:

sid=$(secrevo session open --secret ODOO | jq -r .session_id)
secrevo call --session "$sid" -X POST -u https://your-org.odoo.com/jsonrpc -d @page1.json
secrevo call --session "$sid" -X POST -u https://your-org.odoo.com/jsonrpc -d @page2.json
secrevo session close --session "$sid"

The same surface is in the Python SDK: client.call(...), client.openai_call("OPENAI", "/v1/models"), and client.open_proxy_session(...) / session_call(...) / close_proxy_session(...).

Honest limits

• The value never reaches the agent — not its process, logs, or output. The allowlist is human-managed; an agent can never widen its own allowlist.
• HTTPS only, deny-by-default, SSRF-guarded. A secret goes only to a host+operation an operator approved for it; internal / cloud-metadata addresses are refused.
• Bounded, not omniscient. A compromised agent is limited to the operations you allowlist, under a response budget and TTL, with every call audited and revocable instantly. But the data those endpoints return is visible to the agent within that envelope — mediation hides the credential, not the data a read key legitimately exposes.
• Non-HTTP AWS use has its own path. For an AWS key an agent should use without seeing (SigV4 signing, the AWS SDK/CLI), mediation doesn't apply — mint short-lived credentials instead (secrevo creds, below). SSH, live DB drivers, and private-key signing still need local execution (secrevo run) and remain a human/opt-in path (see the mechanism table).

Use a secret as short-lived credentials (ephemeral creds)

Some loads must hold real credential bytes — the AWS SDK/CLI signing SigV4, a database driver opening a connection. Mediation (secrevo call) can't apply: there is no HTTP request to inject into. The honest answer that still keeps the agent off the long-lived secret is to mint short-lived, scoped credentials from it. For AWS, Secrevo derives a temporary session (via STS GetFederationToken) from the stored key — TTL-bounded, and it can only ever narrow the source key's permissions, never widen them. The agent gets working creds that expire; the long-lived key never leaves the server.

First, a human with secret.write declares the cred-scope — from the secret's page in the dashboard or with the CLI below (deny-by-default — no scope, no minting):

secrevo secret cred-scope add --secret DEPLOY_AWS_KEY \
  --provider aws_federation --max-ttl 15m

Then the agent mints ephemeral creds on demand. --format aws-process emits the AWS credential_process JSON, so the AWS SDK/CLI can call Secrevo for a fresh session automatically:

secrevo creds --secret DEPLOY_AWS_KEY --format aws-process
# or wire it into ~/.aws/config:
#   [profile deploy]
#   credential_process = secrevo creds --secret DEPLOY_AWS_KEY --format aws-process

Other formats: --format env (export AWS_ACCESS_KEY_ID/… ) and --format json. The TTL you request is clamped to the per-secret --max-ttl and the IAM role's own cap — whichever is smallest. Every mint is audited; the creds expire on their own and can't be widened by the agent.

Honest limits

• Deny-by-default and human-scoped. An agent can never grant itself a cred-scope, nor widen one — only a human with secret.write sets it, and the mint is re-clamped server-side against an infrastructure allowlist.
• Short-lived, not revocable per-cred. Minted AWS session creds live until their TTL; the bound is the TTL (kept small), and the ledger reports outstanding creds after a revoke.
• AWS today. aws_federation is the shipped provider. Non-AWS ephemeral providers (e.g. dynamic DB users) are on the roadmap; until then a native DB driver is a human/opt-in path — see the table.

Which mechanism for which secret?

Three sanctioned ways an agent uses a secret without seeing its plaintext — pick by what the secret is. An agent can discover which are wired for a given secret from its metadata (secrevo secret get <NAME> → usable_by_agent_via), and every wall it hits names both the next step to configure AND which paths are already usable on that secret (e.g. read-the-value raw_read vs. use-without-seeing mediated HTTP).

Use the Python SDK

For code that should fetch secrets itself instead of inheriting them from secrevo run:

pip install secrevo-sdk
# or with a third-party integration:
pip install "secrevo-sdk[openai]"

from secrevo_sdk import SecrevoClient

with SecrevoClient.from_env() as secrevo:
    # Native OpenAI client, key already wired. Value never enters your code.
    openai = secrevo.openai_for("OPENAI_API_KEY")
    reply = openai.responses.create(
        model="gpt-5",
        input="What is the capital of France?",
    )
    print(reply.output_text)

Same pattern for anthropic_for, stripe_for, aws_session_for, and github_for. An AsyncSecrevoClient ships for FastAPI / asyncio. Full surface and offline-cache options in the SDK README.

Use Secrevo from a hosted agent (MCP)

If your agent runs somewhere you can't install the CLI — inside ChatGPT or Claude.ai as a hosted connector — Secrevo speaks the Model Context Protocol at https://mcp.secrevo.com. The connector lets the agent govern your secrets (list, grant, audit) and use them in mediated calls — without the secret value ever entering the model.

Add the connector

In Claude.ai → Settings → Connectors → Add custom connector, and in ChatGPT → Settings → Connectors → Add, use the URL https://mcp.secrevo.com/mcp. Both then walk you through an OAuth sign-in.

Sign in (OAuth 2.1)

The connector discovers the login server automatically from https://mcp.secrevo.com/.well-known/oauth-protected-resource, which points at your PrysmID instance (secrevo.auth.prysmid.com). You approve with the same account you use for the dashboard, and the connector receives a token scoped to your grants and nothing more. The MCP server holds no credential that can cross workspaces — every call is authorized by api.secrevo.com under your own identity. There is no plaintext-token config path; auth is OAuth only.

What the agent can do

• Govern — list_secrets, get_secret_meta, list_grants, grant_access, revoke_grant, access requests, audit events, members, groups, and agent lifecycle. Metadata only — no tool ever returns a secret value.
• Consume — secrevo_http and the typed proxies (openai_request, anthropic_request, stripe_request, github_request) inject a secret server-side into an outbound call to an allowlisted destination and return only the response. The value is fetched, used, and zeroed on the server; it never enters the model's context, the tool output, or logs.

Honest limits

• Consumption is HTTP-only and allowlisted. A secret can only be sent to a destination an operator explicitly approved for it (deny-by-default), and the proxy refuses internal / cloud-metadata addresses (SSRF-guarded).
• Non-HTTP use stays with the CLI/SDK. AWS keys used for SigV4 are minted as short-lived credentials with secrevo creds; SSH, live database drivers, and private-key signing need local execution and remain a CLI/SDK (and human/opt-in) path — see the mechanism table. The MCP proxies HTTP consumption only.
• Credential provisioning is dashboard/CLI-only. Minting an agent token or an enrollment code hands out a live credential, so it is deliberately not exposed over MCP — that would place the credential in the model. Create agents from /agents.

The MCP connector is in pilot. If https://mcp.secrevo.com/mcp is not yet reachable for your account, use the CLI or SDK above in the meantime.

Reference & repos

• github.com/getsecrevo/cli — CLI source, releases, install scripts.
• github.com/getsecrevo/sdk-python — Python SDK source.
• pypi.org/project/secrevo-sdk — published SDK releases.
• api.secrevo.com — production API base URL. Health check at /healthz.
• app.secrevo.com — dashboard (sign-in required).
• Security overview · Status · Privacy · Terms · DPA

Troubleshooting

`secrevo version` prints `0.1.0-dev`

You are running a local go build, not an installed release. Reinstall using one of the one-liners above.

`401 unauthorized` from the CLI or SDK

Either SECREVO_API_TOKEN is unset / typo'd, or the agent token was revoked. Mint a new one from app.secrevo.com/agents.

`403 forbidden` reading a secret you can see in the dashboard

The agent inherits the grants of its owner. If you can see a secret as a member but the agent can't, check that the owner — not just the workspace — has a grant on it. Owners can audit their agents' effective access from /agents.

Windows SmartScreen warns the installer is unsigned

The release binaries are not Authenticode-signed yet. Verify the SHA-256 against checksums.txt on the release page before running. Signing is on the roadmap.

Is there a Secrevo MCP server?

Yes — a remote MCP connector at https://mcp.secrevo.com (OAuth 2.1) for hosted agents like ChatGPT and Claude.ai. See Use Secrevo from a hosted agent (MCP) above. It is in pilot; for a headless machine or CI where you control the host, the CLI (secrevo enroll + secrevo run) or the Python SDK remain the direct path.

Something else

Open an issue at getsecrevo/cli/issues or write to [email protected].