Check the runtime controls under each AI use case.
Talon’s category is the control plane for company AI use cases. Use this supporting technical checklist to test whether identity, effective policy, spend, failure paths, sessions, sensitive data, intercepted tools, destinations and evidence are handled deliberately.
AI use case runtime
[ ] one vault-bound agent key
[ ] one resolved effective policy
[ ] cost controlled before next call
[ ] transient failure path defined
[ ] asserted sessions explainable
[ ] sensitive data handled before egress
[ ] destination policy enforced
[ ] intercepted decisions evidenced
[ ] evidence integrity verifiableIdentity and policy checks
Can Talon tell which use case is acting and which rules apply?
| Check | Why it matters | Talon proof path |
|---|---|---|
| One agent identity is bound to the use case | Free-form application labels should not become the security principal. | agent.key.secret_name points to one encrypted vault secret; the presented key resolves agent and tenant. |
| Unknown or conflicting keys fail closed | Authentication ambiguity can turn into cross-use-case access. | Unknown keys return 401; identity mismatch returns 403; agent/admin key collision fails startup. |
| The effective policy is computed once | Primary routing, fallback, reporting and evidence must not reinterpret controls differently. | Organization baseline plus one agent override feeds one resolved snapshot and signed policy digests. |
| Organization constraints remain hard | A use-case override must not weaken the company boundary. | PII floor, provider/model restrictions, tier ceiling and intersected egress remain binding. |
| Security-sensitive configuration is strict | A typo must not silently disable a control. | Strict gateway decode, enum/minimum validation and unknown-field preflight. |
Core operating checks
Can the company operate this use case consistently?
| Check | Why it matters | Talon proof path |
|---|---|---|
| Spend is attributable to the authenticated agent | Provider bills alone do not explain which application or session spent. | Per-agent cost views and agent-scoped session cost. |
| Budget decisions happen before provider access | Alerts after spend do not stop the next request. | Configured per-request/per-agent limits and session soft caps. |
| Transient failure has an explicit path | Availability recovery must not bypass policy. | Configured fallback candidates with effective-policy re-check and linked evidence. |
| Runtime policy is shared | Each app should not reinvent model, provider, PII, tool and regional rules. | Organization policy plus one agent override on supported intercepted paths. |
| Asserted sessions are explainable | Multi-request runs need a coherent cost and outcome history. | Session list, export, cost and verification scoped by tenant and authenticated agent. |
European trust checks
Can the operating layer support security, privacy and residency review?
| Check | Why it matters | Talon proof path |
|---|---|---|
| Sensitive input is scanned before provider access | Policy must run before data leaves when the path is governed. | Built-in, Presidio-compatible or local scanner paths where configured. |
| PII action cannot be weakened below the organization floor | One application should not silently relax the company data boundary. | An agent may tighten allow/warn/redact/block posture; weaker actions are ignored. |
| Destination policy is explicit | EU/local intent should constrain actual provider paths. | Hard sovereignty rules plus organization/agent egress intersection and candidate rejection. |
| Intercepted tool exposure is constrained | Agents should not automatically see or execute every available action. | Gateway tool-schema policy and intercepted MCP/tool governance. |
| Runtime decisions are reviewable | Security and audit teams need reasons, not only dashboards. | Signed evidence, policy digests, export and verification. |
Session and subagent semantics
Do not confuse workflow attribution with Talon authentication.
The Talon agent key authenticates the AI use case. Client-supplied session and subagent metadata explains work inside that boundary but is not independent workload attestation. Two agents using the same session text remain isolated.
[ ] agent key is stored outside YAML
[ ] session state is scoped to tenant + agent
[ ] subagent labels are treated as attribution
[ ] no policy decision trusts free-form subagent text
[ ] identical session ids across agents stay separateHonest boundaries
An unchecked path cannot be governed by a checklist.
Local shell commands, file edits, browser actions and direct API calls that bypass Talon remain invisible. HMAC-signed evidence is tamper-evident, not magically immutable. Session caps are soft without atomic reservation. These boundaries belong in the review.
[ ] all critical provider paths cross the control plane
[ ] intercepted tool paths are identified
[ ] bypass paths are documented
[ ] soft budget semantics are understood
[ ] evidence integrity is sampled
[ ] legal conclusions stay outside the software claimUse the checklist as a test plan
Turn every unchecked box into a reproducible experiment.
Create one real agent identity, route the relevant path through Talon, trigger an authentication, budget or policy decision, inspect the session or provider path, and verify the resulting evidence.