SatGate

Manage your API's economic firewall from the terminal. Mint tokens, track spend, revoke agents, enforce budgets. The server-side counterpart to lnget.

Security Scan

The skill's files and instructions broadly match its stated purpose (managing gateway tokens and budgets), but there are transparency gaps and small risks you should understand before installing (notably missing declared credentials, a networked binary install that can skip checksum verification, and installer actions requiring sudo).

Purpose & Capability

Name/description, SKILL.md, and included scripts all describe a CLI that mints/revokes tokens and talks to a SatGate gateway — that aligns. However, the registry metadata declares no required environment variables or primary credential while the README and configure.sh clearly expect admin/session tokens and several SATGATE_* env vars. The omission reduces transparency and makes automated platform checks impossible.

Instruction Scope

SKILL.md and the scripts keep to the stated domain: installing the satgate binary, configuring ~/.satgate/config.yaml, and calling the gateway (satgate ping/status). There are no instructions to read unrelated system files or exfiltrate data. The SKILL.md suggests installing an unrelated plugin (lnget) for client-side payments, but that is a documented integration, not hidden behavior.

Install Mechanism

install.sh downloads a prebuilt binary from GitHub releases (https://github.com/SatGate-io/satgate-cli), which is a standard release host — good. The script attempts to verify SHA256SUMS but explicitly skips verification if checksums are missing or system tools are absent; in that case the binary is installed without a verified checksum. The installer may use sudo to write to /usr/local/bin. These are reasonable choices but carry the usual risks of installing network-downloaded binaries without enforced verification.

Credentials

The skill manifest lists no required env vars or primary credential, yet SKILL.md and configure.sh expect and store sensitive values (admin_token, session_token, bearer_token, tenant) in ~/.satgate/config.yaml or via SATGATE_* env vars. Requiring admin/session tokens is reasonable for a gateway management CLI, but the manifest's omission is a transparency problem: the platform won't warn users or gate secret provisioning, and automated checks can't reason about needed privileges.

Persistence & Privilege

The skill does not request always:true, does not modify other skills, and only writes its own user-scoped config (~/.satgate/config.yaml) and can place a binary in standard locations (/usr/local/bin). These behaviors are typical for a CLI installer; expected privileges (filesystem write for installation, network access to the gateway) are within scope.

What to consider before installing

This skill appears to be what it claims — a CLI to manage SatGate gateways — but there are a few practical risks and transparency issues to consider before installing: - Verify the origin: the installer pulls a binary from GitHub (SatGate-io/satgate-cli). Visit that repository and confirm the release artifacts and SHA256SUMS match what you expect before running install.sh. - Prefer verified installs: if checksums are missing or your system lacks sha256 tools, the installer will skip verification. Consider building from source or obtaining the checksum directly from the official repo before installing. - Protect secrets: the CLI expects sensitive tokens (admin_token/session_token/bearer_token). configure.sh writes them to ~/.satgate/config.yaml with permissions 600, which is good, but only run this on machines you trust. The registry metadata should have declared those env vars — ask the publisher to update the manifest so the platform can surface required credentials to you. - Least privilege: create and use a scoped admin/session token with minimal privileges where possible rather than a full root credential. - Run health-check first: use scripts/health-check.sh to validate the binary and connection before performing destructive operations; use --dry-run and avoid --yes flags without human approval. If you need higher assurance, inspect the project's GitHub release binary and source code (or build from source) and confirm the vendor (satgate.io) and the GitHub org match officially published channels.

SatGate CLI

SatGate CLI manages API access, budgets, and monetization for the agent economy. Use it when you need to control what agents can access and how much they can spend.

They're the wallet. We're the register.

If the agent needs to pay for L402 APIs, install lnget from Lightning Labs. SatGate is for the server side — enforcement, attribution, and governance.

Setup

Run scripts/configure.sh if no ~/.satgate/config.yaml exists. Or set environment variables:

# For self-hosted gateway
export SATGATE_GATEWAY=http://localhost:9090
export SATGATE_ADMIN_TOKEN=sgk_your_token

# For SatGate Cloud
export SATGATE_SURFACE=cloud
export SATGATE_GATEWAY=https://satgate-gateway.fly.dev
export SATGATE_BEARER_TOKEN=sg_your_api_key
export SATGATE_TENANT=your-tenant-slug

Always run satgate status first to confirm you're targeting the right gateway.

Safety Rules

1. Check target first — run satgate status before any operation to verify gateway URL and surface.
2. Use --dry-run on destructive operations (revoke, mint with large budgets).
3. Never use --yes without explicit user approval.
4. Revocation is irreversible — always confirm token name before revoking.

Commands

Check gateway health

satgate status    # Full status (version, surface, uptime)
satgate ping      # Quick liveness check (exit 0/1)

Mint a token for a new agent

# Interactive (prompts for all fields)
satgate mint

# Non-interactive
satgate mint --agent "my-bot" --budget 500 --expiry 30d --routes "/api/openai/*"

# With parent (delegation under existing token)
satgate mint --agent "child-bot" --budget 100 --parent "parent-token-id"

# Preview without executing
satgate mint --agent "my-bot" --budget 500 --dry-run

Check agent spend

satgate spend                   # Org-wide cost center rollups
satgate spend --agent "cs-bot"  # Per-agent breakdown
satgate spend --period 7d       # Time-scoped

List and inspect tokens

satgate tokens                  # All tokens with status, spend, budget
satgate token <id>              # Detail: scope, delegation chain, spend

Revoke a compromised agent

satgate revoke <token-id>           # Interactive confirmation
satgate revoke <token-id> --dry-run # Preview only

View security threats

satgate report threats          # Blocked requests, anomalies

Check policy modes

satgate mode                    # Current mode per route (read-only)

Common Workflows

"New agent needs API access" → satgate mint --agent "agent-name" --budget 500 --routes "/api/openai/*"

"How much are agents spending?" → satgate spend

"Agent is misbehaving" → satgate revoke <token-id>

"Board wants AI spend report" → satgate spend --json > report.json

"Is the gateway healthy?" → satgate ping

Output Formats

All commands support --json for machine-readable output:

satgate tokens --json | jq '.[] | select(.status == "active")'
satgate spend --json > monthly-report.json

Pairing with lnget

SatGate (server-side) + lnget (client-side) = complete agent commerce stack.

• lnget: Agents pay for L402-gated APIs automatically
• SatGate CLI: Operators mint tokens, set budgets, revoke access, view spend

An agent using lnget hits your SatGate-protected endpoint → SatGate enforces the budget and attributes the cost → you see it in satgate spend.

Install lnget: claude plugin marketplace add lightninglabs/lightning-agent-tools