Architecture & How It Works

TameFlare is a managed service. You sign up at tameflare.com, configure gateways in the dashboard, and run the CLI on your infrastructure. There is nothing to deploy.

How it works

Your process → TameFlare Gateway (Go proxy on your machine)
                    │
                    ├── domain → connector → parse action
                    ├── check permissions against dashboard config
                    ├── inject credentials from encrypted vault
                    │
                    ▼
              External APIs (GitHub, Stripe, OpenAI, ...)
  1. Dashboard (hosted at tameflare.com) - configure gateways, connectors, permissions, credentials, and policies. View traffic logs, approve requests, manage your team.
  2. CLI (npx @tameflare/cli) - runs on your machine. Starts the gateway proxy and routes your process traffic through it.
  3. Gateway (Go binary) - transparent HTTP/HTTPS proxy. Intercepts outbound traffic, parses it via connectors, checks permissions, injects credentials, and logs everything.

The gateway runs locally on your infrastructure. Only configuration and audit data are stored in the hosted dashboard. Your API keys are encrypted at rest (AES-256-GCM) and never leave the vault unencrypted.


Approval channels

TameFlare supports two approval modes:

Dashboard-only (default)

Approvals appear on the Approvals page in the dashboard. Admins and members can approve or deny directly from the UI. No external services required.

Slack integration

For teams that want approval notifications in Slack:

  1. Create a Slack app at api.slack.com/apps
  2. Add the chat:write and chat:read bot scopes
  3. Install the app to your workspace
  4. Copy the Bot Token and Signing Secret to Settings → Integrations in the dashboard
  5. Set the channel ID where approval messages should be posted

Slack approval messages include approve/deny buttons that update the dashboard in real time.

Both modes work simultaneously - Slack notifications are additive, not a replacement for dashboard approvals.


Performance

| Operation | Typical latency | Notes | |---|---|---| | Policy evaluation | 1–5ms | In-memory, no DB calls during evaluation | | Permission check + credential injection | 10–30ms | Local gateway, no round-trip to dashboard | | End-to-end (agent → external API) | 50–500ms | Depends on external API response time |

The gateway adds minimal overhead. It runs as a single Go binary using ~20–50 MB RAM.


Security model

  • Deny-all default - no connector configured = no access
  • Credential isolation - your process never sees real API keys
  • Encrypted vault - AES-256-GCM encryption at rest
  • Per-gateway permissions - fine-grained allow/deny per connector, per action type
  • Kill switch - block all traffic instantly, scoped to a connector or gateway
  • Audit trail - every request logged with gateway, action, decision, and latency
  • Source-available - full source code at github.com/tameflare/tameflare under Elastic License v2