Controls rebuilt per app
Each team creates its own model rules, PII handling, tool permissions and provider wiring.
Open source · Self-hostable
Operate every AI use case through one shared control plane.
Give support bots, coding assistants, internal copilots and AI workflows shared cost control, reliability, policy and session understanding. Talon enforces the boundary before access and leaves signed evidence behind every decision.
Cost controlReliabilityShared policySession understanding
Three AI use cases · four operating pillars · one signed historyLive, evidence-backedRun it yourself →
What is spending?What failed?Which policy intervened?What happened in the session?
The problem changes after the first AI app
Every use case should not become its own operations stack.
AI apps, agents and coding tools should not each reinvent budgets, failure behavior, data policy, session visibility and incident evidence. Talon gives them one operating and policy layer without becoming the orchestrator.
Failure behavior diverges
Retries and fallback become ad hoc, and availability pressure can silently weaken policy.
Sessions become request logs
Operators cannot quickly explain what one use case did, spent, or why it stopped.
Four control-plane outcomes
Cost, reliability, policy and sessions stay connected.
Each control runs on the same governed path and produces the evidence needed to explain the result.
Cost controlStop spend before it happens.
Per-request and per-use-case budgets, session soft caps, pre-provider denial and signed reasons for budget decisions.
Control spend →Governed reliabilityFallback never becomes a policy exception.
Supported transient failures can engage an explicit fallback chain. Every candidate is re-checked against the resolved effective policy.
See reliability →Shared policyCentral defaults, explicit exceptions.
Resolve the organization baseline and one explicit use-case override for models, providers, cost, PII, tools and egress.
Apply policy →Session understandingSee the complete multi-provider history.
Inspect sessions with cost, denials, routing, subagent attribution and signed request history inside the authenticated use-case boundary.
Understand sessions →How it works
Route one use case through Talon. Apply the boundary before access. Keep the receipt.
A decision you can inspect
The control is useful because it leaves a receipt.
Talon estimates the next request before provider access, compares the projected session total with effective policy, prevents the call when the limit would be crossed, and records the decision as signed evidence.
Explore signed runtime evidence →DENIEDsession_budget_exceeded
- AI use case
- document-summary
- Session
- sess-4711
- Spent
- $0.0094
- Estimated next request
- $0.0031
- Session limit
- $0.0100
- Projected total
- $0.0125
- Provider call
- Prevented
Evidence verified
hmac: validThree reproducible proof stories
Do not trust the category claim. Trigger the control.
Budget → stop
Cross a use-case or session limit, confirm the next request is denied before provider access, then inspect the signed reason.
Cost proof →Failure → governed fallback
Trigger a supported transient failure and verify that every fallback candidate is checked against the same effective policy.
Reliability proof →Risky path → block
Deny a disallowed tool, PII flow, model or egress destination before access, then verify the evidence.
Policy proof →Technical and operator detail
Open only the implementation detail you need.
Configuration and policy semanticsOne use-case config resolves one effective policy.
The request cannot choose a different operating boundary.
Talon resolves the presented vault-bound key to the configured agent and tenant, then combines the organization baseline and the use-case override into one effective snapshot. Unknown keys fail; hard organization constraints cannot be weakened.
AI use case key
→ configured agent + tenant
→ organization policy + use-case override
→ effective policy snapshot
→ primary / fallback / reporting / evidenceReliability semanticsFallback candidates remain inside effective policy.
A provider failure does not erase the rules.
On supported transient failures such as timeouts, connection errors, 429s and provider 5xx responses, Talon evaluates an ordered fallback chain. Every candidate is re-checked against provider, model, sovereignty and budget constraints.
primary request
→ transient failure
→ evaluate explicit fallback candidate
→ re-check effective policy
→ serve allowed candidate OR fail closed
→ record signed evidenceOperator commandsMove from the installation view to one session and one decision.
The public product language is “AI use case.” The concrete Talon configuration object is the agent.
What needs attention?
talon agentsConfiguration state, health, cost and explicit causes across the installed use cases.
What is spending?
talon costs --agent <name>Attributed cost and effective caps for one use case.
What happened?
talon audit list --session <id>Requests, providers, models, denials and history for the session.
Why, and can I trust it?
talon audit show <id> && talon audit verify <id>Inspect the decisive reason, then verify record integrity.
Interception boundaryTalon controls only the traffic and actions it can see.
Talon controls only the paths it can intercept.
Provider traffic routed through Talon can be governed and evidenced. Visible tool schemas and intercepted MCP calls can be controlled. Local shell commands, file edits, browser actions or direct API calls that bypass Talon remain invisible.
The configured agent is authenticated by its vault-bound key. Client-supplied subagent and session metadata is attribution, not cryptographic workload attestation. Session caps remain soft unless atomic reservation exists.
through Talon
→ effective policy
→ control + evidence
bypasses Talon
→ not controlled
→ not observed
signed evidence
→ tamper-evident runtime proof
→ not a compliance certificateStart with one real use case
Make one failure case produce a controlled outcome and a receipt.
Route one existing AI use case through Talon, trigger a budget, reliability or policy condition, and inspect the session and signed evidence before designing a broader rollout.