Dativo Talon

The control plane for your company's AI use cases.

Every AI use case a company ships — a customer-support assistant, a coding assistant, a document summarizer — reinvents the same operational plumbing: its own cost controls, its own retry behavior, its own data policy, its own incident trail. The result is use cases you can't reliably operate, and agentic projects that stall because nobody can control them. Talon is one self-hosted Go binary in front of OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, local Ollama, and any OpenAI-compatible endpoint: point every use case at it and each one gets budget caps enforced before the provider is called, policy-checked failover when a provider degrades, central policy defaults with explicit exceptions for PII, tools, and data destinations, and a per-use-case view of what each did and spent — with a signed, verifiable evidence record behind every decision. Operate the whole fleet — discover, inspect, stop, and reconfigure every use case — from one gateway. Apache 2.0.

A live terminal walkthrough (55s): real Talon CLI and API calls across three AI use cases — customer-support, coding-assistant, document-summary — with every headline checked against signed evidence. A downed local model triggers a policy-valid failover (skipping a provider this use case may not use), customer PII is redacted before the provider (the raw request and the provider's reply are both on screen), a destructive admin tool is rejected by a company-wide boundary, a use case's next call is denied on projected cost before it spends, talon agents shows the fleet react, and one session is audited end-to-end — every decision signed and offline-verifiable.

1 · fleet          talon agents → three use cases, each one agent.talon.yaml, one operating view
2 · reliability    raw request (email + IBAN) → redacted ([EMAIL], [IBAN]) → local model down
   + shared policy → disallowed provider skipped → policy-valid fallback → provider's own reply
3 · org policy     admin_* tool → HTTP 403 before the provider, $0.0000 spent
   + cost          projected spend + estimate over the soft session cap → next call denied
4 · operations     live budget edit → safe reload → fleet shows blocked (and why)
   + proof         audit list --session → verify offline: 8 records · 8 valid · 0 invalid

Operate three use cases → Product demo (real providers, ~$0.05) · See it in 60 seconds, no key → Quickstart · Deep proof, one session → Governed session demo · Pilot a real use case → Open a pilot issue

Is this you?

Talon is for teams that already have AI use cases in production — or blocked on the way there — and need to answer:

• How much is each use case spending, and how do we stop runaway spend? (a cap that denies the request before the provider is called, not an alert after the bill)
• What happens when a provider times out or rate-limits? (one central failure behavior — policy-checked fallback — instead of N ad-hoc retry loops)
• Which models, tools, and data destinations are actually allowed? (central defaults with explicit exceptions, enforced before the model runs, not "should be")
• What did that agent actually do — and can we prove it later? (per-session visibility, backed by a signed record an auditor can verify offline)

If those are your questions, Talon sits in front of your existing OpenAI/Anthropic traffic and answers them at the boundary — no SDK change, same response shape.

One control plane, four jobs

1. Cost control — stop spend before it happens

• Per-agent daily/monthly caps: the request is denied before the provider call, not flagged after the money is gone.
• Session budgets across providers (soft cap — see limitations), plus cache-aware, currency-labeled cost attribution by tenant/agent from an editable pricing table.

→ Cap AI spend per agent

2. Reliability — one failure behavior, not N

• Error-driven provider fallback chains on timeouts, connection errors, 429s and 5xx — and every fallback candidate is re-checked against sovereignty, model, and budget policy before it is tried.
• Fail-closed on exhaustion: a policy denial or budget stop is never "retried around" to keep traffic up.

→ Provider fallback chains

3. Shared policy — central defaults, explicit exceptions

• PII scanning (regex, Presidio, HTTP, or local-LLM engines) on prompts, attachments, tool arguments, and responses; redact, block, or warn before the provider — EU identifiers (IBAN MOD-97, VAT, national IDs) plus email, phone, card, passport, IP.
• Tool allowlists and forbidden globs (admin_*): dangerous tools are stripped or blocked before the model ever sees them; MCP tool calls routed through Talon are policy-checked before execution.
• Egress and sovereignty rules: eu_strict / eu_preferred / global routing and destination controls, air-gap friendly.

→ Policy cookbook

4. Session understanding — know what every use case did

• Session identity from X-Talon-Session-ID, vendor headers (Claude Code, Codex CLI), or a synthetic evidence-only ID — attribution boundaries kept honest.
• Session-scoped audit and cost rollups (talon audit list --session, talon audit verify --session); live metrics API, SSE stream, OpenTelemetry GenAI traces, embedded dashboards.

→ Governing coding agents

Underneath all four: verifiable evidence

Every decision — allow, deny, redact, fallback, budget stop — becomes an HMAC-SHA256-signed, tamper-evident record you can list, verify (including offline), and export to CSV/JSON/signed-JSON. This is the proof layer the pillars stand on, and what compliance reports (GDPR Art. 30 RoPA, EU AI Act Annex IV) are generated from — supporting evidence, not a compliance determination.

→ Evidence store · What Talon is (and is not) · Limitations

Start with one AI use case

You don't have to trust Talon in blocking mode on day one.

1. Put Talon in front of one dev or internal use case (change the base URL, present its agent key).
2. Start in shadow mode — Talon records what policy would do (PII, tools, spend, destinations) without changing the response.
3. Turn on one control when you're ready: block PII, cap spend, keep confidential data local, or strip a dangerous tool.

Which are you?

Or just try it with no key first, then open a pilot issue with your stack and the first control you need.

Product demo — three use cases, one control plane

A live, evidence-backed product demo: it operates customer-support, coding-assistant, and document-summary as three agent.talon.yaml files under one agents_dir, on real providers, and walks the four pillars in one operating period:

export OPENAI_API_KEY=sk-...  ANTHROPIC_API_KEY=sk-ant-...   # stop Ollama first
make product-demo

You watch, in one gateway: a downed local model trigger a policy-valid failover that skips a provider this use case isn't allowed to use; an email + IBAN redacted before the provider; a destructive admin_* tool rejected by a company-wide boundary the agent can't weaken; a use case's next call denied on projected cost before it spends; the talon agents fleet view flag the exhausted use case as blocked after a live budget edit; and a signed export verified offline. Every headline is asserted against Talon's own signed evidence before it's rendered. Real, paid provider calls — ≈ $0.02–0.05/run of Talon-accounted cost (denials cost $0), no Docker. Full walk-through: examples/product-demo.

Try it in 60 seconds (no API key)

The bundled Docker Compose stack runs Talon plus a mock provider, so the full pipeline (policy, PII, cost, evidence) runs without any real LLM key.

git clone https://github.com/dativo-io/talon && cd talon
cd examples/docker-compose && docker compose up

In another terminal, send a request containing an email and an IBAN:

curl -X POST http://localhost:8080/v1/proxy/openai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"My email is [email protected] and my IBAN is DE89370400440532013000. Help me reset my password."}]}'

You get a standard OpenAI-compatible JSON response — and Talon still ran every governance check. Inspect the signed evidence:

docker compose exec talon /usr/local/bin/talon audit list
docker compose exec talon /usr/local/bin/talon audit show <evidence-id>

The record shows the PII detected (email, IBAN), the data tier, the policy decision, the cost, and a verifiable HMAC signature.

Why did the IBAN go through? This demo ships in shadow mode: Talon records what policy would do — including the PII it found — without changing the request. That's the low-risk way to adopt: drop Talon in front of real traffic, see what it flags for a week, then flip to enforce mode to redact or block the IBAN before the provider (exactly what the hero above shows). One config line: mode: shadow → mode: enforce.

Full walk-through: 60-second demo.

Drop-in OpenAI proxy

For an existing OpenAI SDK app, start the dev quickstart proxy and repoint the base URL — same request shape, same SDK, governed path:

talon serve --proxy-quickstart --port 8080
export OPENAI_BASE_URL=http://127.0.0.1:8080/v1
export OPENAI_API_KEY=sk-...

import openai

client = openai.OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="sk-...")
resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Summarize EU AI Act obligations for SMBs."}],
)
print(resp.choices[0].message.content)

