Control-plane pillar · Shared policy

Give every AI use case one identity and one effective policy.

Talon resolves organization intent and one explicit agent override before provider access. The same immutable policy snapshot governs models, providers, cost, sensitive data, visible tools, egress and fallback—and its identity is recorded in signed evidence.

Run the 60-second demo Read configuration See EU/local controls

presented agent key
→ resolve agent + tenant
→ load organization policy
→ apply one agent override
→ resolve effective policy snapshot
→ evaluate primary and fallback candidates
→ record signed policy digests

One agent keyOrganization baselineOne agent overrideMonotonic constraintsEffective policySigned digests

The operating problem

Independent AI apps create independent policy drift.

A support bot, coding agent and internal assistant should not each invent their own answer to sensitive data, model access, budget and egress. Talon centralizes identity and enforcement on paths it can actually intercept.

Authenticated use-case identity

One agent.talon.yaml binds one AI use case to one active vault-bound Talon key.

One decision contract

The organization baseline and the agent override are resolved once rather than reinterpreted by every runtime surface.

One proof history

Signed evidence carries the organization, agent, provider and resolved effective-policy digests behind the decision.

Shipped identity model

The presented key is the Talon traffic identity.

Each AI use case has one agent file and one encrypted key reference. Talon resolves the presented key to the agent, derives the tenant, and rejects unknown keys or attempts to claim another agent or tenant. A key collision with the admin key fails startup.

Authentication and key scopes Configuration reference

# agent.talon.yaml
agent:
  name: support-slack-bot
  tenant_id: default
  key:
    secret_name: support-bot-talon-key

# one file = one AI use case
# one vault secret = one traffic identity

One effective policy

Resolve the policy once, then use it everywhere.

The gateway owns providers and organization_policy. The agent file owns one explicit use-case override. Talon deep-copies both into an effective snapshot used by the primary route, every fallback candidate, cost reporting, budget APIs and evidence.

Policy examples Agent cost controls

# talon.config.yaml
gateway:
  organization_policy:
    default_pii_action: warn
    allowed_providers: [openai, ollama]
    max_data_tier: 2

# agent.talon.yaml
policies:
  allowed_providers: [ollama]
  models:
    allowed: [llama3.2]
  data_classification:
    input_scan: true

Monotonic organization boundaries

An agent can specialize the baseline without weakening hard constraints.

Policy domain	Resolution rule	Operator question
PII actions	The organization action is a minimum floor; an agent may tighten it but a weaker action is ignored.	May this data leave in this form?
Provider/model access	Organization restrictions remain binding; agent and provider restrictions are added to the decision.	May this agent call this provider and model?
Data tier	The organization ceiling is hard; an agent may only lower its own maximum tier.	Is this data class allowed on the selected path?
Egress	Organization and agent boundaries are intersected; the destination must satisfy both.	May this traffic go there?
Cost	Positive agent caps replace organization defaults for that use case and feed the same enforcement/reporting calculation.	Should the next call be allowed to spend?
Reliability	Every explicit fallback candidate is evaluated against the same resolved constraints before dispatch.	Can availability recover without bypassing controls?

Fail-closed configuration

A typo should not silently disable a security boundary.

The gateway block is strictly decoded, invalid policy actions and negative limits fail validation, unknown agent-policy fields fail the gateway preflight, and wildcard allow entries are rejected where they would otherwise create ambiguous behavior.

Validation rules Threat model

invalid field or enum
→ startup / doctor failure

unknown agent key
→ HTTP 401

agent key claims another identity
→ HTTP 403

organization hard constraint fails
→ provider call never happens

Tool and action boundary

Govern only actions Talon can actually intercept.

Tool schemas visible in LLM requests can be filtered or blocked. MCP calls routed through Talon can be governed. Local shell commands, file edits, browser actions and direct APIs that bypass Talon are outside the control plane.

Gateway tool governance Policy examples

organization forbids: delete_*
agent allows: search, update, delete_customer

through Talon:
search          → allowed
update          → allowed if policy passes
delete_customer → blocked

local shell bypass → invisible to Talon

Evidence under policy

Prove which identity and policy produced the decision.

Evidence is the proof layer under operation: the reason a request was allowed, denied, redacted, routed, failed over or stopped by budget can be inspected and verified later.

Identity

Authenticated agent, derived tenant, team and session context where present.

Policy

Organization, agent, provider and resolved effective-policy digests are signed with the record.

Outcome

Allow, deny, redact, filter, route or fail-closed result with the decisive reason and layer.

Current boundary

The identity model is shipped; multi-agent discovery is the next fleet step.

A gateway process currently loads one default agent.talon.yaml. The agent identity and effective-policy contract is live now. Discovering and safely reloading many agent files in one process remains tracked product work.

Start small

Give one real AI use case an identity and one enforceable policy.

Create its agent file, mint the vault-bound key, route the application through Talon, and inspect the resulting policy decision before expanding to the next use case.

Add Talon to an app Start with cost Start with egress policy