Policy gets copied into every runtime
Each team re-implements model, data, provider and budget rules in a different place, so company intent drifts as the fleet grows.
Open source · Self-hostable · Company AI control
Turn company AI policy into enforceable controls for every AI use case.
Define company rules once. Talon resolves use-case-specific effective policy and enforces it at the strongest supported boundary—before disallowed provider access or intercepted actions—then keeps verifiable evidence of what happened.
Company policyUse-case rulesAction authorizationVerifiable evidence
Which company rule applies?Is this action allowed?Can this use case weaken the baseline?Can we prove what happened?
AI adoption scales faster than policy enforcement
Every use case should not reinterpret company policy on its own.
Support agents, coding assistants, internal copilots and product AI features often grow across different runtimes and providers. Talon keeps one company control model, then resolves only the use-case-specific rules and exceptions each workload needs.
Native controls fragment
Provider and framework controls are useful, but a use case that changes runtime should not require the company to redefine the control contract.
Actions become consequential
A harmless-looking model response can become a refund, deployment, deletion or external message. Authorization belongs at the real action boundary.
Company control, then action control, then proof
Keep one policy model. Apply it per use case. Prove the decision.
Cost, reliability and session context remain important operating controls, but Talon’s design center is consistent company policy and preventive authorization at boundaries it can actually govern.
Company policyOne control model, use-case-specific effective rules.
Resolve organization rules into one effective policy for each AI use case, with hard company constraints that use-case configuration cannot weaken.
See the policy model →Action authorizationDecide before a consequential effect.
Intercepted MCP tools can be denied today. The HTTP Action Gateway already binds exact operations and supports ALLOW | DENY | REQUIRE_APPROVAL; native/MCP convergence is still in progress.
Verifiable proofShow which rule produced the decision.
Signed evidence records the identity, policy and decisive outcome Talon observed or enforced, so operators can inspect and verify the control later.
See the evidence layer →Operational controlsCost, reliability and sessions stay on the same path.
Per-use-case budgets, policy-preserving fallback and session history make the governed boundary operable without becoming Talon’s category definition.
See use-case operations →How it works
Company policy becomes effective rules at the boundary of each AI use case.
A preventive decision you can inspect
Enforcement should leave proof, not just a log line.
This shipped budget denial is one concrete example of the broader policy model: Talon evaluates the effective rule before provider access, prevents the disallowed call, and records the decision as signed evidence. Intercepted-action authorization follows the same preventive principle at action boundaries.
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.
Policy → prevent
Configure a company constraint, trigger a disallowed provider/data/tool path, and verify that the governed request cannot silently weaken the baseline.
Policy proof →Action → stop
Deny an intercepted MCP tool, or use the shipped HTTP Action Gateway to bind a consequential action to an exact approval and at-most-once dispatch.
Action Gateway guide →Budget → stop
Cross a use-case or session limit, confirm the next provider request is denied, and inspect the signed reason as a supporting policy control.
Cost 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 identity. Session-budget admission uses atomic reservation of the pre-request estimate; one request can still overshoot if actual cost exceeds that estimate.
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 company rule produce a preventive outcome you can prove.
Put one existing AI use case on a governed path, trigger a policy or intercepted-action boundary that matters, and inspect the evidence. Then add use case #2 only if reusing the company control model is cheaper than rebuilding governance in that runtime.