PII / redaction layer
Best when the main requirement is to detect and transform sensitive content before or after an LLM call.
A PII proxy can be the right narrow answer when the job is detection or redaction. Talon is useful when every governed AI use case also needs an authenticated identity, one effective policy, shared budgets, policy-constrained reliability, session understanding and verifiable runtime decisions.
PII layer
→ detect sensitive text
→ redact / mask / block
Talon control plane
→ authenticate agent identity
→ resolve effective policy
→ use PII findings
→ also check cost, model/provider, tools, region
→ record session/runtime path
→ sign the decision evidenceCore difference
Best when the main requirement is to detect and transform sensitive content before or after an LLM call.
Best when the company needs a common authenticated runtime operating layer across several AI use cases.
Talon can use built-in, Presidio-compatible and local scanner engines on supported paths, so a specialist detection service can remain part of the design.
Comparison
| Need | PII / redaction layer | Talon |
|---|---|---|
| Detect and transform sensitive text | Design center | Supported policy domain with selectable scanner paths. |
| Authenticate the AI use case | Usually outside design center | One vault-bound agent key resolves the agent, tenant and policy principal. |
| Stop the next request by budget | Usually outside design center | Per-request and per-agent controls plus agent-scoped session soft caps. |
| Preserve policy during supported fallback | Usually outside design center | Every fallback candidate is re-checked against the resolved effective policy. |
| Apply model/provider/tool/region policy | Usually outside design center | Organization constraints plus one explicit agent override on governed paths. |
| Understand asserted sessions | Usually outside design center | Session list, export, cost and verification inside the authenticated agent boundary. |
| Verify runtime decision integrity | Depends on implementation | HMAC-signed evidence with identity and policy digests. |
Scanner choices
Current Talon supports built-in detection plus external Presidio-compatible and local scanner engines on documented paths. Scanner identity and failures can become runtime evidence, and enforcement-path failures can fail closed rather than silently weakening policy.
authenticated request
→ scanner boundary
→ PII/data facts
→ resolved effective policy
→ allow / warn / redact / block
→ signed runtime evidence
# scanner is an input to policy
# not the whole product categoryPolicy composition
Talon combines scanner results with the authenticated agent, organization constraints, model/provider access, budget state, egress rules and visible tools. The agent may tighten the organization PII floor but cannot weaken it.
agent key
+ organization PII floor
+ agent data policy
+ scanner result
+ model / provider / egress constraints
= one pre-provider decisionWhen to choose which
Use a dedicated PII layer when the primary requirement is detection/redaction and the rest of the operating stack already exists. Use Talon when teams are separately rebuilding identity, budgets, reliability behavior, policy and session history across multiple AI use cases.
Need only:
- detect PII
- redact PII
→ narrow PII layer may be enough
Need also:
- authenticated use-case identity
- shared budgets
- policy-safe fallback
- common runtime policy
- session explanation
→ Talon is closer to the primary jobPractical test
Create an agent identity, run a test request, inspect the PII facts, policy outcome, provider path and evidence. The point is not that redaction is unimportant; it is that companies operating several AI use cases usually need more than one isolated control.