Company policy is the source
Organization constraints define the non-weakenable baseline: models, providers, data handling, destinations, cost and governed actions.
Company AI policy · Use-case-specific enforcement
Turn company AI policy into enforceable rules for each AI use case.
Talon keeps one constrained company control model, then resolves only the bounded use-case-specific rules needed by each workload. The runtime may change; the company policy contract should not.
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 digestsCompany baselineUse-case-specific rulesHard constraintsPreventive enforcementAction authorizationVerifiable evidence
The operating problem
AI adoption grows faster than policy enforcement.
A support bot, coding agent and internal assistant should not each translate company policy into a different provider, runtime or workflow configuration. Talon keeps the company intent stable and resolves the technical rules at the use-case boundary.
Use cases declare only what differs
Each AI use case gets an effective policy from the company baseline plus bounded use-case-specific parameters or tighter constraints.
Runtime is an integration surface
MCP, a model gateway, n8n, a coding agent or a custom app may enforce different parts of the contract without becoming a second policy authority.
Shipped identity model
The current implementation uses an agent identity for each AI use case.
Today, each AI use case has one agent file and one encrypted Talon key reference. That is an implementation detail of the current OSS product, not the category definition; the stable product object remains the AI use case, and federated workload identity is an active follow-on.
# 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 identityOne effective policy
Compile company intent into the rules this use case must obey.
The organization baseline owns the hard company constraints. The current agent file can add one explicit use-case-specific override. Talon resolves both into a single effective snapshot used by the supported provider, data, cost, fallback and evidence paths.
# 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: trueMonotonic 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.
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 happensEnforcement boundary
Keep one policy authority; choose the strongest honest enforcement point.
Talon does not claim universal control. Today it can prevent decisions on provider/gateway paths and intercepted MCP/tool calls it actually sees. The architecture is designed to INTERCEPT where Talon owns the boundary, DELEGATE where a runtime exposes a pre-execution authorization hook, COMPILE only where native controls are sufficiently expressive, and VERIFY where prevention is not honestly possible.
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 TalonExternal containment — shipped reference integration
Let OpenShell enforce a Talon policy decision before provider credentials are injected.
NVIDIA OpenShell v0.1.3 can call Talon through its supervisor middleware at the request-side PRE_CREDENTIALS hook. Talon makes the model, provider, data and budget decision; OpenShell enforces the returned verdict and provides sandbox containment and network policy. Signed Talon evidence records the decision as delegated_expected, not as observed enforcement. This integration does not yet inspect provider responses or provide Talon retries and fallback.
Evidence under policy
Proof follows enforcement; it is not the category.
Evidence records the identity, effective policy and decisive outcome Talon observed or enforced. It helps operators explain and verify what happened later without turning Talon into a generic audit or GRC system.
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.
Fleet boundary
The same policy model now applies across a discovered fleet.
With agents_dir, one Talon process can discover and serve many AI use cases, each with its own compiled runtime bundle and key binding. Periodic safe reload activates valid generations atomically and keeps last-known-good state when edits are invalid.
Start with one real use case
Prove that a company rule can prevent a real outcome.
Put one AI use case on a governed path and test a rule that matters: block a disallowed provider or destination, stop an intercepted action, or enforce a hard budget. Then add another use case only if reusing the company policy is easier than rebuilding it in the new runtime.