Agents · Apps · Bots · Coding tools

Treat every AI agent or application as a use case under company policy.

Your company may call them agents, assistants, bots or AI features. Talon keeps the public object stable—the AI use case—then resolves the company baseline into the effective rules that workload must obey across the supported paths Talon can actually govern.

Run the 60-second demo Choose an integration path Compare approaches

one agent.talon.yaml
= one AI use case
= one vault-bound agent key
= one derived tenant
= one effective policy

request
→ authenticate agent
→ evaluate policy
→ route / deny / redact / filter
→ sign the evidence

AI use caseCompany baselineEffective rulesAction authorizationOperational contextEvidence

Category and implementation

AI use case is the stable product object. Agent is today’s OSS implementation object.

Publicly, Talon governs AI use cases independent of runtime or provider. Today, configuration, authentication, evidence and attribution still use the Talon agent object. That implementation detail may evolve without changing the company policy/use-case contract.

One real use case first

Start with the support bot, coding workflow or product feature where a company rule must prevent or authorize a real outcome.

Keep the orchestrator

Talon does not decide tasks, spawn subagents or replace LangGraph, Claude Code, Codex or your application logic.

Reuse the company control model

Keep policy semantics stable while the technical enforcement point changes across model gateways, MCP, runtime hooks or other supported boundaries.

Identity contract

The application presents an agent key, not a free-form identity claim.

agent.key.secret_name points to one encrypted vault secret. Talon resolves the presented key to the agent and tenant, rejects unknown keys, and prevents the request from acting as a different agent. The admin key remains a separate authority.

Authentication reference Configure an agent

agent:
  name: customer-support
  tenant_id: acme
  key:
    secret_name: customer-support-talon-key

# bearer key → customer-support → acme
# body/header cannot substitute another identity

Four questions

The control layer should answer what each app should not redefine for itself.

Question	Talon pillar	Current proof
What is this AI use case spending?	Cost control	Per-agent cost views, session cost and budget-denial evidence.
What failed and where did execution go?	Reliability	Policy-checked fallback attempts and terminal evidence on supported transient failures.
Which rules apply to this use case?	Shared policy	Organization baseline plus one agent override, resolved for models, providers, cost, PII, tools and egress.
What happened in this multi-request run?	Session understanding	Agent-scoped asserted-session list, export, cost and verification across allowed provider routes.

Effective policy

Use one policy snapshot across the complete provider path.

The organization baseline and agent override resolve into the same effective policy used by the primary route, every fallback candidate, budget reporting and evidence. Organization PII, provider/model, tier and egress boundaries cannot be weakened by an agent.

Shared policy model Policy examples

organization policy
        +
one agent override
        ↓
resolved effective policy
        ↓
primary route + fallback + costs + evidence

Current operator path

Use the CLI and evidence model that actually ship.

Operators can inspect cost, list session evidence, open one decision, verify integrity and confirm the policy identity with shipped CLI surfaces.

talon costs --agent customer-support

talon audit list --session sess-feature-4711

talon audit show <evidence-id>

talon audit verify <evidence-id>

Action boundary

Agentic does not mean universally controllable.

Talon can govern provider-bound traffic, tool schemas visible to the gateway and MCP/tool calls routed through its interception path. Current MCP interception can deny disallowed calls before upstream execution. The HTTP Action Gateway already ships exact-operation authorization and durable approval; convergence of native/MCP calls onto that path remains in progress. Local shell commands, file edits, browser actions and direct APIs that bypass Talon remain outside the control plane.

Action control Action Gateway reference

through Talon
→ authenticated agent
→ policy can run
→ evidence can be written

bypasses Talon
→ invisible
→ uncontrolled by Talon

Fleet operations

One Talon process can serve a discovered fleet of AI use cases.

agents_dir recursively discovers agent files, each use case resolves its own compiled policy/runtime bundle, and safe periodic reload keeps the last-known-good generation active when a new edit is invalid. Runtime identity is resolved from the configured agent key, not from client-asserted request metadata.

Adopt incrementally

Put one real AI use case under one company rule.

Use the current agent file/key mechanism to route the path Talon can govern, trigger a meaningful policy or action decision, verify the evidence, and only then add use case #2 to test whether the shared control model actually reduces governance duplication.

Add Talon to an app Start with cost Start with actions