Sign in your way. AI works on your behalf.

AI agents need access to your work systems — Jira, wikis, calendars, internal APIs. But passing credentials through shell history, environment variables, and agent context windows is a security nightmare.

sig handles browser SSO, encrypts credentials at rest, and injects them into any process — so your agents authenticate without ever seeing secrets.

npm install -g @sigcli/cli

sig init                              # create ~/.sig/config.yaml
sig login https://jira.example.com    # authenticate via browser SSO — once

# now your AI agent can work on your behalf:
sig request https://jira.example.com/rest/api/2/myself
sig request https://jira.example.com/rest/api/2/search --method POST --body '{"jql":"assignee=currentUser()"}'

For APIs that use OAuth2 Client Credentials (no browser needed):

sig login https://oauth-mock.mock.beeceptor.com \
  --strategy oauth2 \
  --token-url https://oauth-mock.mock.beeceptor.com/oauth/token/google \
  --client-id test-client \
  --client-secret test-secret

This mock server accepts any client_id/secret and returns a JWT token. After setup:

sig status oauth-mock                # check token status
sig get oauth-mock --no-redaction    # see raw Bearer token
sig logout oauth-mock                # clear token (keeps secrets)
sig get oauth-mock                   # auto-refreshes using stored credentials

Configure once, then all commands work the same as browser-based providers — sig get, sig run, sig proxy all inject the Bearer token automatically.

• Browser SSO — signs in through a real browser. Works with any website, any login flow.
• OAuth2 Client Credentials — configure once, sig manages token exchange, expiry, and silent refresh. No browser needed.
• Encrypted at rest — AES-256-GCM encryption. Every access is audit-logged.
• Declarative config — define what to extract (cookies, localStorage, tokens) and how to apply them to requests.
• Multi-provider — inject credentials from multiple systems in a single command.
• MITM proxy — agents set HTTP_PROXY and credentials are injected transparently. Zero-trust.
• AI-native — stable CLI with predictable exit codes and JSON output. Built for agents.

You log in once               sig extracts & encrypts           AI agent operates
in your browser         -->   credentials locally          -->  on your behalf
(any SSO/login flow)          (~/.sig/credentials/)             (sig request / sig proxy)

sig login opens a browser, you log in normally (SSO, MFA, anything). sig extracts credentials based on extract[] rules, validates them against validateUrl or validateRule (or detects login redirects), encrypts with AES-256-GCM, and stores locally. When your agent needs a request, apply[] rules inject credentials into HTTP headers, body, or query params.

Most enterprise/SSO sites work with zero config. Public sites need a bit more. Here's the progression from simple to advanced:

For SSO-protected internal tools, just run:

sig login https://jira.example.com

sig opens a real browser, you log in, and it writes config automatically:

# ~/.sig/config.yaml (auto-generated)
jira-example:
    domains:
        - jira.example.com
    entryUrl: https://jira.example.com/
    strategy: browser
    extract:
        - from: cookies
          as: session
          match: '*'
    apply:
        - in: header
          name: Cookie
          value: '${session}'

Public sites set tracking cookies to all visitors. sig can't tell auth cookies from junk using redirect detection alone. Use validateUrl, validateRule, or both:

validateUrl — point to a protected endpoint. sig probes it and accepts credentials only on 2xx:

reddit:
    domains:
        - www.reddit.com
        - reddit.com
    entryUrl: https://www.reddit.com/
    validateUrl: https://www.reddit.com/prefs/friends
    strategy: browser
    extract:
        - from: cookies
          as: cookie
          match: '*'
    apply:
        - in: header
          name: Cookie
          value: '${cookie}'

sig validates extracted credentials against validateUrl — 401/403 means not logged in, 2xx means success.

validateRule — a JS expression for APIs that return 200 even when unauthenticated (e.g. with an error code in the JSON body). Use alone or together with validateUrl:

douyin:
    domains:
        - www.douyin.com
    entryUrl: https://www.douyin.com
    validateUrl: https://www.douyin.com/aweme/v1/web/notice/count/
    validateRule: 'res.body.status_code === 0'
    strategy: browser
    extract:
        - from: cookies
          as: cookie
          match: '*'
    apply:
        - in: header
          name: Cookie
          value: '${cookie}'

validateRule is a JavaScript expression with access to res (the validation response):

The expression must return a truthy value for credentials to be accepted. Examples:

# API returns { "status_code": 0 } on success
validateRule: 'res.body.status_code === 0'

# API returns { "logged_in": true }
validateRule: 'res.body.logged_in === true'

# Accept any 2xx that isn't an error page
validateRule: 'res.status >= 200 && res.status < 300 && !res.body.error'

When validateRule is set, it overrides the built-in status-code and redirect detection logic entirely.

Some sites use multiple domains (e.g. x.com migrated from twitter.com). List all domains so sig captures cookies from both:

x:
    domains:
        - x.com
        - twitter.com
    entryUrl: https://x.com/
    validateUrl: https://x.com/i/api/2/notifications/all.json?count=1
    strategy: browser
    networkProxy: socks5://127.0.0.1:3333
    extract:
        - from: cookies
          as: cookie
          match: '*'
        - from: cookies
          as: ct0
          match: 'ct0'
    apply:
        - in: header
          name: Cookie
          value: '${cookie}'
        - in: header
          name: x-csrf-token
          value: '${ct0}'
        - in: header
          name: authorization
          value: 'Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA'

Some apps store tokens in localStorage instead of cookies. Use from: localStorage with match (key pattern) and jsonPath (nested field):

app-slack:
    domains:
        - your-org.enterprise.slack.com
    entryUrl: https://app.slack.com/client/YOUR_TEAM_ID
    strategy: browser
    extract:
        - from: cookies
          as: session
          match: '*'
        - from: localStorage
          as: xoxc-token
          match: localConfig_v2
          jsonPath: teams.YOUR_TEAM_ID.token
    apply:
        - in: header
          name: Cookie
          value: '${session}'
        - in: header
          name: Authorization
          value: 'Bearer ${xoxc-token}'

Full guide with debugging tips at sigcli.ai.

Pre-built Python scripts that let AI agents operate 14+ web services — email, chat, forums, video platforms, social networks, and more. Each skill includes scripts + documentation that agents read and execute autonomously.

Install skills to your coding agent (Claude Code, Cursor, Windsurf, Cline):

npx @sigcli/skills            # install skills to your coding agent

See the full skills catalog for details.

Full docs, configuration, SDK, and AI agent integration guide at sigcli.ai.

Report an issue https://github.com/sigcli/sigcli/issues

Or contact me: syncviip@gmail.com

MIT