Governance (policy, PII scan/redaction, evidence) stays active in quickstart mode. For production, use --gateway with talon.config.yaml. See OpenAI proxy quickstart.

Governed session demo (real providers)

Watch one AI use case operate under a cross-provider session budget, central policy, and per-session visibility — a real agent session with an Anthropic planner and OpenAI executors through the same gateway, bring-your-own keys (≈ $0.03/run, cheap models, session-capped):

export ANTHROPIC_API_KEY=sk-ant-... OPENAI_API_KEY=sk-...
make governed-session
cd examples/governed-session && ./demo.sh all

session begins ──▶ Anthropic orchestrates (prompt-cache write, then read); ChatGPT executes the plan
               ──▶ forbidden admin_* tool stripped · email redacted · model-allowlist deny
               ──▶ IBAN probe denied before any provider call
               ──▶ confidential data → US model rejected by policy → local Llama runs it (routed)
               ──▶ real cross-provider spend reaches the session cap → 403 session_budget_exceeded
               ──▶ money story from the signed export; flipping a signed field makes audit verify report INVALID
               ──▶ talon audit verify --session → N valid, 0 invalid; talon compliance ropa → GDPR Art. 30 pack

The sovereignty act shows data classification driving execution placement: confidential input is refused by the US model and runs locally instead — the same IBAN the gateway blocks outright elsewhere, because policy (not the data alone) decides the outcome. Every decision is a signed evidence record in one session trail: supporting controls and evidence for GDPR and EU AI Act reviews, not a compliance guarantee.

Recorded with asciinema (cast · scripts/record-governed-session.sh). Full walk-through: governed-session demo. The sovereignty-routing act needs a local Ollama (opt-in routing-demo compose profile).

What Talon does to every request

Each request flows through one governed pipeline before (and after) it reaches a provider:

sequenceDiagram
    participant Client
    participant Talon
    participant Provider
    Client->>Talon: OpenAICompatibleRequest
    Talon->>Talon: IdentityRateLimitPIIScanPolicyToolChecks
    Talon->>Provider: ForwardIfAllowed
    Provider-->>Talon: ProviderResponse
    Talon->>Talon: ResponseScanEvidenceCost
    Talon-->>Client: GovernedResponse

Resolve agent → rate limit → parse model/text/tools → PII scan → classify data tier → OPA policy decision (allowlist, cost, tier, provider) → tool governance → redact/block → forward with the vault key → response scan → signed evidence + cost. Pipeline overhead is typically under 15ms excluding upstream latency (make benchmarks).

Full byte-level breakdown: What Talon does to your request · Benchmarks.

Capabilities by pillar

447 passing conformance tests across the evidence + policy paths — reproduce the current count with make conformance.

Supported providers

Talon proxies OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, local Ollama, plus Mistral, Vertex, Cohere, Qwen, and any generic-openai-compatible endpoint. Every provider carries jurisdiction and region metadata that routing policy can act on — EU-capable options include Azure OpenAI (westeurope, swedencentral, francecentral, uksouth), AWS Bedrock (eu-central-1, eu-west-1, eu-west-3), Mistral (EU), Vertex (europe-west1/4/9), and local Ollama.

Full table with regions and notes: Provider registry. Inspect live: talon provider list, talon provider info <type>, talon provider allowed.

Integration paths

Where Talon fits

Routers optimize a single call; observability tools tell you what already happened. Talon operates the AI use cases routed through it: budget caps and policy decided before the request reaches the model, policy-valid fallback when providers fail, and a per-session trail of what each use case did — with every decision leaving a verifiable, signed record. One layer instead of per-app plumbing.

What "control plane" means here — and what Talon deliberately is not: Talon as a control plane. Why a PII-redaction proxy isn't enough: Why not a PII proxy.

Built for teams that must prove it

Operating AI is the job; proving it is often the trigger. Talon is a single self-hosted binary (on-prem, EU cloud, or air-gapped — no required SaaS), with eu_strict routing to keep confidential data in-region or on local models, and signed evidence behind every decision. From that evidence, Talon generates supporting documentation for reviews: GDPR Art. 30 RoPA and EU AI Act Annex IV packs — supporting controls and evidence, not a compliance determination.

→ Policy packs · Turnkey compliance reports · Air-gapped deployment · Provider registry

Install

Talon requires CGO (SQLite). Go 1.22+ recommended (CI uses 1.25.x).

# From source (recommended on macOS)
git clone https://github.com/dativo-io/talon && cd talon && make install

# Or go install
go install github.com/dativo-io/talon/cmd/talon@latest

# Or Docker
docker pull ghcr.io/dativo-io/talon:latest

Release tarballs (linux/amd64) and an install script are on Releases. Platform matrix, checksums, and the macOS !tapi-tbd workaround: Quickstart install guide.

First run:

export TALON_SECRETS_KEY="$(openssl rand -hex 32)"   # vault encryption key
talon init --scaffold --name my-agent                # agent.talon.yaml + talon.config.yaml
talon run --dry-run "hello"                          # no LLM API key required

Configuration

Short examples below; full schemas in the Policy cookbook and Configuration reference.

# agent.talon.yaml — block on PII, cap spend
policies:
  data_classification: { input_scan: true, block_on_pii: true }
  cost_limits: { daily: 10.00, monthly: 200.00 }

# talon.config.yaml — forbid dangerous tools, enforce EU-strict routing
gateway:
  organization_policy:
    constraints:
      forbidden_tools: ["delete_*", "admin_*", "bulk_*"]
llm:
  routing:
    data_sovereignty_mode: eu_strict

# talon.config.yaml — fallback on transient failures, cap a session's spend
gateway:
  providers:
    openai:
      base_url: "https://api.openai.com"
      secret_name: "openai-api-key"
      fallback:
        - provider: "mistral-eu"        # tried in order on timeout/429/5xx — policy-checked first

# agent.talon.yaml — one file per AI use case; its vault-bound key is the traffic identity
agent:
  name: support-bot
  key:
    secret_name: "support-bot-talon-key"   # talon secrets set support-bot-talon-key ...
policies:
  session_limits:
    max_cost: 0.50          # soft cap: denies the next request once exceeded

Proof Pack (trust & verification)

Artifacts a skeptical reviewer can grep in one session:

• Limitations — what Talon does and does not prove
• Threat model — attack surface and trust boundaries
• Evidence integrity specification — byte-exact signing and verification
• Conformance suite — make conformance (evidence + policy paths)
• Benchmarks — make benchmarks on your hardware
• Sample auditor pack — signed export + compliance report + GDPR Art. 30 RoPA + EU AI Act Annex IV pack (make auditor-pack)
• Roadmap & focus — shipped-vs-target status, active MVP roadmap, and public anti-goals

Docs

Documentation index · 60-second demo · Your first governed agent · Limitations · What Talon does to your request · Policy cookbook · Provider registry · Evidence store · Conformance · Roadmap · Gateway dashboard

Pilot Talon on a real AI use case

The fastest way to know if Talon fits: put one use case behind it in shadow mode and see what it flags. Common first steps:

Open a pilot issue → with your current stack and the one control you need first — we'll help you get it running.

License

Apache 2.0 — see LICENSE.