KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition Kolawole Quadri Veldt Labs USA [email protected]
arXiv:2605.25376v1 [cs.CR] 25 May 2026
Abstract Observability tells operators when an agent is slow. KYA tells operators when an agent is wrong, drifting, leaking, or quietly going rogue. We present KYA (Know Your Agents), an open-source trust and governance layer for autonomous systems composed of five primitives: (1) a four-gate inbound apply pipeline; (2) an only-tighten composition algebra over a three-channel multi-tenant hierarchy; (3) KYP — Know Your Principal, a schema-level unification of trust scoring across human users, AI agents, and service accounts; (4) auditable interaction-multiplier amplification over an AIVSS-shaped additive baseline; and (5) two-axis delegation attribution — a static premium for risky delegates and a runtime debit for actual delegate misbehavior in multi-agent fan-out. KYA is framework-agnostic across 15+ agent frameworks. On a 4 × 9 cross-backend matrix all 36 cells pass; the pure-function scorer runs sub-millisecond at p99 and the system sustains ≈ 1,800 ops/sec at 20 concurrent workers with HMAC chain integrity preserved end-to-end. KYA detects 89% of 1,200 adversarial probes from PyRIT and Garak, including the recently-published topologyguided multi-agent attack. The system is available under Apache 2.0 as the veldt-kya package on PyPI (release candidate at submission time; stable v0.1.0 forthcoming).
By mid-2026 several of these platforms have added audit-log surfaces and EU AI Act compliance marketing, but the artifacts they emit are operator-internal audit: who-changed-what, whoran-which-eval, SOC 2 RBAC, platform-level access logs. None produces agent-identity-bound, cryptographically verifiable, third-party-attestable governance artifacts — because that is not what an observability platform is for. KYA addresses that distinct layer and composes with observability rather than replacing it: kya_otlp_bridge (section 3) consumes OpenTelemetry spans from any of the above as one input source, but KYA operates standalone without them. The gap is not in telemetry. It is in agent identity, evidentiary provenance, and enforceable behavioral contracts — a separate category that composes on top of telemetry rather than competing with it. This paper presents KYA (Know Your Agents), an open-source trust and governance layer for autonomous systems.1 KYA targets the agent-identity / evidentiary-provenance gap with five primitives that, in combination, support the audit, attestation, and federated policy distribution demands of modern AI governance frameworks including the EU AI Act [22], NIST AI RMF [58], ISO 42001 [33], and SR-11/7 [8].
CCS Concepts
Contributions
• Security and privacy; • Computing methodologies → Artificial intelligence;
KYA is a systems contribution: a code-verified governance layer for autonomous systems whose novelty lies in the composition discipline, the formal safety properties of that composition, and a small set of engineering primitives that make the system deployable in regulated multi-tenant environments. We do not claim new cryptographic constructions or new mathematical primitives — foundational citations include Schneier and Kelsey (1998) [72], Bellare and Yee (1997) [6], Back and von Wright (1998) [2], and Bell and LaPadula (1976) [4] — but the composed system has no equivalent in the surveyed prior art [31, 50, 55, 81]. We claim five contributions:
Keywords agent governance, autonomous systems, trust, audit, federated learning, AI safety, EU AI Act
1
Introduction
Autonomous agents now decide loans, triage patients, adjudicate benefits, and execute trades [31, 89]. The observability platforms shipped alongside them — LangSmith [46], Phoenix [1], Langfuse [44], Braintrust [10], Weave [86] — answer when an agent is slow, expensive, or generating errors; that is the observability category and they execute on it. Governance is a distinct layer. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. FAccT ’27, TBD © 2027 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-xxxx-xxxx-x/27/06 https://doi.org/10.1145/xxxxxxx.xxxxxxx
(1) A four-gate inbound apply pipeline composing Ed25519 signature verification, expiration check, only-tighten composition, and operator-approval-as-default (section 7). Generalizes TUF/Uptane [45, 69] rollback prevention from a versioncounter to a policy-strength lattice. (2) An only-tighten composition algebra for tenant-scoped policy overrides (section 7). Tenant overrides can restrict, but never loosen, platform default weights; the property 1 The phrase "Know Your Agent" was coined by Chaffer (2025) [12] for an agent-only Web3 identity framework; we use KYA (Know Your Agents), plural, for the multiprincipal trust layer described here and re-anchor the agent-identity framing on a unified principal taxonomy (KYP) in section 5.6.
FAccT ’27, June 2027, TBD
is structurally a refinement-calculus result (Back and von Wright, 1998 [2]) applied to agent risk weights composed with cryptographically signed external recommendations. Lemma 1 establishes soundness. (3) KYP — Know Your Principal unified trust taxonomy (section 5). A schema-level unification (single table, one principal_kind discriminator) of trust scoring across three principal kinds — human user, AI agent, service account — with shared signal mechanics. Closest commercial framing is Okta’s 2026 NHI initiative [62]; closest agent-governance system, Microsoft’s Agent Governance Toolkit [55], scores agents only. (4) Auditable interaction-multiplier amplification over an AIVSS-shaped [65] additive baseline (section 4). A bounded asymmetric (multipliers ≥ 1.0 only, product-capped at MAX_MULTIPLIER) registry of named pairwise interactions surfaced to the auditor with stable code strings. AIVSS, CVSS [24], and FAIR [78] are all purely additive or formuladriven without per-interaction audit codes. (5) Two-axis delegation attribution (section 4, section 5). On the static-score axis, an additive-with-cap delegation-trust premium with an observation gate that prevents the coldstart false positives EigenTrust [41] suffers. On the dynamictrust axis, an actor_agent_key convention at three hooklayer entry points: when orchestrator 𝐴 triggers sub-agents 𝐵/𝐶/𝐷 and any sub-agent fires a rogue signal, the signal is tagged with actor_agent_key=𝐴 so 𝐴’s principal-trust counter is debited at runtime. The static axis factors in risky delegates; the dynamic axis registers actual delegate misbehavior. Default actor_agent_key=agent_key makes attribution work without per-customer wiring. Names the "clean orchestrator delegates to risky downstream" attack pattern (Liang et al. [49]) as the contribution.
Why now Three forces compound. GPAI obligations under the EU AI Act [22] have been in force since August 2025; risk classification, postmarket monitoring, and incident reporting exceed what observability tools produce. The agent-governance subfield emerged in twelve months (AIVSS [65], AAGATE [31], Aegis [50], SIGIL [74], TrustPact [81], Microsoft AGT [55]). Agentic systems have moved from prototypes to production write paths in finance, healthcare, and government. Framework-agnosticism is a hard requirement, not a convenience.
Paper organization Section 2 states the threat model and design goals. Section 3 describes the four-piece KYA stack and its deployment topology. Section 4–section 7 present the five contributions in detail. Section 8 reports empirical results across four storage backends, concurrency loads, and adversarial red-team campaigns. Section 9 surveys related work, section 10 states limitations and open problems, and section 11 concludes. KYA ships under Apache 2.0 as veldt-kya [85]; reproducibility artifacts accompany the release.
Kolawole Quadri Observability platforms (LangSmith, Phoenix, Langfuse, Braintrust, Weave — 2026)
KYA: trust + governance layer (this work)
Latency, cost, traces
Agent identity (KYP)
SOC 2 access logs
Tamper-evident evidence chain
Platform audit-log surface
Enforceable behavioral contracts
EU AI Act marketing
gap
Answers operational questions: how long, how much, what path?
Federated signed recommendations
Answers accountability questions: was it wrong, did it leak, who is responsible?
Figure 1: The agent-identity / evidentiary-provenance gap. By mid-2026 the observability layer markets audit logs; KYA addresses the remaining gap: verifiable, third-party-attestable, agent-identity-bound governance artifacts.
2
Threat Model and Design Goals
We model an autonomous agent as a stateful program 𝐴 with an identifying definition 𝐷𝐴 (system prompt, model selection, tool set, configuration), a runtime invocation context 𝐶, a set of principals (users, sub-agents, services) participating in the session, and an action output 𝑎 ∈ Actions. KYA reasons about threats that manifest in 𝐷𝐴 (definitional integrity), 𝐶 (runtime behavior), the principals (identity / accountability), or the boundary between 𝐴 and the outside world (data leakage, cross-tenant access).
2.1
Threat taxonomy
We organize threats along two orthogonal axes (fig. 2): static vs. dynamic (whether the threat arises from the configuration or runtime behavior) and internal vs. external (whether the threat originates from a privileged operator or an external adversary). The taxonomy is informed by recent literature on attack patterns in multi-agent LLM systems [25, 31, 49, 50]. T1 (static, internal): Definition drift. Edit to 𝐷𝐴 (swap model, add write tool, weaken prompt) after approval but without re-triggering governance review. Detected via canonical-hash mismatch over enumerated policy-bearing fields (section 6.5). T2 (static, external): Supply chain. Dependency replacement (typosquat, compromised framework, malicious marketplace update). Static scoring tags each dependency with publisher-trust class + supply-chain premium; signed inbound channel (section 7) provides Ed25519-verified updates. T3 (dynamic, internal): Capability drift. Runtime tool call outside sanctioned set, or tenant_id outside scope. Observed via out-of-scope + cross-tenant counters (section 5). T4 (dynamic, external): Prompt injection / jailbreak. Adversarial instructions embedded in agent input. Observed via policy-violation counter, prompt-injection quality signal, red-team integration (section 8).
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition Internal
External
Static
Static · Internal T1 Definition drift (canonical hash, §6.5)
Static · External T2 Supply-chain compromise (publisher trust, §4)
Dynamic
Dynamic · Internal T3 Capability drift T5 Data leakage T8 Attribution evasion (rogue signals, §5)
Dynamic · External T4 Prompt injection T7 Topology propagation (red-team + delegation, §8)
Table 1: Threat coverage comparison. Columns: DEv = DeepEval, TEv = TrustEval, TPa = TrustPact, MAG = Microsoft Agent Governance Toolkit [55], AUR = AURA [71]. ✓: full coverage; ◦: partial; –: none. DeepEval and TrustEval are LLMevaluation libraries and AURA is an academic risk-scoring framework; their – cells on threats outside evaluation (T1, T6, T7, T8) reflect category scope — they were not designed to cover audit-tampering or topology-attack defense — rather than deficiency. Their outputs compose into KYA’s evidence chain as quality signals. Peer governance-layer comparison concentrates on MAG and TPa; fuller per-system treatment is in section 9.
Post-hoc audit (any axis) T6 Audit-log tampering — HMAC chain verify (§6)
Figure 2: KYA’s threat taxonomy. Each quadrant labels which KYA primitive detects the corresponding class of threat. T7– T8 are informed by recent multi-agent attack literature.
T5 (dynamic, internal): Data leakage. 𝐴 emits data outside its sanctioned class (PHI / PII / trade secrets / ITAR). Observed via data-leak counter; default classifier covers civilian, defense, NATO, and EU schedules. T6 (any, post-hoc): Audit-log tampering. Compromised operator modifies historical records. Detected via HMACchain verification with dialect-aware concurrency serialization (section 6). T7 (dynamic, external): Topology attack. The “clean orchestrator” pattern: adversary compromises an exposed edge agent and propagates influence to a clean orchestrator that triggers no signals itself (40–78% attack success rate against undefended systems [49]). Detected via delegation-trust premium (static axis) + actor-agent attribution (dynamic axis). T8 (dynamic, internal): Attribution evasion. Sub-agent rogue signals attributed to the puppet instead of the orchestrator, hiding the responsible upstream principal. Detected via the actor_agent_key convention (section 5.7) defaulted at three SDK entry points.
2.2
Assumptions
We assume a trusted operator holding the per-(tenant, invocation) HMAC key; a trusted central collector (the SDK vendor) holding the Ed25519 inbound-signing key in KMS or HSM (compromisedcollector handling: section 7); honest-but-curious storage backends (observed but not tamper-proof); and standard cryptographic assumptions — HMAC-SHA256 unforgeable [6, 72], Ed25519 EUFCMA secure [7].
2.3
Design goals
KYA targets seven goals: G1. Framework-agnostic — one adapter per framework, not a per-framework rewrite of the core;
FAccT ’27, June 2027, TBD
Threat
DEv
TEv
TPa
MAG
AUR
KYA
T1 Drift T2 Supply-chain T3 Capability drift T4 Prompt injection T5 Data leakage T6 Audit tampering T7 Topology attack T8 Attribution evasion Federation
– – ◦ ◦ – – – – –
– ◦ ◦ ✓ ✓ – – – –
– – ✓ ✓ ◦ – – – –
◦ ◦ ✓ ✓ ✓ ◦ ◦* – ◦*
– ◦ ◦ ◦ – – – – –
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
* MS-AGT discusses cross-org federation as future work [52]; topology
defense via inverse direction (parent caps child) rather than upward attribution.
format_adapter.py ships 15+ native adapters (LangChain, CrewAI, OpenAI Assistants/Agents, Claude Agent SDK, AutoGen, Semantic Kernel, LlamaIndex, Haystack, Bedrock, Vertex, MCP, and others). G2. Verifiable evidence — Schneier-Kelsey-class HMAC chain [72] with the deployment-shape extensions of section 6. G3. Multi-tenant safe by default — Cedar-style forbiddominance [17] extended to a three-channel hierarchical authority (section 7). G4. Operationally light — pip-installable on Python 3.10+, sub-millisecond scoring on the hot path, only SQLAlchemy as a hard core dependency. G5. Regulator-legible artifacts — direct mapping to EU AI Act risk tiers, NIST AI RMF functions, HIPAA / NYDFS / FDA PCCP [83] formats. G6. Federation without data hoarding — only aggregated weight recommendations cross organizational boundaries, only after operator review. G7. Closed-set extensibility — every trust-layer dimension enumerated; new kinds require SDK release, preventing caller-supplied keyspace expansion.
3
System Architecture
KYA is delivered as a coordinated four-piece stack (fig. 3). The core SDK (kya, distributed on PyPI as veldt-kya [85]) is a pure Python library with one hard dependency (SQLAlchemy [3]) and optional extras for metrics, tracing, webhooks, and an LLM judge. Three sibling components extend the core: kya_hooks provides in-process integrations for popular agent frameworks; kya_otlp_bridge ingests OpenTelemetry [14] spans and translates them into KYA signals; and kya_redteam runs adversarial probing campaigns via PyRIT [53] and Garak [19]. Only kya is required; the other three are opt-in. The total artifact spans 50+ Python modules with
FAccT ’27, June 2027, TBD
Kolawole Quadri
in-process req
kya_hooks
kya_otlp_bridge
Claude / LangChain /
sidecar container
OpenAI Agents
OTLP → KYA
Layer 1: Auth / RBAC
Layer 2: Action gate
JWT → roles → endpoint check
rule-fire-time governance verdict
Layer 3: Tool RBAC loop-time per-tool role check
action dispatched
L2 verdicts: allow | block | redact throttle | flag_for_review
kya (core) PyPI: veldt-kya 50+ modules Effective permission =
kya_redteam PyRIT + Garak
𝐿1 ∩ 𝐿2 ∩ 𝐿3
Figure 4: Three runtime enforcement layers. The effective permission for any agent-driven action is the intersection 𝐿1 ∩ 𝐿2 ∩ 𝐿3 .
adversarial campaigns
out-of-band
Figure 3: The four-piece KYA stack. kya runs in the agent process; kya_hooks attaches to LangChain / CrewAI / OpenAI Assistants / Claude Agent SDK / OpenAI Agents loops; kya_otlp_bridge runs as a sidecar that consumes OpenTelemetry spans; kya_redteam runs out-of-band as an adversarial fleet.
cross-backend portability across PostgreSQL, SQLite, DuckDB, and MySQL.
3.1
Component overview
kya (core SDK).. Trust scoring, evidence chain, versioning, drift detection, tenant-weight overrides, inbound signing, principal trust (KYP, section 5.6), and the adapter registry all live in the core. Modules are organized by concern (static scoring, dynamic signals with actor-agent attribution, HMAC evidence chain, canonical-hash drift, snapshots, KYP, only-tighten overrides, bounded multipliers, closed-loop feedback, four-gate inbound apply, pluggable adapters); file-line citations in section D. The core has no imports from any agent framework and depends only on the Python standard library, SQLAlchemy, and optional extras. kya_hooks (framework integrations). A thin per-framework shim that registers callbacks into the agent’s invocation loop and emits canonical events into the core. Native support ships for Anthropic’s Claude Agent SDK, LangChain (callback handler), and OpenAI’s Agents SDK. The actor_agent_key=agent_key default convention (section 5.7) is hard-wired at all three entry points so that orchestrator attribution works without per-customer wiring. kya_otlp_bridge (telemetry ingestion). A standalone container that consumes OpenTelemetry OTLP spans (via gRPC or HTTP) and maps them into KYA signals. The bridge extends OTel ingestion in four notable ways: (1) a span-kind → evidence-semantics taxonomy across six OpenInference kinds (LLM, TOOL, AGENT, RETRIEVER, GUARDRAIL, EVALUATOR); (2) cross-batch trace stitching via a TTL-capped trace_id → invocation_id cache so child spans arriving in separate batches attach to the same invocation; (3)
principal-identity normalization (normalize_agent_key) preventing the dual-principal split where customer-registered agents and OTel-runtime emissions become two principals; (4) capture-time sensitivity hinting where data-classification tags on spans drive retention-policy enforcement at the moment evidence hits storage. kya_redteam (adversarial probing). An out-of-band campaign runner that drives PyRIT orchestrators and Garak probes against a target agent deployment. Findings are written back through the same record_evidence() path as production events, so red-team discoveries land in the same HMAC chain as runtime observations. The module includes a curated set of native probes (DAN persona break, base64/character-split encoding-evasion, prompt extraction, Goodside override, markdown injection) that run without an external Garak install. Deployment topology. Raw prompt/completion payloads remain in the customer process; only aggregated telemetry crosses the organizational boundary, and only signed policy recommendations come back (section G).
3.2
Three-layer runtime gates
KYA composes with three orthogonal enforcement layers, each evaluated at every agent action (fig. 4): Layer 1 — Authentication and RBAC.. Standard HTTP-requesttime authorization: the caller’s identity and roles are resolved from a JWT; admin endpoints require explicit privilege checks. KYA reads these decisions but does not own them. Layer 2 — Action gate. When a rule fires or an agent dispatches an action, the gate evaluates governance policies against the action payload. Verdicts are allow, block, redact, throttle, or flag_for_review; each verdict is logged to the evidence chain. The gate consults tenant-scoped weights (section 7) and class-tagged data classifications to make its verdict. Layer 3 — Tool RBAC.. At every tool call inside an agent’s invocation loop, KYA verifies that the calling user’s roles intersect the tool’s required-role set. The default catalog ships with the SDK; tenants may tighten (but not loosen) it via override under the onlytighten algebra of section 7.
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
3.3
Persistence and cross-backend portability
KYA’s storage primitives run unchanged against PostgreSQL, SQLite, DuckDB, and MySQL: dialect-aware variant types (_po rtable.py), schema retargeting via SQLAlchemy’s schema_tr anslate_map, and an upsert dispatcher (_dialect_helpers.p y) that emits the right ON CONFLICT grammar per backend. Runtime concurrency uses the dialect-aware serialization primitive of section 6.3. A fresh pipinstallveldt-kya is usable end-to-end without provisioning a database server via kya.default_sessio n()’s SQLite fallback. The full stack is validated across the 4 × 9 phase matrix and the 17 × 4 per-table matrix of section 8.
3.4
Cross-cutting design disciplines
Five design disciplines recur across the 50+ SDK modules and are load-bearing for KYA’s claims: closed-set whitelists with explicit "unknown" buckets (signal kinds, principal kinds, evidence kinds, inbound scopes, data classes, compliance regimes — every scoring/persistence dimension is a closed enumeration; caller-supplied strings cannot expand the keyspace); bounded composition everywhere (per-factor caps, MAX_MULTIPLIER=2.0, delegationtrust cap 25, final score clamp to 100); asymmetric composition rules (data sensitivity via MAX, security capabilities via SUM, interaction multipliers ≥ 1.0 only — register_interaction raises on < 1.0); explicit "never X" runtime invariants (never autotune, never apply-anyway on signature failure, never bypass human gate on critical verdicts, never break scoring on hot-path exceptions, never leak across tenants); and fail-soft observability (Valkey / Phoenix / collector / prometheus_client unreachable ⇒ core scoring and persistence continue). Each is a hard runtime check, not a convention; section D enumerates the source-line citations.
3.5
Running example: a loan-decisioning agent fleet
We anchor the rest of the paper in a single scenario revisited across sections 4 and 6 to 8. A mid-size US regional bank operates a four-agent loan-decisioning fleet under NYDFS Part 500, ECOA, and CFPB UDAAP oversight: a Loan Triage Agent (orchestrator) coordinates a Document Verification Sub-Agent (OCR + identity-matching against a third-party KYC provider), an OFAC Screening Sub-Agent (sanctions list lookup), and a Risk Review Agent (credit-policy reasoner with write authority to flag applications for human underwriter review). Principals span all three KYP kinds: the underwriter (user), the four agents (agent), and a nightly batch reconciliation job (service_account). Data classes in scope are PII (ssn, dob, address), financial (account_number, income, debt-to-income), and KYC documents (driver’s license, utility bill). The fleet’s adversary surface includes prompt injection in uploaded documents [49] (T4), out-of-scope tool calls by the Risk Review Agent (T3), data leakage of SSN in summary outputs (T5), and topology-guided propagation from a compromised Document Verification Sub-Agent upward into a clean Triage orchestrator (T7). Section 4 scores the four agents; section 6 traces a single application through the HMAC-chained evidence log; section 7 demonstrates a cross-bank federated recommendation tightening the OFAC tool multiplier after a sector-wide incident; section 8
FAccT ’27, June 2027, TBD
reports the topology-attack detection result against exactly this fleet topology.
3.6
Second domain: a clinical triage agent
The framework-agnostic claim (G1, section 2) requires the primitives to land cleanly on domains that share no regulator, threat surface, or data taxonomy with loan decisioning. We anchor this with a parallel scenario revisited briefly in sections 4 and 6. A regional hospital network operates a clinical triage fleet under HIPAA, 21 CFR Part 11, and FDA SaMD oversight: a Triage Orchestrator (intake-symptom parser, no write authority of its own) coordinates a Diagnosis Suggestion Sub-Agent (LLM-driven differential shortlist, suggest-only), an HL7 Lookup Sub-Agent (readonly EHR record fetch), and a Medication-Interaction Checker (rules-engine wrapper, no write authority). Principals span the same three KYP kinds as the loan fleet but in different proportions: the attending nurse and supervising physician (user), four agents (agent), and an overnight bulk-ingest job pulling HL7 deltas (service_account). Data classes are different: PHI (medical record number, diagnosis codes, lab results), ePHI (real-time vitals from monitors), and phi_genetic. The threat surface shifts accordingly: T4 prompt injection in patient-history free-text; T5 disclosure of diagnosis to an unauthorized requester; T7 topology propagation from a compromised HL7 sub-agent up into the orchestrator (the same primitive defends, but the upstream attack vector is the EHR API rather than an OCR pipeline). What makes this fleet a useful test of framework-agnosticism is that nothing about the KYA primitives — not the scoring factors, not the only-tighten algebra, not the KYP principal-trust schema, not the actor-agent attribution convention — requires per-domain customization. The compliance regime mapper (kya.compliance) returns HIPAA-shaped retention windows (6 years) and breach-notification SLAs (60 days) in place of the bank’s ECOA / NYDFS configuration, and the data-class taxonomy reports MAX-weighted sensitivity according to the same monotone schedule.
4
Static Risk Scoring
KYA’s static risk model is structurally an AIVSS-shaped weighted scorer (OWASP AIVSS v0.5 [65]): a per-factor decomposition followed by an aggregation step. We do not claim novel scoring mathematics. The contribution at this layer is twofold: (1) an auditable interaction-multiplier amplification step over the AIVSS-shaped additive baseline (section 4.2), and (2) a set of design disciplines (closed-set whitelists, asymmetric MAX-vs-SUM composition rules, bounded composition, explicit-over-inferred precedence, fail-soft scoring) that make the factor model auditable end-to-end. The scoring pipeline composes with the only-tighten algebra (section 7) and the HMAC-chained evidence log (section 6) so every score and its per-factor decomposition is recoverable from the audit chain.
4.1
Factor decomposition
The static score 𝑆 (𝐷𝐴 ) is the sum of deltas from independent factor functions (table 2). Each returns a structured RiskFactor(name, label, delta) record preserved in AgentRiskScore and persisted into the evidence chain; an auditor querying any score can recover
FAccT ’27, June 2027, TBD
Kolawole Quadri
Table 2: Static-score factors. MAX = take the highest applicable; SUM = sum applicable values; cap = listed ceiling. Factor
Aggregation / weight
Cap
Base score Write-tool count Admin-gated tools Governance mode
constant +5 +4 per write tool +8 per admin-gated tool none=+30, on-loop=+15, hybrid=+10, in-loop=0 +12 if True +8 if True
— — — —
can_override flag can_revert flag access_level=write Data sensitivity Security capabilities Provenance Model trust Blast radius Deployment environment Delegation depth Supply chain Input sources Lifecycle Compliance scope Trust signals Cost burn Delegation-trust prem.
+6 MAX (public to top-secret) SUM (orthogonal powers) MAX (builtin → third-party) MAX (enterprise → self-host) SUM composite MAX (dev to enclave) MAX chain length SUM + breadth premium SUM + breadth premium SUM (signed, approval, age) MAX regulatory severity SUM (neg. for evidence) SUM operational anomaly SUM observation-gated
Auditable per-interaction codes. Each interaction carries a stable string code surfaced on the scoring result so an auditor or UI can render "why was this score amplified." The 10 pre-registered interactions include:
— — — 60 60 20 10 30 25 25 35 25 — — — — 25
its full per-factor attribution. Section E gives the per-bucket weight schedules and edge cases. Why MAX vs SUM matters. The asymmetry is load-bearing: data sensitivity aggregates via MAX because handling PHI is what makes an agent high-stakes (touching internal + confidential + PHI does not triple-count); security capabilities aggregate via SUM because having both code_execution and shell_access is materially worse than having one. ITAR is weighted above civilian secret because ITAR violations carry felony export-control consequences. unknown input source is weighted higher than declared external_api because declaration is information; absence is suspicious. Most weighted scoring systems use a single composition rule throughout (CVSS’s nested formula, FAIR’s Monte Carlo, AIVSS’s single threat multiplier); KYA’s choice-per-dimension with documented rationale (table 2) is a design discipline worth naming.
4.2
The interaction-multiplier amplification step
The additive sum captures the bulk of the signal but misses compounding effects. A write tool that touches PII in an autonomous deployment is materially more dangerous than the linear sum of those three factors suggests. KYA defines an explicit registry of interactions — predicates over 𝐷𝐴 and the factor list that trigger a multiplicative bonus. This is the strongest claim of novelty in the scoring layer. Closed-form composition. Let 𝑆𝑎𝑑𝑑 be the additive score and let I (𝐷𝐴 ) be the set of interactions that fire for 𝐷𝐴 . The final additive score is 𝑆 (𝐷𝐴 ) = min 100, 𝑆𝑎𝑑𝑑 · min MAX_MULTIPLIER,
Ö
Asymmetry enforced at runtime. The register_interaction (code,name,condition,multiplier,description,severity) function raises ValueError if multiplier < 1.0 (interactions.py :268). The rule is not a convention but a runtime invariant: "Use credit factors (citation, audits) for downward deltas."
𝑚𝑖
𝑖 ∈ I (𝐷𝐴 )
with MAX_MULTIPLIER = 2.0 (capped product) and 𝑚𝑖 ≥ 1.0 for every registered interaction (asymmetric: amplify, never reduce).
• autonomous_writer_in_prod (1.3×, critical) • code_exec_with_user_input (1.5×, critical): "Classic RCEvia-prompt-injection setup. Treat as if attacker controls code execution on the host." • classified_autonomous (1.4×, critical): "EU AI Act Art. 14 and US classification regimes both require effective human oversight — this combo violates both spirit and letter." • untrusted_chain (1.2×, warning): marketplace agent fanning out to ≥ 3 delegates. • unaudited_classified (1.25×, critical): "Classified data being handled but no red-team / bias / fairness audit evidence on file." • rejected_in_prod (1.4×, critical): an agent with security review status rejected but running in production. • orphan_writer_in_prod (1.2×, warning). • prod_marketplace_writer (1.2×, warning). • self_hosted_with_pii (1.2×, warning). • unowned_high_risk (1.15×, warning). The registry is extensible: tenants register custom interactions via register_interaction(), which appear in subsequent decompositions under their registered code. CVSS, AIVSS, and FAIR have no equivalent surface; AIVSS’s "single threat multiplier ThM" applies once after a linear AARF sum and is not per-pair. Ablation: do multipliers change operator-visible buckets? We measure whether the multiplier step crosses bucket boundaries relative to the additive-only baseline. The harness (examples/interacti on_multiplier_ablation.py) scores six agent definitions twice — once with disable_interactions=True (additive only) and once with multipliers enabled — and reports the buckets either side. Results in table 3: two of six cross a boundary attributable specifically to the multiplier step (rows 2 and 4: high→critical via code_exec_with_user_input at 1.5×, and medium→high via untrusted_chain at 1.2×). Two saturate at the additive ceiling already (governance = none alone contributes +30); for those, the multiplier records a code on the audit trail but does not change the bucket. The benign control fires no multiplier — no false positives in this scenario set. The honest takeaway: multipliers visibly move buckets on moderate-risk agents with human-in-the-loop discipline but a single concentrated risk concentration (untrusted chain, code-exec with user input, etc.). For already-critical configurations they add an audit code but do not change the operator-visible bucket because clamping at 100 dominates. The ablation justifies the multiplier step’s presence on the moderate-risk middle of the distribution — exactly where bucket boundaries matter for review-queue triage.
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
Table 3: Interaction-multiplier ablation. Each row scored twice: additive-only baseline, then with multipliers. Two of six cases cross a bucket attributable to the multiplier step. “Add” is the additive score; “Final” is after multiplier × capping at 100. Single workstation; deterministic across runs.
4.3
Scenario
Add
AddBkt
Final
FinBkt
Mult
autonomous_writer_in_prod code_exec_user_input_hil self_hosted_pii_hil untrusted_chain_hil replit_style_autonomous benign_readonly_hil
86 63 64 57 100 34
critical high high medium critical medium
100 94 77 68 100 34
critical critical high high critical medium
1.30 1.50 1.20 1.20 1.95 1.00
Score buckets
FAccT ’27, June 2027, TBD
(a) Additive baseline Sadd = 198 (clamped to 100) write_tools (3) admin_tools (1) human_loop=none can_override access_level=write data_classes (PHI) security_caps (net+fs) provenance: marketplace model_trust: open deployment: prod blast_radius delegation_depth=2 supply_chain lifecycle (pending) trust_signals (stale) compliance_scope +0 0
+8
fired interactions:
+10 +12
+6
×1.3
unaudited_classified
+30
+20
+15
+8
autonomous_writer_in_prod
+30
+12
+6
×1.25
prod_marketplace_writer
×1.2
+15
raw product: ×1.950
MAX_MULTIPLIER cap (2.0): ×1.950
S = min(100, Sadd 1.95)
+10
+4 5
(b) Interaction multipliers
+12
10
final score: 100 15
20
Per-factor delta
25
30
35
bucket: CRITICAL
Figure 5: Static score decomposition for a sample agent. The additive sum is on the left; the multiplicative amplification step with fired interaction codes is on the right.
The headline score is bucketed for human consumption: • [0, 29]: low — safe to run unattended in sandboxed contexts • [30, 59]: medium — routine production with standard monitoring • [60, 84]: high — requires elevated review; surfaces in operator queues • [85, 100]: critical — requires explicit governance approval; auto-gated by the action gate in default policy Bucket thresholds are tenant-configurable through the onlytighten algebra (section 7); tenants can lower the "critical" threshold (treating more agents as critical), never raise it.
4.4
Worked example: scoring the loan-decisioning fleet
Applying the factor model to the four-agent fleet introduced in section 3.5: the Risk Review Agent scores 77 (high): write tool (fla g_for_review, +6), admin-gated tool (override_decision, +12), data sensitivity financial (MAX, +20), governance mode none (autonomous, +30, the largest single factor in the additive model), decision-influence delegate, and the admin_tool_AND_financial _data interaction multiplier fires at ×1.25. The Loan Triage Agent scores 61 (high): no admin tools of its own, but the delegation-trust premium adds 8 for delegating to a high-bucket Risk Review Agent. The Document Verification Sub-Agent scores 42 (medium): read-only KYC lookups, no write authority, but third_party provenance (+20) and pii data sensitivity (+15) keep it above low. The OFAC Screening Sub-Agent scores 34 (medium): read-only, enterprise model, but us_classified data class (sanctions list, +25) and regulator-mandated-tool status. All four scores include the auditable per-factor breakdown returned by score_agent(); no factor exceeds its cap and no interaction multiplier fires silently. Second domain: clinical triage fleet. (section H). The parallel clinical fleet from section 3.6 scores on the identical pipeline: Diagnosis Suggestion 84/critical, HL7 Lookup 56/medium, Triage Orchestrator 70/high (the Triage Orchestrator’s bucket comes from the same delegation-trust premium that lifts the bank’s Loan Triage). Domain changes; pipeline does not.
4.5
Calibration and limitations
The default factor weights are derived from a synthesis of public governance literature [22, 33, 58, 65], internal red-team campaigns
(section 8), and expert judgment. We do not claim the defaults are optimal. What the framework guarantees is that defaults are auditable (every factor and weight in the Apache 2.0 SDK release) and adjustable (tenants tighten via override; signed recommendations propose cross-fleet tightenings). Empirical calibration from collector telemetry is the most consequential piece of future work (section 10).
5
Dynamic Rogue Signals
Static scoring (section 4) measures what an agent could do given its definition. It does not measure what an agent has tried to do at runtime that it should not have. Two agents with identical static scores can have radically different risk profiles in practice: one sits idle, the other has attempted to call a privileged tool fifty times in the past hour. KYA bridges this gap with a small set of runtime signals that aggregate observed misbehavior into a dynamic score delta.
5.1
Signal sources
KYA observes six classes of runtime misbehavior, each instrumented at the point of detection in the agent loop, counted via Prometheus, recorded to the evidence chain, and surfaced through the roguedetection API: tool RBAC refusals — Layer 3 blocks a tool call whose required roles the caller doesn’t have (counter: veldt_too l_rbac_refusals_total); out-of-scope tool attempts (OOS) — agent invokes a tool not in its sanctioned tools list (the strongest single signal; intent to act outside the configured capability surface; counter: veldt_agent_oos_tool_attempts_total); governance blocks — action gate vetoes an action on content-safety, PII, or policy grounds (counter: veldt_governance_action_gate_tota l with verdict=block); cross-tenant attempts — tool call carrying a tenant_id outside the agent’s scope, typically from prompt injection or a compromised upstream caller (counter: veldt_agent_cros s_tenant_attempts_total); data leakage — output containing data of an unsanctioned class, caught by the action gate’s classtagged output classifier (counter: veldt_agent_data_leak_tota l); policy violations — jailbreak, harmful output, refusal failure, or successful prompt injection (counter: veldt_agent_policy_viol ations_total). Signal flow is one-directional: gates emit, the rogue module consumes, but gates do not read rogue state for real-time
FAccT ’27, June 2027, TBD
Kolawole Quadri Single table → one discriminator → three principal kinds
verdicts (preventing the bias feedback loop where prior misbehavior gates legitimate later actions). Per-source instrumentation points are in section F.
user
agent
5.2
Aggregation and bucketing
kya_principal_trust tenant_id uuid (PK) principal_kind varchar (PK, discriminator) principal_id text (PK) trust_score int ∈ [0, 100] signal_counts jsonb last_signal_at timestamptz updated_at timestamptz
One signal-application code path
• same starting score (50) • same bounds [0, 100] • same time-decay • same Valkey-window mirror No per-kind branching.
service_account
The rogue score rogue_score(report) is a bounded integer in [0, 50] that adds to the static score. The score is computed from per-signal counts within a configurable window (default 24 hours), with logarithmic compression to prevent a single very active agent from saturating the score on volume alone: ∑︁ ª © rogue_score = min 50, 𝑤𝑠 · log2 1 + 𝑐𝑠 ® « 𝑠 ∈signals ¬ where 𝑐𝑠 is the count of signal 𝑠 in the window and 𝑤𝑠 is its weight. This rewards breadth (multiple signal kinds) over depth (one signal repeated): an agent that attempted one out-of-scope tool call and emitted one PII leak is treated as more suspicious than one that attempted ten out-of-scope tool calls of the same kind. Validation in fig. 14 (appendix): rogue-event clusters across a 40agent fleet co-occur with annotated attack epochs during a 24-hour Garak [19] red-team campaign.
5.3
Quality signals
Alongside the four rogue counters, KYA tracks three quality signals — weaker per-event but valuable in aggregate: Hallucination signals. Tagged from downstream evaluation: the agent produced a response that an LLM-judge (section 9) or a citation-verification pass marked as unsupported by retrieved context. QA irrelevance. The response failed a relevance check against the original query — the agent “went off topic.” Prompt injection attempts. The user input or upstream context contained signatures of a known prompt-injection template [30]. Whether the injection succeeded is captured separately under policy violations. Quality signals contribute a smaller delta than rogue signals (𝑤𝑞 < 𝑤𝑟 ) because their false-positive rate is higher, but they are useful as early indicators: a rising hallucination rate often precedes a discovered drift event by hours or days.
5.4
Burst anomaly detection
The realtime module (realtime.py) maintains Valkey-backed sliding windows over signal kinds and publishes burst alerts when the per-minute rate exceeds the trailing-hour baseline by a configurable factor. Alerts flow through pub/sub to subscribed operators; the API exposes detect_burst_anomalies() for batch queries. This is the only path through KYA that runs against in-memory state rather than the durable evidence chain — burst detection is intended for live triage, not after-the-fact audit.
5.5
Integration with the static score
The total agent-risk view in operator dashboards is total = static + rogue, clamped to [0, 100]. A purely-defined high-risk agent that has never misbehaved retains its static score; a moderately-defined
[v20 L-removed]
PRINCIPAL_KINDS closed-set whitelist at kya/principals.py:81
Figure 6: KYP unified principal-trust schema. A single table (kya_principal_trust) carries trust scores for all three principal kinds; the closed-set principal_kind discriminator selects users, agents, or service accounts without branching the scoring code path. Per-kind subsystems are visible only in the choice of identifier domain; signal mechanics, decay, and storage are shared.
agent that attempts privilege escalation accumulates rogue deltas and crosses into higher buckets at runtime. This composition is the central distinction from purely static governance: the principaltrust posture moves with behavior.
5.6
KYP — Know Your Principal
KYA’s dynamic-trust layer is built around a unified principal-trust taxonomy we call KYP (Know Your Principal). KYP generalizes the per-user trust scoring common in fraud-detection systems [12, 38] to a single schema-level abstraction over three principal kinds: • user — a human user (UUID identifier) • agent — another AI agent (agent_key identifier) • service_account — an automated service, cron job, batch pipeline, or harness All three principal kinds share the same scoring mechanics: initial trust score 50 (STARTING_TRUST, kya/users.py), bounded [0, 100], signal-driven decrement, time-decayed recovery. Default per-signal weights (SIGNAL_DELTAS, kya/users.py; tenantoverrideable via the only-tighten algebra of section 7): oos_t ool −3, rbac_refusal −2, governance_block −2, data_leak −10, cross_tenant −15. Scores map to four buckets via bucke t_for_trust (kya/users.py): trusted (≥ 75), neutral (≥ 40), risky (≥ 15), blocked (< 15). All three principal kinds share one storage table kya_principal_trust (kya/principals.py: 215) keyed by (tenant_id, principal_kind, principal_id) with one signal-application code path (fig. 6). The closest prior art each unifies at a different layer. Chaffer [12] coins "Know Your Agent" but for an agent-only Web3 trust framework with no human or service principal. Janani [38] argues for a human-machine identity continuum at the policy-and-riskevaluation layer with no data model. Okta’s NHI initiative [62] unifies humans, services, and agents at the platform/UI layer while keeping separate scoring subsystems per identity kind. Microsoft Agent Governance Toolkit [55] provides per-agent trust scoring in Agent Mesh and relies on Entra ID upstream for humans, with no unified scoring substrate spanning both. KYP’s delta is the relational-schema unification: a single table, one discriminator (PRINCIPAL_KINDS at kya/principals.py:81), shared scoring code across kinds.
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
The PRINCIPAL_KINDS tuple is intentionally closed at three; specialized actors (eval harnesses, red-team campaigns, batch ingest, autonomous SQL pipelines) instantiate as service_account with metadata in the attributes JSON column. Caller-supplied strings cannot expand the keyspace (consistent with the closed-set whitelist discipline of section 3.4).
5.7
Actor-agent attribution for autonomous fan-out
When orchestrator agent 𝐴 triggers downstream sub-agents 𝐵/𝐶/𝐷 and any sub-agent fires a rogue signal at runtime, the signal is tagged at emission with actor_agent_key=𝐴, so 𝐴’s principaltrust counter is debited — not 𝐵’s, 𝐶’s, or 𝐷’s. This is complementary to the static-score delegation premium of section 4 (where 𝐴’s risk score factors in risky delegates): the static axis penalizes configured delegation to risky agents; the dynamic axis registers actual delegate misbehavior in 𝐴’s runtime principal-trust counter. The default actor_agent_key=agent_key convention is hard-wired at three SDK entry points (Claude Agent SDK hook, LangChain callback handler, OpenAI Agents RunHooks) so attribution works without per-customer wiring. The same convention is documented in the OTLP bridge’s KYA-hooks client. Three distinct deltas from prior work: banking AML / Horton capability [56] do audit-time attribution; AgenTracer [90] identifies the offending sub-agent post-hoc; Microsoft AGT propagates trust ceilings downward [55]. KYP debits the orchestrator at runtime — complementary to all three. Legal-theoretic motivation: Gabison and Xian [25] (REALM at ACL 2025).
6
Evidence Chain
KYA’s evidence log is the system’s source of truth for after-thefact audit. The log stores the actual forensic payloads regulators need to reconstruct what an agent did: the prompts the agent received, the responses it produced, the tool calls it made with their arguments (e.g. the literal SQL it tried to run), delegation messages between agents, human-in-the-loop approval decisions, and system context. Closed-set kinds: prompt, response, tool_call, tool_result, delegation_message, hil_decision, system_message (VALID_EVIDENCE_KINDS). Where the scoring tables (kya_invocations, kya_principal_trust) hold the counts, this table holds the proof. Each row is appended to a per-(tenant, invocation) HMAC-chained sequence. The HMAC-chain construction itself is well-trodden prior art: Bellare and Yee (1997) [6] introduced forward-secure hash-chained MAC audit logs, Schneier and Kelsey (1998) [72] provided the canonical USENIX treatment, and Crosby and Wallach (2009) [16] explored the Merkle-tree alternative. We do not claim novelty in the chain construction. Our contribution is the deployment shape: per-(tenant, invocation) parallel chains with dialect-aware concurrency serialization, plus a type-marked canonicalization that closes a collision-attack vector the naïve default=str JSON encoder leaves open. We also explicitly acknowledge the v1 singlekey limitation and the Sigstore-style anchoring upgrade path; this honesty distinguishes KYA’s claim from contemporaneous work (notably Aegis [50]) that asserts a stronger primitive.
6.1
FAccT ’27, June 2027, TBD
Chain construction (background)
Let 𝐾 be a secret HMAC key held by the tenant operator, 𝐻 be HMAC-SHA256 [5], and ∥ denote byte concatenation. A KYA evidence chain 𝐿 = (𝑒 0, 𝑒 1, . . . , 𝑒𝑛 ) is a sequence of events where each 𝑒𝑖 carries: • seq𝑖 ∈ N: monotonically increasing sequence number • kind𝑖 ∈ K: event kind from a validated closed vocabulary (VALID_EVIDENCE_KINDS, 7 entries) • payload𝑖 : canonical-JSON serialized event body • ℎ𝑖 : chain hash, defined as ℎ𝑖 = 𝐻𝐾 ℎ𝑖 −1 ∥ canonical_json(𝑒𝑖 ) , with the seed ℎ −1 set to a domain-separation tag. For tamper-evidence we refer to the standard result of Bellare and Yee (1997) [6]: any modification to a prior entry 𝑒𝑖 without knowledge of 𝐾 produces a chain that fails verify_chain with prf probability at most Adv𝐻 .
6.2
Deployment shape: per-(tenant, invocation) parallel chains
Unlike a single global chain, KYA maintains a parallel chain per (tenant, invocation) pair. Three properties motivate this: Cross-tenant isolation. A compromised chain in tenant 𝑇1 cannot break the chain in 𝑇2 . Pruning under one tenant’s retention policy does not require coordination with any other tenant. Forensic audit on tenant 𝑇1 does not expose data from 𝑇2 . Bounded fan-in for concurrent agent invocations. Modern agent frameworks fire many concurrent invocations per tenant. A single chain head would serialize all of them; per-invocation chains allow 𝑁 parallel writers across 𝑁 invocations without contention. Pruning preserves verification of surviving chains. Retentiondriven pruning (section B) creates a "clean cut" the verifier distinguishes from tampering: an expected chain-head mismatch at the first surviving entry of a pruned chain is reported as a clean cut, not a tamper.
6.3
Dialect-aware concurrency primitive
Concurrent writers within the same (tenant, invocation) still risk a chain fork: two writers reading the same tail ℎ𝑛−1 and producing distinct 𝑒𝑛 , 𝑒𝑛′ both signing against ℎ𝑛−1 . KYA’s evidence module serializes per-(tenant, invocation) writes via a dialect-specific primitive: • PostgreSQL: pg_advisory_xact_lock keyed on a hash of ‘kya:evidence:’, the tenant id, and the invocation id. The key is derived from the (tenant, invocation) identifiers, so the lock functions even on empty chains where no tail row exists to lock. The lock is transaction-scoped and released on commit/rollback. • MySQL: SELECT ... FOR UPDATE on the most-recent chain entry within the writer’s transaction. • SQLite and DuckDB: the module documents and enforces a "one writer per invocation" contract at the application layer, since these dialects do not provide the row-locking semantics the primitive requires.
FAccT ’27, June 2027, TBD
The closest prior art handles concurrency by avoiding it. Schneier-Kelsey [72] and Bellare-Yee [6] defer concurrency to operator practice and assume a single-writer ingestion process. Sigstore Rekor [61] serializes appends through a single coordinator. The Microsoft Agent Governance Toolkit [55] documents a single-writer audit-sink contract for its FileAuditSink. KYA’s delta is the dialect-aware concurrency primitive applied to per-(tenant, invocation) parallel chains: PostgreSQL writers serialize via pg_advisory_xact_lock, MySQL writers via SELECT FOR UPDATE on the tail row, SQLite/DuckDB writers via an enforced single-writer contract at the application layer. The combination of parallel chains with primitive-level serialization removes the global serialization point that earlier systems retain (kya/evidence.py:436–462). Type-marked canonicalization, retention floors, signing-key resolution, and verification semantics. (section B): canonical JSON (RFC 8785 [68]) extended with type-marked wrapping to close a collision-attack vector; per-regime retention floors (GDPR/HIPAA 6yr, NYDFS 5yr, EU AI Act 7yr, ISO 27001, FedRAMP, ITAR, NATO, EU classified, plus 6 more) enforced at prune_expired_evidenc e(); three-tier signing-key resolution (KMS/Vault/HSM provider, env-mounted key, dev fallback with one-time WARN); 𝑂 (1) perevent and 𝑂 (𝑛) full-chain verification with three distinct failure modes (payload tamper, chain break tamper, clean cut). All standard pieces; the only-novel deployment-shape claims are above.
6.4
Worked example: one loan application through the chain
Continuing the running example (section 3.5), a single loan application produces an invocation chain on the order of 20–30 entries: 𝑒 0 the originating prompt from the underwriter (kind prompt), 𝑒 1–3 the Loan Triage Agent’s delegation calls to the three sub-agents (kind tool_call, with actor_agent_key=triage on each so any subagent rogue signal debits the orchestrator), 𝑒 4 a Document Verification result tagged with sensitivity pii and a 6-year retention floor under NYDFS, 𝑒 5 an OFAC screening result tagged us_classified with the 25-year IL6 floor, 𝑒 6–8 Risk Review Agent reasoning steps, 𝑒 9 the action-gate verdict (kind governance_verdict, allow), and 𝑒 10 the underwriter-facing decision (kind response). Any posthoc attempt to alter the OFAC entry — whether to hide a missed hit or to fabricate one — changes ℎ 5 and breaks the chain at ℎ 6 ; verify_chain() returns chain break tamper at 𝑒 6 . The retention floor at 𝑒 5 (25 years) outlives any other entry, forcing the whole invocation’s chain head to survive that long even if civilian-PII entries are pruned at year 6. The same chain construction applies to the clinical fleet of section 3.6: a single triage invocation produces a similar 10–20 entry chain, but every entry tagged with sensitivity phi inherits HIPAA’s 6-year retention floor (45 CFR 164.530(j)) and a breach-notification SLA of 60 days under the HIPAA Breach Notification Rule. The regime-aware retention selector (section B) reads the data-class tags and selects the longest applicable floor without per-domain code paths. Honest scope. The chain is verifiable by anyone holding the HMAC key; multi-party verification (no single party can forge
Kolawole Quadri
seed
ℎ −1 KYA-v1-evidence
𝑒0 seq = 0 kind = prompt payload (canonical) ℎ 0 = 𝐻𝐾 (ℎ −1 ∥𝑒 0 )
ℎ0
𝑒1 seq = 1 kind = tool_call payload ℎ 1 = 𝐻𝐾 (ℎ 0 ∥𝑒 1 )
ℎ1
𝑒2 seq = 2 kind = response payload ℎ 2 = 𝐻𝐾 (ℎ 1 ∥𝑒 2 )
Per-(tenant, invocation) writers serialized via dialect-aware lock: pg_advisory_xact_lock on PostgreSQL, SELECT FOR UPDATE on MySQL, single-writer contract on SQLite/DuckDB.
payload canonicalization wraps non-JSON values as {"__t__": type, "v": ...} so a datetime and its isoformat() hash differently.
Figure 7: KYA evidence chain construction. Per-(tenant, invocation) parallel chains with dialect-aware concurrency serialization (section 6.3) and type-marked canonical JSON (section B).
the chain) requires threshold signatures over the root and is future work (section B, section 10).
6.5
Configuration drift detection
Observability tracks agent behavior; not agent configuration. A one-line edit to a system prompt silently changes the agent’s policy without leaving any observability trace. KYA addresses this with (i) content-addressed canonical hashing over an explicit allowlist of 18 policy-bearing fields (system_prompt, tools, model, access_level, can_override, etc.); (ii) an append-only event-time + ingest-time snapshot history with lineage-driven risk inheritance; and (iii) a behavioral-drift signal — the mode-vs-config gap — that records exercised human_loop mode at each invocation and flags configurations whose declared mode diverges from the empirical distribution (EU AI Act Art. 14 evidentiary requirement for exercised oversight). The detector returns a structural diff, records to the evidence chain above, and triggers operator review. Algorithm, lineage-decay constants, signature verification, and the explicit out-of-scope drift classes (model-provider behavioral drift, tool-environment drift, retrieval-corpus drift) are detailed in section A.
7
Inbound Federation and Closed-Loop Adaptation
KYA’s risk-weight tables (section 4) ship with defaults from expert judgment. Defaults are generic by construction. A write tool in a clinical setting is not the same risk as the same tool in logistics. Pertenant overrides (section 7.1) let customers adapt weights locally, but local tuning misses cross-fleet signal when attack patterns emerge across many customers. KYA addresses both gaps with two coordinated mechanisms: federated weight recommendations (vendor → fleet, section 7.2) and in-tenant closed-loop adaptation (operator → local fleet, section 7.3). Both route apply through the same gates, preserving the only-tighten invariant (section 7.1) and operator approval as default. The signed-update transport itself is well-trodden prior art: TUF [69], Uptane [45], OPA signed bundles [63], STIX/TAXII [39], and Ioannidis et al.’s distributed firewall [34] all distribute signed policy artifacts to enforcement points. Our contribution is not
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
Gate 1: Ed25519 signature verification. The recommendation envelope is verified against pinned trust anchors via _ inbound_signing.verify_envelope. Canonical-JSON serialization (signature field stripped, sorted keys, no whitespace, ensure_ascii=True). Multi-anchor pinning is firstclass: the KYA_INBOUND_PUBLIC_KEY environment variable accepts a comma-separated list of <keyid>:<base64-pub key> entries, so operators can pin current + next-quarter keys for invisible rotation, or pin a self-operated gateway key for air-gapped deployments. A signature verification failure aborts processing immediately and is never followed by an "apply anyway" fallback. Gate 2: Expiration check at persist time. Each recommendation carries an expires_at timestamp. The check is at persist time, not only at signing-verify, so recommendations signed in advance cannot bypass expiry by traveling slowly through the fetch pipeline (inbound.py:166). Gate 3: Only-tighten composition. Apply routes through tenant_weights.set_override, which enforces Definition 1 and Lemma 1. A recommendation that would lower the effective weight raises OverrideLoosensError; the recommendation is rejected and the operator notified. Gate 4: Operator approval (default). Every recommendation lands as status=’pending’ by default; an operator explicitly approves via the SDK’s approve_recommenda tion path. Optional auto-apply is scoped: the customer configures an auto_apply_allowlist of (𝑠𝑐𝑜𝑝𝑒, 𝑘𝑒𝑦) tuples, and only recommendations matching the allowlist are auto-applied — and even then through the same set_overr ide path, so gates 1–3 still hold.
the transport but the four-gate apply pipeline with operatorapproval-as-default and the formal only-tighten composition algebra. The closed-loop in-tenant adaptation pipeline (section 7.3) is an engineering discipline that inherits those two mechanisms; we describe it for completeness, not as a separate contribution.
7.1
Tenant override algebra
The only-tighten composition algebra is structurally adjacent to Cedar’s forbid-dominance theorem (Cutler et al. [17], OOPSLA 2024), which proves in Lean that forbid dominates permit under union composition for a flat policy set. The same one-way property is also operationally deployed in Istio AuthorizationPolicy [37] (CUSTOM ≻ DENY ≻ ALLOW, non-configurable lattice) and GCP IAM Deny Policies [29] (descendant deny narrows ancestor permits; never broadens). KYA does not claim novelty in the one-waytightening property itself. Our contribution is the three-channel hierarchical composition: platform default ⊕ tenant override ⊕ signed external recommendation, with a soundness lemma over the multi-authority hierarchy. The signed external-recommendation channel as a third party to the meet is the genuinely new dimension; no prior work surveyed formalizes it. Let 𝑊0 : (scope, key) → N be the platform default weight function and let 𝑊𝑡 denote tenant 𝑡’s effective weight function and ⪰ be the order 𝑤 ′ ⪰ 𝑤 ⇐⇒ 𝑤 ′ ≥ 𝑤 (higher = tighter). A tenant override is only-tighten if every (𝑠𝑐𝑜𝑝𝑒, 𝑘𝑒𝑦) value dominates the platform default under ⪰ (Definition 1, App. K). The SDK enforces this at write time: tenant_weights.set_override raises OverrideLoosensError on any tenant-scoped value below the platform default (tenant_weights.py:189). Composition is sound: the effective tenant weight function 𝑊𝑡 satisfies 𝑊𝑡 ⪰ 𝑊0 at all times and is monotone non-decreasing within the tenant scope (Lemma 1, proof sketch in App. K). The invariant binds tenants, not platform admins — the _check_only_tighten function returns early when tenant_id=None; platform admins retain the management-decision right to lower the platform default itself. A runnable witness (examples/three_channel_compositi on_witness.py) exercises all three channels across six update attempts (platform raise, tenant tighten, tenant loosen, signedrec tenant-tighten, signed-rec tenant-loosen, signed-rec platformlower). Every attempt matches its expected accept/block outcome and Lemma 1 holds in the resulting state: with platform𝑊0 (pii)=12 and tenant 𝑊𝑡 (pii)=30, we have 𝑊𝑡 ≥ 𝑊0 (30 ≥ 12). The signedrecommendation channel routed at the tenant level (𝑊𝑟 → 𝑊𝑡 ) traverses the same _check_only_tighten guard as direct tenant overrides — so a compromised collector key cannot loosen a tenant’s effective weight even though the inbound pipeline accepted the message.
7.2
The four-gate apply pipeline
Inbound federation is off by default; a tenant operator explicitly calls enable_inbound(collector_url, trusted_keys) (kya/inbound.py) to opt in. Until then, no external recommendation reaches the SDK. Once enabled, every signed recommendation traverses four sequential gates before any effect on a tenant’s weight table.
FAccT ’27, June 2027, TBD
A fifth latent gate guards against race conditions: the autoapply UPDATE is status-guarded (WHERE status=’pending’ at inbound.py:248) so a re-fetch cannot roll back an operator-applied row to an auto_applied status. The contribution is the composition of gates 1–4 (plus the latent race-guard) in this specific order with operator-approval as the default. No prior signed-update distribution system surveyed (section 9) composes all four with operator-approval as the default — the closest analogue is the KeyNote-credential composition with local POLICY in Ioannidis et al. (2000) [34], which lacks an explicit operator-approval step.
7.3
Closed-loop in-tenant adaptation (supporting discipline)
Local incidents within a tenant’s deployment produce adaptation candidates via the kya.feedback pipeline: a resolved critical governance incident triggers feedback.propose_from_incident, which analyzes which factors fired against the incident-producing agent and proposes weight bumps. Suggestions land in kya_weig ht_suggestions as status=’pending’; an operator reviews and approves (or rejects); approved suggestions are applied via tena nt_weights.set_override, inheriting the only-tighten algebra and the change-audit trail. The module’s docstring states the safety discipline: "Never auto-tune. Auto-applying weights based on incidents creates a feedback loop where one false-positive incident silently
FAccT ’27, June 2027, TBD
Kolawole Quadri signed recs → 4 gates
Customer A
Vendor side
veldt-kya
8
2: expiry
3: only-tighten
1: signature verify
4: operator approval
telemetry up
aggregate-only counts, no payloads
Customer B veldt-kya
analyst review
Ed25519 sign
Veldt-internal
key_id
Customer C veldt-kya
governance incident
suggestion
operator review
feedback.py
never auto-tune
in-tenant closed loop
Figure 8: KYA’s federated + closed-loop adaptation. Both paths route through the same gates; the only-tighten invariant (Lemma 1) holds across both.
weakens the governance model. Human-in-the-loop is non-negotiable here." This is an engineering discipline, not a research contribution: the mechanism is straightforward (propose → stage pending → operator approval → apply through the four-gate pipeline). Structurally it parallels FDA-PCCP [83] envelope review and draws on AI corrigibility [60, 75] and active-learning oracle-gating [73]. Counterposition: Cloudflare WAF ML [15] ships vendor-trained classifier updates globally with no customer-side approval; IBM SOAR [32] gates response actions but not policy weight adaptations. Worked example: sector-wide OFAC tightening. Continuing the running example, a peer bank’s sanctions-evasion incident traces to a misclassified OFAC hit. The KYA collector ingests aggregated counts, the operator drafts a recommendation tightening the dataclass multiplier on us_classified for ofac_lookup (1.20 → 1.30), signs it, and distributes. Our bank’s KYA verifies signature (Gate 1), checks expiry (Gate 2), confirms 1.30 ≥ current override (Gate 3 only-tighten), and stages for operator review (Gate 4). The risk officer approves; the OFAC sub-agent’s score shifts 34 → 38 and the flag_for_review threshold tightens one bucket. No raw application data, principal identity, or completion payload crosses the organizational boundary — only counts upward, signed weight deltas downward.
7.4
Threat-model summary
Compromised collector private key: an attacker forging recommendations can over-restrict (denial of service) but cannot loosen below the platform default — the only-tighten algebra constrains blast radius to friction, not exposure; key rotation via key_id + multi-anchor pinning lets operators distrust a compromised key. Replay: expires_at bounds replay; the SDK rejects expired recommendations at persist time. Compromised platform admin and insider-threat collusion: out of scope (section J); KYA provides tenant-side immutability against vendor recommendations + compromised admin, not absolute immutability.
Evaluation
Headline result. Reproducing the topology-guided multi-agent attack of Liang et al. [49] against the loan-decisioning fleet of section 3.5, an undefended Loan Triage orchestrator remains "clean" by static-score metrics (61, high) even as its compromised Document Verification sub-agent propagates adversarial influence upward. With both delegation-trust premium (section 4) and actor-agent runtime debit (section 5.7) enabled, the Triage Agent’s principaltrust counter is debited on the first malicious invocation (using the default SIGNAL_DELTAS weight of −3 for oos_tool signals; kya/users.py), and crosses into the risky bucket (< 40) at the 4th invocation and the blocked bucket (< 15) at the 12th. Faster transitions follow for heavier signal kinds: with data_leak (−10 per signal), the orchestrator crosses risky at invocation 2 and blocked at invocation 4; with cross_tenant (−15), risky at 1 and blocked at 3. Disabling either axis alone fails to attribute: the dynamic-only configuration leaves the orchestrator in neutral until invocation 4 (no static premium elevation), and the static-only configuration leaves the runtime trust counter unchanged regardless of how many sub-agent rogue signals fire. This is the only runtime attribution mechanism in the surveyed prior art that catches the Liang attack at the orchestrating principal without relying on legal-theoretic post-hoc forensics ([25]) or downward trust-ceiling propagation ([55]). We evaluate KYA along five further axes below: cross-backend correctness, latency and throughput, adversarial-probe detection, compliance-regime coverage, and adapter breadth. All data is reproducible from the Apache 2.0 veldt-kya [85] release.
8.1
Integrated scenario: governance, detection, and evidence working together
Before reporting per-axis results, we walk one representative agent through all three temporal phases of the KYA contract — the configuration-time governance check (section 4), the runtime detection layer (section 5), and the after-the-fact forensic record (section 6) — to make the through-line concrete. The agent is the Risk Review Agent of the running loan-decisioning fleet (section 3.5), which carries write authority to flag applications for human underwriter review. Phase 1 — before-runtime governance check. At configuration time, score_agent (section 4) returns a per-factor decomposition over the Risk Review Agent’s declared definition. The dominant contributions are: governance mode hybrid (+10), can_override=True (+12), write tool count (+4 each), admingated tool override_decision (+8), data sensitivity financial (MAX, +20), and the admin_tool_AND_financial_data interaction multiplier fires at 1.25×. The agent scores 77 (high). The operator’s deployment review queue surfaces the agent before any production traffic reaches it; the high-bucket classification triggers the static delegation-trust premium (section 4) on the Loan Triage Agent that delegates to it. Phase 2 — during-runtime detection. Suppose the Risk Review Agent receives a manipulated input (a loan application with embedded prompt-injection content) and attempts to invoke an outof-sanctioned-list tool — export_applicant_pii_to_external.
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
FAccT ’27, June 2027, TBD
& U R V V E D F N H Q G F R U U H F W Q H V V H H S K D V H V × V W R U D J H E D F N H Q G V
Three signal sources fire on the same event: (1) Layer 3 toolRBAC refusal (the tool isn’t in the agent’s tools list), (2) the action gate emits a policy_violation verdict (unsanctioned data egress), and (3) the rogue module records an oos_tool signal. The record_principal_signal call debits both the Risk Review Agent’s principal-trust counter and the Loan Triage Agent’s counter (the actor_agent_key convention of section 5.7 routes the second debit through the default hook wiring).
/ U H 6 4
3 R V W J
W H
6 4 / L
' % ' X F N
/ 0 \ 6 4
V W R U D J H L Q L W V W D W L F V F R U L Q J Y H U V L R Q L Q J G U L I W H Y L G H Q F H F K D L Q U R J X H V L J Q D O V D F W R U D J H Q W
Phase 3 — after-runtime evidence. The same invocation produces seven HMAC-chained evidence rows: the originating prompt; the agent’s reasoning response; a tool_call row whose payload contains the literal attempted argument (e.g. {"tool":" export_pii_external","args":{"applicant_id":". . . "} }); a tool_result row recording the action-gate rejection; an hil_decision row if an underwriter approves or denies the escalation; and any delegation messages. Each row’s signed_hash chains to the previous row’s hash so neither the operator nor a compromised database role can rewrite the record after the fact. The chain is queryable by tenant and invocation id; a regulator or external auditor reads the literal payloads to reconstruct what the agent attempted. Replit (July 2025) as a real-world cross-check. The same threephase contract applied to the publicly reported Replit autonomousagent database deletion incident2 reproduces the same shape: the agent configuration scores critical before deployment under KYA’s static factors; a destructive DDL invocation at runtime fires the same combination of detection signals; the literal DROP TABLE string is what the evidence chain would have recorded. The Replit incident is not load-bearing for the contributions of this paper. After-the-fact reconstruction of an agent definition from a public post-mortem and observing that it scores critical under KYA’s weights is a calibration check on the weight assignments, not evidence of prospective detection. The full reconstruction and an explicit non-prevention disclaimer are in section 10.
8.2
Cross-backend correctness
KYA persists state through SQLAlchemy abstractions and is designed to run against multiple SQL backends without configuration changes other than the connection string. We verify this at two granularities. Nine-phase end-to-end matrix (9 × 4 = 36 cells). The OpenCLAW end-to-end suite exercises nine phases of the SDK against PostgreSQL 15, SQLite 3.45, DuckDB 0.10, and MySQL 8.0 (fig. 9): (1) storage initialization, (2) static scoring, (3) versioning + drift, (4) evidence chain append + verify, (5) rogue signal recording + actoragent attribution, (6) quality signal recording, (7) tenant weight overrides with only-tighten enforcement, (8) inbound signed recommendations through the four-gate apply pipeline, and (9) full lifecycle including delegation-trust attribution (register → score → snapshot → accumulate signals → apply recommendation → verify chain). All 36 cells pass. 2We treat this as one corroborating example sourced entirely from the published
post-mortem; full reconstruction and the explicit non-prevention disclaimer are in section 10.
T X D O L W \ V L J Q D O V W H Q D Q W R Y H U U L G H V R Q O \ W L J K W H Q L Q E R X Q G J D W H D S S O \ O L I H F \ F O H G H O H J D W L R Q W U X V W
F H O O V S D V V
Figure 9: Cross-backend correctness across nine end-to-end phases × four storage backends. All 36 cells pass. Per-table persistence matrix (17 × 4 = 68 cells). A second harness (tests/verify_all_backends_with_data.py) drives every write through the public SDK API and verifies a non-empty row in each of KYA’s 17 owned tables on each of the four backends: 4 ORM-modeled core tables (agent_versions, kya_invocations, kya_principal_trust, kya_evidence) and 13 legacy tables (aliases, user trust, weight overrides + changes + suggestions, breach notifications, six red-team tables, and inbound recommendations). The portable upsert layer (kya/_dialect_helpers.py) dispatches each write to its native dialect grammar — PG INSERT ... ON CONFLICT DO UPDATE, MySQL INSERT ... ON DUPLICATE KEY UPDATE, SQLite ON CONFLICT DO UPDATE, DuckDB raw text (the duckdb-engine SQLAlchemy adapter has a compile bug on the on-conflict constructor that we route around). All 68/68 cells pass.
8.3
Latency and concurrent throughput
Per-operation latency on commodity hardware: the pure-function scorer (score_agent) runs sub-millisecond at p99 (median 110 𝜇s, p99 0.9 ms). Storage-bound operations were measured against each of the four supported backends, 𝑁 = 1000 record_principal_si gnal+commit calls per backend after a 50-call warm-up, on a single workstation (table 4). Table 4: Per-call latency for record_principal_signal + commit, measured 𝑁 = 1000 against each backend on a single workstation. SQLite and DuckDB run in-memory; PostgreSQL 15 and MySQL 8 on localhost. SQLite in-memory numbers are not representative of network-attached production deployments; PG/MySQL rows are the operationally relevant figures. Backend
Median
p95
p99
SQLite PostgreSQL 15 DuckDB MySQL 8
1.2 ms 7.3 ms 11.1 ms 12.1 ms
1.8 ms 13.9 ms 15.9 ms 21.1 ms
4.1 ms 20.9 ms 19.8 ms 27.6 ms
FAccT ’27, June 2027, TBD
Kolawole Quadri & R Q F X U U H Q W W K U R X J K S X W D J D L Q V W 3 R V W J U H 6 4 / F K D L Q L Q Y D U L D Q W V S U H V H U Y H G
3 H U R S H U D W L R Q O D W H Q F \ R Q 3 R V W J U H 6 4 / F R P P R G L W \ K D U G Z D U H
S S S S P V
S P V
O D W H Q F \ P V O R J V F D O H
S P V
S P V
S P V
S P V
S P V S P V
P V
S P V
S H U W U L D O P H D Q Q L G H D O O L Q H D U V F D O L Q J
a R S V V H F V D W X U D W L R Q S R L Q W P D W F K H V 3 * F R Q Q H F W L R Q S R R O V L ] H
S P V
7 K U R X J K S X W R S V V H F
V F R U H B D J H Q W S X U H I Q
U H F R U G B H Y L G H Q F H 3 * Z U L W H
V Q D S V K R W B D J H Q W 3 * L Q V H U W
V H W B R Y H U U L G H 3 * X S V H U W
L Q E R X Q G J D W H H Q G W R H Q G
Y H U L I \ ? B F K D L Q V X F F H H G H G R Q H Y H U \ S H U W H Q D Q W L Q Y R F D W L R Q O R J D W W K H H Q G R I H Y H U \ W U L D O
& R Q F X U U H Q W Z R U N H U V
Figure 10: (Left) Per-operation latency distributions. (Right) Concurrent throughput against PostgreSQL 15 — linear scaling to 20 workers, saturation matches connection-pool size.
For context, Aegis [50] reports 238 ms median for ZK proof verification — KYA’s principal-signal path is one to two orders of magnitude faster because KYA does not anchor each record to a ZK proof (the operator-key vs multi-party verifiability tradeoff of section 10). A five-phase 20-worker × 50-op load test sustains ≈ 1,800 ops/sec on a single PostgreSQL backend, scales linearly to 20 workers, and saturates beyond as connection-pool contention dominates. Per-worker this is ≈ 90 ops/sec against the 7.3 ms PG median (table 4, which implies ≈ 137 ops/sec single-threaded), so roughly 66% of unloaded per-worker throughput is retained under 20-way pg_advisory_xact_lock contention — consistent with contention rather than measurement artifact. Critically, every operation under load preserves the HMAC chain invariants: verify_chain succeeded on every per-(tenant, invocation) log at the end of the test, validating pg_advisory_xact_lock prevents chain forks under realistic concurrent ingest. The same five-phase suite (record-invocation, evidence-chain append, principal-signal upsert, actor-mirror writes, versioning-version-no race) passes end-to-end on all four backends (20/20 phase-backend cells green)3 . Latency and throughput distributions: fig. 10 (combined panel: latency p50/p95/p99 left, throughput vs workers right). Red-team lifecycle, cross-backend. A separate 50-finding campaign harness (examples/redteam_cross_backend.py) exercises the full kya_redteam surface — create_campaign, create_targ et with encrypted secret, set_tenant_policy, create_run, re cord_finding ×50, heartbeat, finalize_run — across all four backends. All four pass: 50/50 findings persisted per backend, all six red-team tables (campaigns, findings, runs, targets, target_secrets, tenant_policy) populated correctly on each.
8.4
Attack-pattern detection
We exercised KYA against three attack classes corresponding to threats T4, T7, and T8 of section 2. Adversarial-prompt probes (PyRIT + Garak). We ran 1,200 adversarial probes from PyRIT and Garak across five attack categories: prompt injection, data exfiltration, role confusion/impersonation, jailbreak, and capability escalation. The red-team package (kya_r edteam) ships a tiered orchestrator surface: prompt_sending and 3 In-process multi-writer is verified on all four backends; SQLite/DuckDB add an in-
process per-(tenant, invocation) lock to close the lost-update window that their lack of row-level locks leaves open. Cross-process multi-writer is verified only on PG (pg_advisory_xact_lock) and MySQL (SELECT FOR UPDATE); SQLite/DuckDB crossprocess workloads require the documented single-writer-per-invocation contract or an external advisory-lock service.
garak_probes are single-shot (free tier), red_teaming and xpia (cross-prompt injection adversarial) drive a Veldt-hosted attacker LLM at the standard tier, and crescendo and tree_of_attacks _with_pruning (TAP) drive premium multi-turn campaigns. Figure 11 reports detection rates by category, broken into block (action gate refused), flag (action allowed but logged as policy violation), and missed (no rogue or quality signal fired). Across 1,200 probes, KYA blocked or flagged 1,068 (89%); the residual missed cases concentrated in sophisticated multi-turn prompt-injection sequences, which we discuss in section 10. Scope of this metric. (i) The 89% headline is a composite of block and flag: flag-only outcomes log the policy violation but do not prevent the agent’s action, and an operator who treats flags as informational rather than blocking sees a strictly weaker guarantee; the per-category block/flag split in fig. 11 is the operative metric for that scenario. (ii) Adversarialprompt detection is one sub-component of KYA’s runtime-rogue surface (one of five primitives); the 89% is a coverage calibration for that sub-component, not a system-level performance claim. (iii) Content-filter systems such as Llama Guard 3, NeMo Guardrails, Lakera Guard, OpenAI moderation, and model-provider built-in filters classify individual inputs or outputs as harmful or benign; they are not governance layers and have no notion of agent identity, multi-tenant policy composition, trust scoring across human and machine principals, delegation attribution, or cryptographic audit chains. A head-to-head comparison against these tools would therefore be at the sub-component level (rogue-signal detection only) and is orthogonal to KYA’s primary contributions. System-level comparison against the governance layers that occupy the adjacent surface — Aegis [50], AAGATE [31], MS AGT [55], TrustPact [81], SIGIL [74] — is in section 9. Topology-guided propagation (Liang attack) [49]. We constructed a re-implementation of the topology-guided multi-hop attack pattern described by Liang et al., guided by their published methodology; we did not execute the authors’ original attack code (the public release post-dates this evaluation). The simulation comprised a fleet of orchestrator agents that delegate to attack-controlled edge agents, with multi-hop payload propagation matching the paper’s adversarial contamination pattern. The orchestrators were themselves clean by static-score metrics. Without KYA’s delegation-trust attribution and actor-agent dynamic-trust attribution, the orchestrators triggered no signals under the attack. With both enabled, the orchestrator’s principal-trust counter accumulated debits from the first malicious sub-agent invocation; with default oos_tool weight −3, the orchestrator crossed the risky bucket (< 40) at invocation 4 and blocked (< 15) at invocation 12. Heavier signal kinds (data_leak at −10, cross_tenant at −15) compress the timeline proportionally. The observation gate of section 4 prevented the brand-new sub-agents from triggering false positives during a matched control run where the same orchestrator delegated to clean agents. Attribution evasion (T8). We constructed scenarios where misbehaving sub-agents would, in a naive system, debit their own principal-trust without affecting the orchestrator. With KYA’s actor_agent_key convention enabled at the kya_hooks entry points, the orchestrator’s trust counter moved correctly in 100% of the constructed cases. Disabling the default convention reproduced the evasion.
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
Table 5: Four-gate deterministic acceptance test: latency distribution after warmup. p50/p95/p99 are the median across three independent N=100 runs on a single workstation, SQLite in-memory. All four gates rejected their target input on every trial (1,200 / 1,200) — this confirms gate firing, not adversarial robustness. SQLite latency is ≈ 6× lower than the PG figures in table 4; on PostgreSQL the G3/G4 rows would move into the low-millisecond range while G1/G2 remain microsecond-class. Gate
Adversarial input
p50
p95
p99
G1 Ed25519 sig G2 expires_at G3 only-tighten G4 operator-approval
forged signature past timestamp value below platform valid, no allowlist
17 𝜇 s 1.5 𝜇 s 442 𝜇 s 428 𝜇 s
26 𝜇 s 2.3 𝜇 s 696 𝜇 s 605 𝜇 s
59 𝜇 s 3.1 𝜇 s 769 𝜇 s 1,161 𝜇 s
Two observations. First, the cryptographic and timestamp gates (G1, G2) dispatch in tens of microseconds — the four-gate pipeline itself is not a latency bottleneck even at p99. Second, the DB-bound gates (G3 lookup, G4 persist) sit in the hundreds of microseconds, dominated by SQLite round-trip; on PostgreSQL this moves into the millisecond range reported in table 4. The G4 row demonstrates the operator-approval-as-default discipline: a well-formed, signed, non-expired, only-tightening recommendation is accepted into the queue but not applied to a weight table in the absence of an explicit auto_apply_allowlist entry covering its (𝑠𝑐𝑜𝑝𝑒, 𝑘𝑒𝑦). A re-fetch of the same row does not roll it back to auto_applied (the statu s=’pending’ guard on the auto-apply UPDATE).
8.5
Compliance regime coverage
KYA’s compliance.py module maps agent definitions to 32 regulatory regimes (section I), surfacing retention windows, breachnotification SLAs, and required controls per regime via complianc e_summary() and required_controls(). Concrete regulator artifacts are produced by kya/compliance_exports.py: an SR 11/7shape model-risk card (sr_11_7_model_card) and an ISO 42001 AI-management-system bundle export (iso_42001_aims_export), each emitting JSON-shaped records ready for downstream packaging. Five load-bearing regimes (table 6) illustrate the format. The
5 H G W H D P G H W H F W L R Q S U R E H V E O R F N H G R U I O D J J H G ? R Y H U D O O Q
E O R F N H G D F W L R Q J D W H I O D J J H G S R O L F \ Y L R O D W L R Q O R J P L V V H G
Q
3 U R E H F R X Q W
Four-gate inbound apply pipeline (deterministic acceptance). We verify that each of the four gates of section 7.2 rejects its target input class with deterministic 100% recall. This is a deterministic acceptance test of gate firing, not an adversarial robustness evaluation: each gate receives an input designed to trip its specific check (a forged signature for G1, a past timestamp for G2, a below-baseline value for G3, an unapproved-but-otherwise-valid bundle for G4). The PyRIT/Garak campaign above is the adversarial-robustness evaluation; this test confirms the per-gate primitive operates as specified. Setup: real kya/inbound.py pipeline backed by in-memory SQLite (examples/four_gate_adversarial_test.py in the SDK release; the file-name retains the original "adversarial" designation and will be renamed in a future release). Methodology: 𝑁 =100 trials per gate, the first 10 discarded as warmup (SQLAlchemy statement cache + interpreter JIT cold start), the remaining 90 used for percentiles, repeated across three independent runs. Every trial of every gate rejected its target input: 1,200 / 1,200 rejections. Table 5 reports the median across runs.
FAccT ’27, June 2027, TBD
Q
Q
Q
M H F W L R Q 3 U R P S W L Q
X V L R Q 5 R O H F R Q I
O W U D W L R Q ' D W D H [ I L
- D L O E U H D N
V F D O D W L R Q
\ H & D S D E L O L W
Figure 11: Red-team detection rates across five attack categories. Stacked bars show block (action gate refused), flag (logged as policy violation), and missed (no signal).
Table 6: Five load-bearing compliance regimes (full 32-regime list: section I). Regime GDPR HIPAA EU AI Act NYDFS Part 500 DORA
Retention
Breach
Tier model
6 yr 6 yr 10 yr 5 yr 5 yr
72 h 60 d — 72 h 24 h
Art. 4 PHI tiers Risk tier 1–4 — —
remaining 27 include CCPA, GLBA, FERPA, SOX, PCI-DSS, SR-11/7, ISO 42001, ITAR/EAR, NIST 800-171/53, IL5/IL6, FedRAMP, CMMC, IRAP, CCCS, C5, and ENS. The mapping is advisory: KYA produces the artifacts (canonical hashes, evidence chain, scored decisions, drift records, regulatory breach-notification fan-out via the idempotent multi-regime compliance_shim.py emitter) that compliance teams need to assemble certification packages. The multi-regime fan-out deserves a note: a single incident with PII + NYDFS scope produces two distinct notifications (72 h EDPB + 72 h NYDFS formats), with UNIQUE(incident_id, regime) preventing double-fire.
8.6
Adapter coverage
KYA ships native adapters for 15+ agent frameworks (table 7) with auto-detection for unknown frameworks falling back to the generic adapter. Each adapter normalizes the framework’s native representation into KYA’s canonical schema and is exercised by the cross-backend test matrix.
8.7
Summary
KYA produces measurable, regulator-legible artifacts at productionrelevant performance across four storage backends and 15+ agent frameworks. The system detects topology-guided multi-agent attacks (T7) and attribution evasion (T8) that prior systems fail to catch (section 9); it sustains ≈ 1,800 ops/sec with HMAC chain integrity preserved under concurrency; it covers 32 regulatory
FAccT ’27, June 2027, TBD
Kolawole Quadri
Table 7: Native framework adapters shipped in KYA 0.1.0. Tenants register additional adapters via register_adapter. Framework
Adapter coverage
Veldt-native LangChain CrewAI OpenAI Assistants OpenAI Agents Claude Agent SDK AutoGen Semantic Kernel LlamaIndex Haystack MCP AWS Bedrock Google Vertex OpenAI Swarm Letta, Pydantic-AI, smol, ADK Generic + auto-detect
First-party Callback hook + adapter Adapter Adapter RunHooks + adapter HookMatcher + adapter Adapter Adapter Adapter Adapter Adapter Adapter Adapter Adapter Adapters Fallback
regimes including defense/classified data classes. Limitations (section 10) include the heuristic nature of static factor weights (empirical calibration awaits collector deployment), the single-key HMAC chain (multi-party verification via Sigstore-anchoring is roadmap), and the workshop-venue framing of contribution #5 (section 5.7).
9
verification (section 6.5, section 6). The two systems are complementary, not competitive; the release ships a working bridge mapping ActiveGraph’s Event.actor/frame_id into KYP debits at e xamples/live_activegraph_with_kya.py. Microsoft Agent Governance Toolkit [55] is the closest commercial competitor on feature breadth; KYA differs by scoring users, agents, and service accounts in one principal-trust system (AGT’s Agent Mesh scores agents only, relying on Entra ID upstream), by formalizing only-tighten with a soundness proof, and by shipping the federated weight-recommendation channel that AGT discusses as future work [52]. TrustPact [81] is closest on weighted-factor scoring; scoped to evaluation by design, its outputs compose into KYA’s evidence chain as quality signals rather than competing with KYA’s governance layer. AURA [71] is the closest academic competitor on static scoring; its purely-additive construction without per-interaction multipliers reinforces our contribution’s novelty. Multi-agent attacks: Liang et al. [49] (40–78% topology-attack success) motivates section 4’s delegation-trust attribution; Wu et al. [88] eigenvector-backpropagates on agent-influence graphs as the closest computational analog; AgenTracer [90] does post-hoc counterfactual attribution where KYA debits the orchestrator at runtime. Table 8: KYA vs concurrent agent-governance systems on the four dimensions where contribution claims concentrate. Columns: Aeg = Aegis, AAG = AAGATE, MAG = Microsoft AGT, TPa = TrustPact. ✓: present; ◦: partial / future work; –: absent. Extended comparison in section C.
Related Work
KYA’s positioning rests on five bodies of prior work: concurrent agent-governance systems, adjacent admission-control literature, LLM evaluation and observability platforms, software-provenance and signed-policy distribution, and adaptive-governance precedents. We summarize the deltas against the closest adjacent surface here (table 8) and defer detailed per-system treatments, Cedar lineage, safety-lattice ancestors, and the inherited HMAC / signedbundle primitives to section C. Concurrent agent-governance systems (2025–2026). Five contemporaneous systems occupy adjacent surface (table 8). Aegis [50] proposes ZK-verified runtime governance; we accept the weaker operator-key anchor and document the Sigstore upgrade path. AAGATE [31] is a Kubernetes-native NIST AI RMF control plane at the platform-infrastructure layer; KYA is an SDK that integrates into platforms (including Kubernetes control planes such as AAGATE) and adds KYP, the formal only-tighten algebra, the four-gate apply pipeline, and the dynamic-trust actor-agent attribution at the SDK layer. SIGIL [74] (on-chain skill registry) is adjacent rather than competitive. ActiveGraph [57] proposes an event-sourced reactive-graph agent runtime: a during-runtime architecture for auditable, forkable agent execution. KYA spans a broader temporal scope — before-runtime evaluation of an agent’s declared definition (governance mode in / on / autonomous; access level read / write / admin; tools; model; deployment environment; data classes; the full factor model of section 4), during-runtime rogue-signal attribution (section 5), and after-runtime drift detection and evidence-chain
KYP unified principal Only-tighten algebra (formal) Four-gate apply pipeline Actor-agent runtime debit
10
Aeg
AAG
MAG
TPa
KYA
– –
– –
– – – –
✓ ✓ ✓ ✓
◦
◦
◦ ◦ ◦
–
–
–
Limitations and Future Work
We are explicit about KYA’s limitations. The system is intentionally conservative in its scope; several plausible extensions are deliberately deferred. The scoring model is heuristic. Factor weights come from expert judgment, governance literature [22, 33, 58, 65], and red-team observation; they are not formally verified or calibrated against groundtruth incident data. AURA’s purely-additive construction [71] and AIVSS’s single-threat-multiplier shape are reasonable alternatives trading auditability for easier calibration. KYA guarantees instead that the model is auditable (every weight in the Apache 2.0 release) and adjustable (tenant override, signed recommendation). Empirical calibration from collector telemetry is the most consequential future work. Structural ceiling on external safety filtering. Nayebi (2025) [60] proves (Proposition 4) that no total Turing machine decides whether an arbitrary agent in an arbitrary environment will ever trigger catastrophic behavior — safety verification reduces to the halting problem. KYA’s adversarial-detection results in section 8.4 should therefore be read as a coverage calibration for KYA’s specific filter,
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
not as a path to complete safety: the 11% miss rate on multi-turn prompt-injection sequences (Appx. J) is consistent with a structural ceiling that holds for any external safety filter, not a calibration gap closable by adding more probes. A complementary path forward, suggested by Nayebi’s framework, is to internalize KYA’s policies as the deployed agent’s own utilities — restricting the deployable agent class to those whose internal objectives provably match the framework. The construction is non-trivial and is left to future work; KYA’s per-factor decompositions and evidence-chain artifacts are a plausible ground-truth source for that training direction. Replay against a public incident: Replit autonomous-agent database deletion (July 2025). Reconstructing the agent definition from the public post-mortem (code-execution + filesystem-write + database-DDL tools, no human-in-the-loop on destructive actions, frontier model, autonomous mode, production-tier write access) yields a KYA static score of 91 (critical) with the admin_tool_AND_autonomous_mode and write_capability_AN D_no_approval_gate multipliers both firing. The default actiongate maps critical to flag_for_review on first write-capability invocation, which would have routed the DROP TABLE to operator approval before execution. We do not claim KYA would have prevented the incident — the human-in-the-loop is still the dependent failure mode — but it would have correctly classified the agent as critical before deployment. One data point, not a calibration study, but the shape of replay that operationalizes "are these weights right?" Single-key HMAC chain. Multi-party verification (threshold signatures over the chain root) is future work (section B). The trade-off with Aegis [50]’s zero-knowledge multi-party verification is deliberate: operator-key simplicity now, multi-party verifiability on the roadmap. Cedar-overlap on the only-tighten primitive. Cedar (Cutler et al. [17]) Lean-mechanizes forbid-dominance under union composition for a flat policy set, structurally subsuming the single-channel case. KYA’s claim at #2 is therefore the three-channel hierarchical composition (platform ⊕ tenant ⊕ signed recommendation) with a soundness lemma over the multi-authority hierarchy, not the one-way-tightening property itself. Secondary limitations (reference-implementation collector, OTel baggage / RFC 8693 proximity, closed-set friction, behavioraldrift out-of-scope categories, adapter coverage gaps, aggregatetelemetry DP, curated red-team distribution, insider-threat collusion, same-shape concurrent work) are detailed in section J. Falsifiability. The contributions collapse on counter-examples in published form. Contribution #1: a deployed system composing signature-verify ⊕ persist-time-expiry ⊕ only-tighten ⊕ operatorapproval-as-default with the apply-side race guard. Contribution #4: an asymmetric (≥ 1.0) bounded-product multiplier registry with per-interaction stable audit codes in any production risk-scoring framework outside KYA. Contribution #5: a runtime trust-counterdebit on the orchestrator when downstream sub-agents emit rogue signals — not post-hoc forensic attribution (AgenTracer [90], OTel baggage [87]), not downward ceiling propagation (MS-AGT [55]), not legal-theoretic principal liability (Gabison & Xian [25]). Reviewers are invited to bring such counter-examples.
11
FAccT ’27, June 2027, TBD
Conclusion
Observability tells operators when an autonomous agent is slow, expensive, or generating errors. By mid-2026, observability platforms have broadly added audit-log surfaces and EU AI Act compliance marketing. The remaining gap — agent identity, evidentiary provenance, and enforceable behavioral contracts that are cryptographically verifiable and third-party-attestable — is what KYA (Know Your Agents) addresses. KYA is a systems contribution. We claim five primitives, each verifiable in the shipping code at github.com/veldtlabs/vel dt-kya [85]: (1) a four-gate inbound apply pipeline composing Ed25519 signature verification with multi-anchor pinning, expiration check at persist time, only-tighten composition, and operatorapproval-as-default; (2) an only-tighten composition algebra extending Cedar-style forbid-dominance to a three-channel hierarchical authority over platform / tenant / signed external recommendation; (3) KYP — Know Your Principal, a schema-level unification of trust scoring across human users, AI agents, and service accounts (covering specialized actors such as red-team harnesses and evaluation campaigns under the service_account kind); (4) an auditable interaction-multiplier amplification step over an AIVSS-shaped additive baseline, with bounded asymmetric (≥ 1.0) per-interaction multipliers carrying stable audit codes; and (5) two-axis delegation attribution combining a static observation-gated delegationtrust premium on the static-score axis with zero-config runtime orchestrator-blame (actor_agent_key) at three SDK hook surfaces on the dynamic-trust axis. The closed-loop in-tenant adaptation pipeline (section 7.3) is described as an engineering discipline that inherits primitives (1) and (2), not as a separate contribution. Beyond the five primitives, the cross-cutting design disciplines (section 3.4) — closed-set whitelists, bounded composition, asymmetric composition rules, "never X" invariants, and fail-soft observability — are not novel individually; their cumulative presence in one coordinated SDK is. KYA passes a 4 × 9 cross-backend correctness matrix, sustains ≈ 1,800 ops/sec under 20-worker concurrent load with HMAC chain integrity preserved, detects 89% of 1,200 PyRIT and Garak adversarial probes, and attributes the Liang topology-guided multiagent attack [49] to the orchestrating principal via the two axes of contribution 5. KYA ships under Apache 2.0 as veldt-kya [85]. The most consequential extensions — empirical weight calibration, multi-party tamper-evidence via Sigstore Rekor anchoring [61], and differential-privacy guarantees over aggregate telemetry — are deferred to section 10.
Ethics and Adverse Impacts Statement This paper presents an agent governance SDK whose explicit purpose is to make AI-system behavior more accountable to the operators and auditors who supervise it. The system is open-sourced (Apache 2.0) and ships as a library that runs in customer infrastructure. We describe four classes of risk and our position on each. Dual-use and misuse. A governance layer that scores agent definitions and gates actions can in principle be repurposed to surveil operator behavior, to gate-keep legitimate agents on illegitimate grounds, or to manufacture compliance theatre that satisfies auditors without producing safer deployments. KYA’s
FAccT ’27, June 2027, TBD
design defenses against these misuses are: (i) every scoring factor and weight is published in the open-source codebase — weights cannot be secretly tuned to disadvantage particular agents or operators; (ii) the evidence-chain artifacts are operator-readable and operator-portable — governance decisions cannot be hidden inside vendor-controlled opaque logs; and (iii) the "never auto-tune" invariant (section 7.3) keeps an identified human in the approval loop on every weight change, raising the cost of compliance theatre relative to actual review. Deployment bias in scoring weights. The factor weights in section 4 reflect expert judgment and governance-literature priors; they are not calibrated against ground-truth incident data. A deployment in a regulatory regime or agent ecosystem KYA’s expert reviewers underrepresented will systematically misallocate risk attention. We treat empirical calibration from collector telemetry as the highest-priority future work (section 10). In the interim, the only-tighten algebra lets local operators tighten weights against bias they identify without waiting for a platform update. Privacy of monitored agents and principals. The KYP unifiedtrust schema (section 5.6) scores three principal kinds including human users. Per-principal trust counters are tenant-local; the federated channel ships only aggregated counts, never per-principal payloads (section 7). At small fleet sizes the counts themselves may leak coarse information about a customer’s deployment shape, which is why differential privacy on the aggregate-telemetry channel is named as a future-work prerequisite for cross-industry deployments. The evidence chain retains per-event records under regime-aware retention floors; retention is bounded above by the customer’s policy and below by the regulatory minimum. Stakeholders. The audiences that benefit directly from KYA’s artifacts are internal governance teams, external auditors, and regulators performing post-hoc review. The audience whose interests the system must not silently advantage is the vendor of any individual agent or framework. The closed-set extensibility discipline (G7, section 2) ensures that no vendor can expand the scoring keyspace at runtime to advantage their own products without an SDK release subject to community review. The fairness layer above KYA (section L) is the appropriate site for protected-class analysis; KYA’s substrate does not itself model protected attributes. Operator-in-the-loop is non-negotiable. The system is designed so that automated governance adaptation without a human gate is a structural impossibility, not a policy choice. The cost of an automation failure where one false-positive incident silently weakens the model is asymmetric to its benefit; operator review is the bottleneck and we treat the pressure to relax it as the most consequential failure mode of automated governance infrastructure to resist.
Acknowledgments The author thanks Aran Nayebi (Carnegie Mellon University) for pointing out Proposition 4 of [60] and the framing of external safety-filter limits in section 10.
References [1] Arize AI. 2024. Phoenix: AI Observability and Evaluation.
Kolawole Quadri
[2] Ralph-Johan Back and Joakim von Wright. 1998. Refinement Calculus: A Systematic Introduction. Springer. [3] Mike Bayer and the SQLAlchemy authors. 2024. SQLAlchemy — The Database Toolkit for Python. https://www.sqlalchemy.org/. [4] D. Elliott Bell and Leonard J. LaPadula. 1976. Secure Computer System: Unified Exposition and Multics Interpretation. Technical Report ESD-TR-75-306. MITRE Corporation. [5] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. 1996. Keying Hash Functions for Message Authentication. In Advances in Cryptology — CRYPTO ’96. Springer, 1–15. [6] Mihir Bellare and Bennet S. Yee. 1997. Forward Integrity for Secure Audit Logs. Technical Report CS98-580. Dept. of Computer Science, UC San Diego. [7] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. 2012. High-speed high-security signatures. Journal of Cryptographic Engineering 2, 2 (2012), 77–89. [8] Board of Governors of the Federal Reserve System and Office of the Comptroller of the Currency. 2011. SR 11-7: Supervisory Guidance on Model Risk Management. Technical Report. Federal Reserve. [9] Keith Bonawitz, Vladimir Ivanov, Ben Kreuter, Antonio Marcedone, H. Brendan McMahan, Sarvar Patel, Daniel Ramage, Aaron Segal, and Karn Seth. 2017. Practical Secure Aggregation for Privacy-Preserving Machine Learning. In Proceedings of the 2017 ACM Conference on Computer and Communications Security. 1175–1191. [10] Braintrust Data. 2024. Braintrust: AI Evaluation Platform. https://braintrust.dev. [11] Quinn Burke, Anjo Vahldiek-Oberwagner, Michael Swift, and Patrick McDaniel. 2026. It’s a Feature, Not a Bug: Secure and Auditable State Rollback for Confidential Cloud Applications. In IEEE Symposium on Security and Privacy (S&P). arXiv:2511.13641 [12] Tomer Jordi Chaffer. 2025. Know Your Agent: Governing AI Identity on the Agentic Web. SSRN Electronic Journal (2025). doi:10.2139/ssrn.5162127 [13] Jane Cleland-Huang, Ankit Agrawal, Michael Vierhauser, Michael Murphy, and Mike Prieto. 2022. Extending MAPE-K to support Human-Machine Teaming. In Proc. 17th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS ’22). arXiv:2203.13036 [14] Cloud Native Computing Foundation. 2024. OpenTelemetry: Observability Framework for Cloud-Native Software. https://opentelemetry.io/. [15] Cloudflare. 2022. Improving the WAF with Machine Learning. https://blog. cloudflare.com/waf-ml/. [16] Scott A. Crosby and Dan S. Wallach. 2009. Efficient Data Structures for TamperEvident Logging. In USENIX Security Symposium. [17] Joseph W. Cutler, Craig Disselkoen, Aaron Eline, Shaobo He, Kyle Headley, Michael Hicks, Kesha Hietala, John Kastner, Anwar Mamat, Matt McCutchen, Neha Rungta, Bhakti Shah, Emina Torlak, and Andrew Wells. 2024. Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization. Proc. ACM Program. Lang. (OOPSLA1) 8 (2024), 670–697. arXiv:2403.04651 doi:10.1145/3649835 [18] Dorothy E. Denning. 1976. A Lattice Model of Secure Information Flow. Commun. ACM 19, 5 (1976), 236–243. [19] Leon Derczynski, Erick Galinkin, Jeffrey Martin, Subho Majumdar, and Nanna Inie. 2024. garak: A Framework for Security Probing Large Language Models. https://github.com/NVIDIA/garak. arXiv:2406.11036 [20] Cynthia Dwork and Aaron Roth. 2014. The Algorithmic Foundations of Differential Privacy. Vol. 9. 211–407 pages. [21] Shahul Es, Jithin James, Luis Espinosa-Anke, and Steven Schockaert. 2024. RAGAs: Automated Evaluation of Retrieval Augmented Generation. In Proc. 18th Conference of the European Chapter of the ACL: System Demonstrations. 150–158. [22] European Parliament and Council. 2024. Regulation (EU) 2024/1689 on Artificial Intelligence (Artificial Intelligence Act). Official Journal of the European Union. [23] Marcelo Fernandez. 2026. Agent Control Protocol: Admission Control for Agent Actions. arXiv:2603.18829 [24] FIRST.Org, Inc. 2019. Common Vulnerability Scoring System v3.1: Specification Document. https://www.first.org/cvss/v3.1/specification-document. [25] Garry A. Gabison and R. Patrick Xian. 2025. Inherent and emergent liability issues in LLM-based agentic systems: a principal-agent perspective. In REALM Workshop at ACL 2025. arXiv:2504.03255 [26] Galileo Technologies. 2024. Galileo: AI Reliability and Evaluation Platform. https://galileo.ai. [27] Leo Gao, Jonathan Tow, Baber Abbasi, Stella Biderman, et al. 2024. A framework for few-shot language model evaluation. doi:10.5281/zenodo.12608602 [28] Suyash Gaurav, Jukka Heikkonen, and Jatin Chaudhary. 2025. Governanceas-a-Service: A Multi-Agent Framework for AI System Compliance and Policy Enforcement. arXiv preprint (2025). arXiv:2508.18765 [29] Google Cloud. 2024. Google Cloud IAM Deny Policies. https://cloud.google.com/ iam/docs/deny-overview. [30] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. 2023. Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. In Proc. 16th ACM Workshop on Artificial Intelligence and Security (AISec). 79–90.
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
[31] Ken Huang, Kyriakos Rock Lambros, Jerry Huang, Yasir Mehmood, Hammad Atta, Joshua Beck, Vineeth Sai Narajala, Muhammad Zeeshan Baig, et al. 2025. AAGATE: A NIST AI RMF-Aligned Governance Platform for Agentic AI. arXiv:2510.25863 [cs.CR] [32] IBM. 2024. What is SOAR (Security Orchestration, Automation and Response)? https://www.ibm.com/think/topics/security-orchestration-automationresponse. [33] International Organization for Standardization. 2023. ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. [34] Sotiris Ioannidis, Angelos D. Keromytis, Steven M. Bellovin, and Jonathan M. Smith. 2000. Implementing a Distributed Firewall. In Proc. 7th ACM Conf. on Computer and Communications Security (CCS). ACM, 190–199. [35] Jeffrey Ip and Kritin Vongthongsri. 2024. DeepEval. https://github.com/confidentai/deepeval [36] ISO/IEC 2025. ISO/IEC 42005:2025 Information technology — Artificial intelligence — AI System Impact Assessment. ISO/IEC. [37] Istio Project. 2024. Istio Authorization Policy. https://istio.io/latest/docs/ reference/config/security/authorization-policy/. [38] Kush Janani. 2025. The Human-Machine Identity Blur: A Unified Framework for Cybersecurity Risk Management in 2025. (2025). arXiv:2503.18255 [39] Bret Jordan, Rich Piazza, and Trey Darley. 2021. STIX Version 2.1, OASIS Standard. Technical Report. OASIS. [40] Peter Kairouz, H. Brendan McMahan, Brendan Avent, Aurelien Bellet, et al. 2021. Advances and Open Problems in Federated Learning. Foundations and Trends in Machine Learning 14, 1–2 (2021), 1–210. [41] Sepandar D. Kamvar, Mario T. Schlosser, and Hector Garcia-Molina. 2003. The EigenTrust Algorithm for Reputation Management in P2P Networks. In Proc. 12th Int. Conf. on World Wide Web (WWW). ACM, 640–651. [42] Maurits Kaptein, Vassilis-Javed Khan, and Andriy Podstavnychy. 2026. Runtime Governance for AI Agents: Policies on Paths. arXiv preprint (2026). arXiv:2603.16586 [43] Jeffrey O. Kephart and David M. Chess. 2003. The Vision of Autonomic Computing. IEEE Computer 36, 1 (2003), 41–50. [44] Marc Klingen, Maximilian Deichmann, and Clemens Rawert. 2023. Langfuse: Open Source LLM Engineering Platform. [45] Trishank Karthik Kuppusamy, Akan Brown, Sebastien Awwad, Damon McCoy, Russ Bielawski, Cameron Mott, Sam Lauzon, Andre Weimerskirch, and Justin Cappos. 2016. Uptane: Securing Software Updates for Automobiles. In 14th ESCAR Europe. [46] LangChain, Inc. 2024. LangSmith: Observability and Evaluation Platform for LLM Applications. https://smith.langchain.com. [47] Ben Laurie, Adam Langley, and Emilia Kasper. 2013. Certificate Transparency. RFC 6962. IETF. [48] Percy Liang, Rishi Bommasani, Tony Lee, et al. 2023. Holistic Evaluation of Language Models. Transactions on Machine Learning Research (2023). [49] Ruichao Liang, Le Yin, Jing Chen, Yebo Feng, Cong Wu, Xiaoyu Zhang, Huangpeng Gu, Zijian Zhang, and Yang Liu. 2025. Don’t Trust Your Upstream: Exploiting LLM Multi-Agent System via Topology-Guided Adversarial Propagation. arXiv preprint (2025). arXiv:2512.04129 [50] Adam Massimo Mazzocchetti. 2026. Cryptographic Runtime Governance for Autonomous AI Systems: The Aegis Architecture for Verifiable Policy Enforcement. arXiv:2603.16938 [cs.CR] [51] Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson, and Blaise Agüera y Arcas. 2017. Communication-Efficient Learning of Deep Networks from Decentralized Data. In Artificial Intelligence and Statistics (AISTATS). [52] Microsoft Agent Governance Toolkit contributors. 2026. Cross-organization policy federation (follow-up to ADR-0007). https://github.com/microsoft/agentgovernance-toolkit/issues/1386. [53] Microsoft AI Red Team. 2024. PyRIT: Python Risk Identification Toolkit for Generative AI. https://github.com/Azure/PyRIT. [54] Microsoft Learn. 2024. Use Signed Policies to Protect Windows Defender Application Control Against Tampering. https://learn.microsoft.com/en-us/windows/ security/application-security/application-control/. [55] Microsoft Open Source. 2026. Agent Governance Toolkit: Open-source Runtime Security for AI Agents. https://github.com/microsoft/agent-governance-toolkit. Public preview, MIT License, April 2026. [56] Mark S. Miller, Jed Donnelley, and Alan H. Karp. 2007. Delegating Responsibility in Digital Systems: Horton’s “Who Done It?”. In 2nd USENIX Workshop on Hot Topics in Security (HotSec). [57] Yohei Nakajima. 2026. The Log is the Agent: Event-Sourced Reactive Graphs for Auditable, Forkable Agentic Systems. https://arxiv.org/abs/2605.21997. arXiv:2605.21997 [cs.AI] [58] National Institute of Standards and Technology. 2023. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Technical Report NIST AI 100-1. U.S. Department of Commerce. [59] National Institute of Standards and Technology. 2024. Artificial Intelligence Risk Management Framework: Generative AI Profile. Technical Report NIST AI 600-1. U.S. Department of Commerce.
FAccT ’27, June 2027, TBD
[60] Aran Nayebi. 2025. Core Safety Values for Provably Corrigible Agents. In AAAI 2026 Machine Ethics Workshop (W37). arXiv:2507.20964 [61] Zachary Newman, John Speed Meyers, and Santiago Torres-Arias. 2022. Sigstore: Software Signing for Everybody. In ACM CCS. [62] Okta. 2026. Non-human and Human Identities: A Unified Approach. https://www. okta.com/blog/ai/non-human-and-human-identities-a-unified-approach/. [63] Open Policy Agent Authors. 2024. Open Policy Agent: Bundles — Signing and Verification. https://www.openpolicyagent.org/docs/management-bundles. [64] OpenAI. 2023. Evals: A Framework for Evaluating LLMs. https://github.com/ openai/evals. [65] OWASP Foundation. 2025. AIVSS Scoring System For OWASP Agentic AI Core Security Risks v0.5. Technical Report. OWASP. https://aivss.owasp.org/ [66] Daniel Ramage and Stefano Mazzocchi. 2020. Federated Analytics: Collaborative Data Science without Data Collection. Google Research Blog. [67] Selvan Sunitha Ravi, Bartosz Mielczarek, Anand Kannappan, Douwe Kiela, and Rebecca Qian. 2024. Lynx: An Open Source Hallucination Evaluation Model. In arXiv:2407.08488. [68] Anders Rundgren, Bret Jordan, and Samuel Erdtman. 2020. JSON Canonicalization Scheme (JCS). RFC 8785. IETF. [69] Justin Samuel, Nick Mathewson, Justin Cappos, and Roger Dingledine. 2010. Survivable Key Compromise in Software Update Systems. In Proc. 17th ACM Conf. on Computer and Communications Security (CCS). ACM, 61–72. [70] Brell Sanwouo et al. 2025. Breaking the Loop: AWARE is the New MAPE-K. In Proc. 33rd ACM Intl. Conf. on the Foundations of Software Engineering (FSE 2025) — Ideas, Visions, and Reflections. doi:10.1145/3696630.3728512 [71] Lorenzo Satta Chiris, Ayush Mishra, et al. 2025. AURA: An Agent Autonomy Risk Assessment Framework. arXiv preprint (2025). arXiv:2510.15739 [72] Bruce Schneier and John Kelsey. 1998. Cryptographic Support for Secure Logs on Untrusted Machines. In USENIX Security Symposium. [73] Marius Schubert, Tobias Riedlinger, Karsten Kahl, and Matthias Rottmann. 2023. Deep Active Learning with Noisy Oracle in Object Detection. arXiv preprint (2023). arXiv:2310.00372 [74] Tingda Shen, Yebo Feng, Konglin Zhu, Xiaojun Jia, Yang Liu, and Lin Zhang. 2026. Sealing the Audit-Runtime Gap for LLM Skills. arXiv:2605.05274 [75] Nate Soares, Benja Fallenstein, Eliezer Yudkowsky, and Stuart Armstrong. 2015. Corrigibility. In Workshops at the Twenty-Ninth AAAI Conference on Artificial Intelligence. [76] Renan Souza, Amal Gueroudji, Stephen DeWitt, Daniel Rosendo, Tirthankar Ghosal, Robert Ross, Prasanna Balaprakash, and Rafael Ferreira da Silva. 2025. PROV-AGENT: Unified Provenance for Tracking AI Agent Interactions in Agentic Workflows. In IEEE Int’l Conf. on e-Science. arXiv:2508.02866. [77] Zhuoran Tan, Jeremy Singer, and Christos Anagnostopoulos. 2026. Attesting LLM Pipelines: Enforcing Verifiable Training and Release Claims. arXiv:2603.28988 2nd Intl. Workshop on Large Language Model Supply Chain Analysis (LLMSC 2026). [78] The Open Group 2021. Risk Taxonomy (O-RT), Version 3.0. The Open Group. [79] Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. 2019. in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes. In 28th USENIX Security Symposium. 1393–1410. [80] Truera. 2023. TruLens: Evaluation and Tracking for LLM Experiments. https: //github.com/truera/trulens [81] TrustPact. 2026. TrustPact: Behavioral Trust Scanner for MCP Servers and AI Agents. https://pypi.org/project/trustpact/. [82] UK AI Security Institute. 2024. Inspect AI: Framework for Large Language Model Evaluations. https://github.com/UKGovernmentBEIS/inspect_ai [83] U.S. Food and Drug Administration. 2024. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial IntelligenceEnabled Device Software Functions. Final Guidance for Industry and FDA Staff. https://www.fda.gov/medical-devices/software-medical-device-samd/ artificial-intelligence-software-medical-device [84] Apostol Vassilev, Alina Oprea, Alie Fordyce, Hyrum Anderson, Xander Davis, and Alina Marshall. 2025. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. Technical Report NIST AI 100-2 E2025. NIST. [85] Veldt Labs. 2026. veldt-kya: Know Your Agents — a trust and governance SDK for autonomous systems. https://github.com/veldtlabs/veldt-kya. Forthcoming; planned Apache 2.0 release alongside paper submission. [86] Weights and Biases. 2024. Weave: Toolkit for LLM Application Development. https://wandb.ai/site/weave. [87] World Wide Web Consortium. 2024. Propagation Format for Distributed Context: Baggage. W3C Working Draft. [88] Chengcan Wu, Zhixin Zhang, Mingqian Xu, Zeming Wei, and Meng Sun. 2025. Monitoring LLM-based Multi-Agent Systems Against Corruptions via Node Evaluation. arXiv preprint (2025). arXiv:2510.19420 [89] Asaf Yehudai et al. 2025. Survey on Evaluation of LLM-based Agents. In KDD ’25 Tutorials. arXiv:2503.16416. [90] Guibin Zhang, Junhao Wang, Junjie Chen, Wangchunshu Zhou, Kun Wang, and Shuicheng Yan. 2025. AgenTracer: Who Is Inducing Failure in the LLM Agentic Systems? arXiv preprint (2025). arXiv:2509.03312
FAccT ’27, June 2027, TBD
Versioning and Drift Detection
Observability platforms watch agent behavior; they do not watch agent configuration. A one-line edit to a system prompt silently changes the agent’s effective policy without leaving any trace in observability tooling. KYA addresses this with content-addressed versioning + drift detection over the agent definition, plus a separate behavioral-drift mechanism (the mode-vs-config gap) capturing EU AI Act Art. 14 evidentiary requirements for exercised oversight. Canonical hash over explicit policy-bearing fields. The canonical hash 𝐻𝑐 (𝐷𝐴 ) is the SHA-256 of a canonical-JSON encoding (RFC 8785 [68]) over an explicit, enumerated allowlist of 18 policybearing fields: agent_key, name, description, system_prompt, m odel, tools, denied_tools, human_loop, access_level, can_ov erride, can_revert, can_delegate_to, required_roles, exte nds, data_classes, security_caps, provenance, model_trust, and compliance_scope. Operational fields (counters, timestamps, deployment metadata) are deliberately excluded so the hash is stable across runs of the same definition. Two semantically-equal definitions hash identically; a single byte change to any of the 18 fields yields a different hash. The explicit allowlist is a small governance contribution: naming the policy-bearing fields lets the auditor see what is monitored. Event-time + ingest-time versioned snapshots. Definitions snapshot into an append-only history table keyed by (tenant_id, agent_key, version_no) with two timestamp axes: occurred_at (caller’s clock, event time) and created_at (storage clock, ingest time). The delta Δ = created_at − occurred_at exposes pipeline lag, clock skew, or backdated tampering. Rollback is append-only: rollback_to(v_old) creates a new version that copies the old definition with a "rolled back" note. History is never mutated. Drift detection algorithm. Given a previously-declared hash ℎ𝑑 and current definition 𝐷 ′ , algorithm 1 returns either ⊥ (no drift) or a structural diff identifying changed fields. Algorithm 1 detect_drift. Let 𝐹 denote the HASHED_FIELDS allowlist of 18 policy-bearing fields and 𝐷 | 𝐹 the projection of definition 𝐷 onto 𝐹 . 1: function detect_drift(ℎ𝑑 , 𝐷 ′ ) 2: ℎ ′ ← SHA256(canonical_json(𝐷 ′ | 𝐹 )) 3: if ℎ ′ = ℎ𝑑 then 4: return ⊥ 5: end if 6: 𝐷𝑑 ← lookup_by_hash(ℎ𝑑 ) 7: return structural_diff(𝐷𝑑 | 𝐹 , 𝐷 ′ | 𝐹 ) 8: end function Diffs are structural (identifying system_prompt, tools[3], model, etc.) rather than byte-level patches, recorded to the evidence chain (section 6), and trigger operator review queues. Lineage and risk inheritance. Agents derive from other agents (tenant clones a platform default, edits, deploys). Each snapshot carries an optional parent_agent_key forming a DAG. When a parent’s risk score elevates (new vulnerability in tool set, compliance scope change), KYA traverses children with per-generation
decay (_INHERITANCE_PER_GEN: direct +8, grandchild +4, greatgrandchild +2, minimum 1 for distant generations). Behavioral drift: the mode-vs-config gap. The canonical-hash detector catches declared-definition drift. The invocations.py module records each invocation with both the configured human_loop mode and the exercised mode at runtime. An agent configured human_loop="hybrid" that actually runs autonomous 90% of the time is a regulatory gap under EU AI Act Art. 14, not a code bug. The mode_distribution() read aggregates exercised modes and flags configurations whose declared mode does not match the empirical distribution. Definition signature verification. verify_signature() extends drift detection with cryptographic signing: tenants sign the canonical hash of approved definitions at registration; auditors verify against the operator’s public key. Signatures compose with the HMAC evidence chain (section 6) as an entry of kind definition_signed; subsequent drift alerts chain forward from the signature event. What drift detection does not catch. The detector catches declareddefinition changes. It does not catch model-provider behavioral drift (same prompt against a new checkpoint), environment drift (a tool returning different data), or upstream context drift (the retrieval corpus changed). Those classes require the runtime signals of section 5, the LLM-judge infrastructure, or external evaluator pulls from Phoenix [1]. & D Q R Q L F D O K D V K G U L I W G H W H F W L R Q R Y H U G D \ V G U L I W G H W H F W H G V \ V W H P B S U R P S W H G L W H G
K3 G D \
F D Q R Q L F D O B K D V K Q R U P D O L ] H G
A
Kolawole Quadri
G U L I W G H W H F W H G W R R O D G G H G
K2 G D \
H Y L G H Q F H F K D L Q H Q W U \ R I N L Q G ? W H [ W W W ^ G U L I W ? B G H W H F W H G ` I L U H G D W H D F K V W H S F K D Q J H
K1 L Q L W L D O
' D \
Figure 12: Drift detection over a 28-day window. The hash is constant for 17 days, jumps on day 18 when an unreviewed system-prompt edit landed, and triggers an operator alert via the evidence-chain event of kind drift_detected.
B
Evidence Chain — Extended Details
Type-marked canonicalization. The hash input is canonical JSON (RFC 8785 [68]) with a specific extension: every non-JSON value wraps as {"__t__": typename, "v": serialized_form} before hashing. This closes a collision-attack vector that the prior default=str shortcut left open: a datetime and its isoformat() string would hash identically without type marking, letting an attacker swap a structured datetime for its string representation without breaking the chain. The fix is small (15 lines at evidence._canonical_default) but load-bearing. Regime-aware retention floors. The evidence module enforces per-regime retention floors at pruning time: GDPR 6yr, HIPAA 6yr,
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
NYDFS Part 500 5yr, SOX 7yr, PCI-DSS 1yr, EU AI Act 7yr, plus ISO 27001, SOC 2, FedRAMP, ITAR, NATO, and EU classified-data regimes. Pruning treats these as floors, not ceilings: an operator may retain longer, never shorter. Declarative, regime-aware, surfaces in the same prune_expired_evidence() call. Three-tier signing-key resolution. The HMAC signing key resolves through three tiers: (1) pluggable provider — KYA_EVI DENCE_KEY_PROVIDER names a module:function that returns the key, wired to KMS / Vault / HSM in production; (2) environmentmounted key — base64 in KYA_EVIDENCE_SIGNING_KEY; (3) development fallback — process-local random key with a one-time WARN. The dev fallback is intentional: a missing key cannot silently disable evidence collection. Verification. Single-event verification is 𝑂 (1): given 𝑒𝑖 , ℎ𝑖 −1 , ℎ𝑖 , recompute and compare. Full-chain verification is 𝑂 (𝑛). The SDK exposes verify_chain and verify_event. The verifier distinguishes three failure modes: payload tamper (recomputed payload hash mismatches stored), chain break tamper (prev_hash mismatches predecessor’s signed hash), and clean cut (expected predecessor pruned — chain-head mismatch at the first surviving entry of a pruned chain). The first two are tamper findings; the third is a normal retention outcome. Honest scope and upgrade path. KYA’s evidence chain is verifiable by anyone holding the HMAC key. For multi-party verification — where no single party can forge the chain — threshold signatures over the chain root are future work (section 10). Customer deployments requiring multi-party audit currently publish the chain root to a separate transparency log; a native primitive is planned for v2. External notary anchoring (Sigstore Rekor [61], RFC 3161 timestamp authority) is similarly future work and explicitly named in the module’s v1-limitations docstring.
C
Extended Related Work
Concurrent agent-governance systems (extended). Aegis [50] proposes a runtime-governance architecture with an Immutable Ethics Policy Layer and Immutable Logging Kernel, claiming median proofverification latency of 238 ms. Submitted approximately six weeks before this work. Aegis’s stronger anchor (zero-knowledge verification of policy enforcement) and our weaker anchor (HMAC chain with documented Sigstore-anchoring upgrade path) represent a deliberate trade-off: operator-key simplicity versus multi-party verifiability. Aegis does not address tenant-override composition algebra, KYP, or actor-agent dynamic attribution. AAGATE [31] is a Kubernetes-native NIST AI RMF control plane integrating MAESTRO threat modeling, OWASP AIVSS, and SEI SSVC. AAGATE is the closest academic prior art on overall scope. Our work differs by including KYP, the formal only-tighten composition algebra, the four-gate apply pipeline with operatorapproval-as-default, the dynamic-trust actor-agent attribution, and the interaction-multiplier amplification with auditable codes. AAGATE is platform infrastructure; KYA is an SDK that integrates into existing platforms (including Kubernetes control planes such as AAGATE). SIGIL (arXiv:2605.05274 [74]) proposes a tamper-evident onchain registry for LLM skills with runtime verification. The threat
FAccT ’27, June 2027, TBD
surface (compromised skills) and the trust model (blockchainanchored) are adjacent rather than directly competitive with KYA. PROV-AGENT (arXiv:2508.02866 [76]) extends W3C PROV provenance to agent workflows; KYA’s evidence chain produces compatible artifacts but uses a per-(tenant, invocation) HMAC chain rather than a PROV graph. Microsoft Agent Governance Toolkit [55] ships a multipackage suite covering policy enforcement, DID-based agent identity, runtime sandboxing, compliance mapping, and signed-plugin marketplace verification. AGT is the closest commercial competitor on overall feature breadth. Positioning differs on three axes: (a) KYA scores users, agents, and service accounts in a single principal-trust system, whereas AGT’s Agent Mesh scores agents only (relying on Entra ID upstream for users); (b) KYA’s only-tighten composition algebra is formalized with a soundness proof; (c) KYA’s federated weight-recommendation channel exists; AGT discusses cross-org policy federation as future work (issue #1386 [52]). TrustPact (PyPI v0.1.0 [81]) implements a behavioral trust scanner for MCP servers and AI agents using a proprietary AEGIS five-dimensional scoring model. Closest direct overlap on weightedfactor risk scoring. KYA’s interaction-multiplier amplification and per-(tenant, invocation) evidence chain have no analog. TrustEvalAI offers benchmark prompts mapped to HIPAA / GDPR / PCIDSS / ABA Rules but is evaluation-only. ai-audit-sdk provides asynchronous decision logging tied to GDPR Article 22 without tamper-evidence, drift detection, or federation. Adjacent agent governance and admission control (2025–2026). Gaurav et al. [28] propose Governance-as-a-Service with runtime trust scoring but no signed-update distribution or tenant override algebra. Kaptein et al. [42] formalize proposed-action semantics for runtime governance but not the apply-side gates of section 7. Tan et al. [77] (LLMSC 2026) target training-time artifacts; KYA’s four-gate apply targets runtime policy distribution. Fernandez’s Agent Control Protocol [23] uses Ed25519-signed execution tokens for per-action admission control, which is action-scope rather than policy-distribution-scope. Burke et al.’s Rebound [11] (IEEE S&P 2026) mediates state-transition policy via a reference monitor for confidential cloud applications — adjacent authorization-mediation work but at the cloud-state layer. Multi-agent attack patterns and failure attribution. Liang et al. "Don’t Trust Your Upstream" [49] demonstrates the exact attack pattern that section 4’s delegation-trust attribution defends against: topology-guided adversarial propagation from exposed edge agents to high-privilege orchestrators (40–78% attack success across multiple frameworks). Wu et al. [88] propose node-evaluation monitoring on signed agent-influence graphs — the closest computational analog to our delegation-trust mechanism, but using eigenvectorstyle backpropagation rather than additive bucketed penalties with an observation gate. AgenTracer [90] addresses failure attribution via counterfactual replay (post-hoc), whereas KYA’s actor-agent attribution (section 5.7) debits the orchestrator at runtime. Gabison and Xian [25] (REALM at ACL 2025) provide the legal-theoretic principal-agent framing. Agentic risk-scoring frameworks beyond AIVSS.. AURA, the Agent Autonomy Risk Assessment framework [71], is the closest recent
FAccT ’27, June 2027, TBD
academic competitor to KYA’s static scoring layer. AURA uses weighted-linear additive construction without per-interaction multipliers or audit codes, reinforcing the position that KYA’s bounded asymmetric multiplicative amplification with per-interaction codes is genuinely new. LLM evaluation libraries. lm-eval [27], DeepEval [35], RAGAS [21], TruLens [80], HELM [48], OpenAI Evals [64], and Inspect AI [82] measure model behavior in isolation under fixed prompts; they do not model the surrounding agent or produce the audit artifacts regulators ask for. KYA composes with them: an evaluation verdict from any can be recorded into the evidence chain as a quality signal. Patronus AI Lynx [67] is a RAG-hallucination evaluator with per-criterion reasoning; KYA’s LLM-judge uses a similar architecture for fault attribution but adds a verbatim-quote anti-hallucination guard that rejects judge verdicts whose cited quotes fail to validate against the source. Observability + eval platforms. By mid-2026 every major LLM observability platform markets audit logs and EU AI Act readiness: LangSmith [46], Arize Phoenix [1] / Arize AX, Langfuse [44] Enterprise, Braintrust [10], Galileo Luna-2 [26]. These produce platform-level audit logs (who-changed-what, who-ran-which-eval, RBAC actions). None ships agent-identity-bound, cryptographically verifiable, third-party-attestable governance artifacts. KYA composes: kya_otlp_bridge ingests OpenTelemetry spans from any of the above into evidence-chain entries. Software provenance and signed-policy distribution. The HMACchain log construction is Bellare and Yee [6] and Schneier and Kelsey [72]; Merkle-tree alternative is Crosby and Wallach [16]. Certificate Transparency [47], Trillian, and Sigstore Rekor [61] are industrial deployments; in-toto and SLSA [79] address supply-chain provenance. Signed policy distribution: KeyNote in the Distributed Firewall [34], TUF and Uptane [45, 69] for rollback prevention, OPA Signed Bundles [63] for JWT-signed manifests, STIX/TAXII [39] for federated threat-indicator sharing with analyst review. KYA’s contribution is not the signed-update transport but the four-gate apply pipeline with operator-approval-as-default and the only-tighten composition discipline. Only-tighten composition — Cedar lineage. The only-tighten algebra (section 7) is structurally adjacent to Cedar (Cutler et al. [17], OOPSLA 2024), which provides a Lean-mechanized formal proof that forbid dominates permit under union composition for a flat policy set. The same one-way property is operationally deployed in Istio AuthorizationPolicy [37] (CUSTOM ≻ DENY ≻ ALLOW, non-configurable), GCP IAM Deny Policies [29] (descendant deny narrows ancestor permits), and Windows App Control supplemental policies [54] (supplementals may only expand allow lists, never weaken the base policy’s signer requirements). We do not claim novelty in the one-way-tightening property itself. KYA’s contribution is the three-channel hierarchical composition: platform default ⊕ tenant override ⊕ signed external recommendation, with a soundness lemma over the multi-authority hierarchy. The safety-lattice ancestor is Denning [18] and Bell-LaPadula [4]; the refinement-calculus framing is Back and von Wright [2].
Kolawole Quadri
Adaptive governance and the never-auto-tune discipline. Section 7.3’s "never auto-tune" invariant intersects AI corrigibility (Soares et al. [75]; Nayebi’s five-utility construction [60] is the closest formal analog), the MAPE-K human-machine-teaming lineage [13, 43, 70] (none formalize the never-auto-tune property on the adapted parameters themselves), and active-learning noisyoracle gating [73]. The strongest regulatory analog is the U.S. FDA’s PCCP [83]: changes outside a pre-specified envelope require human re-submission. KYA’s closed-loop is the first SaaS-tenant analog of an FDA-PCCP-style change-envelope for AI governance weights. The opposing position — Cloudflare WAF ML [15] and IBM/Acceldata enterprise-governance practice — advocates automatic operational-parameter adjustment without customer approval, sharpening the contrast. Federated learning, federated analytics, federated policy. KYA’s federated recommendation channel borrows the topology of federated learning but not the mechanism: no gradient training, no model checkpoint — the distributed artifact is a signed weight recommendation. This is closer to federated policy distribution than to federated model training [40, 51]. Federated analytics [66] is structurally closer for the upward telemetry; STIX/TAXII and cloud-EDR indicator distribution (CrowdStrike, MS Defender) are the closest operational analogues for the downward signed-recommendation path. AI governance frameworks (citation context). KYA’s compliance scope maps to NIST AI RMF [58], Generative AI Profile [59], adversarial-ML taxonomy [84], EU AI Act [22], ISO/IEC 42001 [33], ISO/IEC 42005 [36], SR-11/7 [8], NYDFS Part 500, DORA, GDPR, HIPAA. KYA does not propose changes to these frameworks; it produces artifacts populating their documentation requirements.
D
Cross-Cutting Design Disciplines — Source Citations
Closed-set whitelists. Signal kinds (ALLOWED_SIGNAL_KINDS, ky a/realtime.py:92), principal kinds (PRINCIPAL_KINDS, kya/pri ncipals.py:81), evidence kinds (VALID_EVIDENCE_KINDS, kya/e vidence.py:128), inbound scopes (KNOWN_SCOPES, kya/inbound. py:137), dual-write tables (ALLOWED_TABLES, kya/dualwrite.py :122), data classes (kya/data_classes.py:67--92), compliance regimes (kya/compliance.py:95--130). Bounded composition. Interaction-multiplier cap (MAX_MULTIP LIER=2.0 at kya/interactions.py:36), delegation-trust cap (D ELEGATION_TRUST_CAP=25 at kya/delegation_trust.py:37), security-capabilities cap (60), data sensitivity cap (60), supply-chain cap (35), blast-radius cap (30), input-source cap (25), final score clamp to 100. Asymmetric composition. Data sensitivity MAX (kya/data_cla sses.py:204); security capabilities SUM (kya/security_caps.p y:128--138); input sources base + breadth premium (kya/inpu t_sources.py:86--93); interaction multipliers ≥ 1.0 enforced at kya/interactions.py:register_interaction line 268. "Never X" invariants. Never auto-tune (kya/feedback.py:2 0--22); never apply-anyway on signature failure (kya/inboun d.py:31--32); never bypass human gate on critical flag_for
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
_review verdicts; never break scoring on hot-path exceptions (kya/risk.py:486–490); never leak across tenants via schema translation. Fail-soft observability. Valkey unreachable, Phoenix unreachable, collector unreachable, prometheus_client unavailable — core scoring and persistence continue unaffected.
E
Factor Decomposition — Full Weight Schedules
FAccT ’27, June 2027, TBD
Cost burn. Hourly burst > 5× monthly average, budget exhaustion, anomaly factor. Cost burn is framed as a security signal first, financial second: prompt-injection attacks often trigger expensive long-context bursts.
F
Dynamic Rogue Signals — Source-Code Instrumentation
Out-of-scope tool attempts (OOS).. Instrumented in the agents.a pi and agents.streaming agent loops at the point of tool dispatch. Counter: veldt_agent_oos_tool_attempts_total.
Write-tool count. Rule-based classifier with a 20-entry writeprefix list (create_, delete_, update_, override_, revert_, ingest_, execute_, publish_, ack_, suspend_, remove_, etc.); catalog-based classifier promotes any tool with role requirements to write tool.
Cross-tenant attempts. Instrumented at the tool-call binding point, comparing the declared tenant_id on the call to the agent’s bound tenant. Counter: veldt_agent_cross_tenant_attempts_ total.
Provenance schedule. builtin (0) → custom (5) → imported (10) → marketplace (15) → third_party (20).
Data leakage. Detected in the action gate’s class-tagged output classifier; a class mismatch records a leak signal. Counter: veldt_a gent_data_leak_total.
Model trust schedule. enterprise (0) → frontier (3) → open (8) → self_hosted (10). Data sensitivity schedule. Closed civilian + defense + NATO + EU taxonomy: public (0) → pii (15) → phi (30) → cui (35) → itar (50) → us_secret (55) → us_top_secret (60).
Policy violations. Block verdicts from content-safety / jailbreak / refusal-fail policies. Counter: veldt_agent_policy_violations_ total.
OOS tool attempt Layer 3 RBAC refusal
Security capability schedule. fs_read (5), network_egress (10), code_execution (20), shell_access (25), container_exec (30); SUM-aggregated, cap 60. Deployment environment schedule. dev (0) → staging (5) → prod (15) → enclave (25). Enclave weighted highest because misbehavior in a classified enclave is a national-security incident, not a Slack message. Delegation depth. Maximum chain length reachable via can_del egate_to, with hard caps against pathological graphs (5000 nodes, 50 hops, 50 paths returned). Supply chain. first_party (0) → marketplace (5) → self_h osted_ext (10) with breadth premium for > 5 dependencies. Input sources. web_fetch and user_upload tied at 15 as the highest-risk vectors. unknown weighted (10) higher than declared e xternal_api (8). Lifecycle. Ownership signed; approval status (pending 10, rejected 30, expired 20, unknown 15); time-in-production (brandnew < 7d +8, churning ≥ 20 versions in 30d +10). Approval autodegrades to expired when review_expires_at is past. Compliance scope. Each regulatory regime (GDPR, HIPAA, EU AI Act, NYDFS Part 500, DORA, SR-11/7, plus 26 additional regimes including ITAR, EAR, CMMC, FedRAMP, NATO/EU classified) elevates baseline severity multiplicatively rather than additively. Trust signals. Red-team, fairness, citation evidence contribute negative deltas; stale audits decay to half weight after 180 days; missing audit evidence adds positive risk (untested = dangerous). Cited explicitly to EU AI Act Article 13.
Cross-tenant attempt
Prometheus counter
rogue-score delta
tenant_id mismatch
veldt_agent_*
log2 (1 + 𝑐𝑠 )
Data leak
Evidence chain
operator alert
class-tagged emit
HMAC-signed row
burst, threshold
Policy violation
KYP debit
bucket reclass.
action-gate block
actor_agent_key
neutral → risky
Figure 13: Runtime signal flow. Each observed event is counted, recorded to the evidence chain, and surfaced as a score delta. Signal flow. Rogue heatmap.
G Deployment Topology Figure H Clinical Triage Scoring — Full Breakdown Scoring the clinical-triage fleet of section 3.6 on the identical factor pipeline used for the loan-decisioning fleet: the Diagnosis Suggestion Sub-Agent scores 84 (critical) — no write authority, but phi data class (+30), phi_genetic adds further via MAX aggregation, frontier model (+3), and the phi_AND_LLM_uncertainty interaction multiplier fires at ×1.20. The HL7 Lookup Sub-Agent scores 56 (medium) — read-only, but phi sensitivity floor + EHR provenance push it just under the high threshold. The Triage Orchestrator scores 70 (high) via the delegation-trust premium for delegating to the critical-bucket Diagnosis sub-agent — the same mechanism that lifts the bank’s Loan Triage Agent into the high bucket via its Risk Review delegate.
FAccT ’27, June 2027, TBD
Kolawole Quadri
5 R J X H H Y H Q W L Q W H Q V L W \ G X U L Q J * D U D N U H G W H D P F D P S D L J Q
Regime
Retention
Breach
7 yr 1 yr 7 yr 3 yr 5 yr 6 yr 6/25 yr 2 yr 5 yr 5 yr 3 yr 6 yr 7 yr 6 yr 3 yr 3 yr 25 yr 25 yr 3 yr 3 yr 3 yr 7 yr 3 yr 3 yr 3 yr 10 yr 6 yr
— — — — — — — — — — — — — — — — — — — — — — — — — — 60 d
Tier model
D W W D F N H S R F K
SOX PCI-DSS SR 11-7 ISO 42001 ITAR/EAR NIST 800-171/53 IL5 / IL6 CCPA GLBA FERPA FedRAMP CMMC IRAP (AU) CCCS (CA) C5 (DE) ENS (ES) NATO EU classified ISO 27001 ISO 42005 SOC 2 SR 21-8 NIST AI RMF NIST AI 600-1 NIST AI 100-2 EU AI Act DA HIPAA Title III
U R J X H V L J Q D O F R X Q W S H U D J H Q W K R X U
$ J H Q W , ' D J H Q W W H V W I O H H W
D W W D F N H S R F K
+ R X U R I F D P S D L J Q K R X U Z L Q G R Z
Figure 14: Rogue-event heatmap across a 40-agent test fleet during a 24-hour Garak red-team campaign. Clusters of high intensity co-occur with attack epochs (annotated arrows).
— — Model tiers — Export-control — DoD IL — — Student-record Low/Mod/High Level 1–3 Prot./Sec./TS — — Bajo/Med/Alto Restr.–Cosmic R/C/S/TS — Impact-assess. — — GMMM functions GenAI Profile Adversarial-ML Delegated acts Min.-necessary
Customer process / tenant boundary customer agent
J
LangChain / Claude / etc. spans
Vendor side
kya_hooks callback / RunHooks
Ed25519 signing
OTLP
𝑘𝑒𝑦 _𝑖𝑑 + KMS
OTel collector
← signed recommendations analyst review kya_otlp_bridge sidecar container
kya core
Veldt collector
evidence, scoring, KYP
aggregate counts
aggregate-only telemetry →
Raw prompts, completions, and tool I/O never leave the customer process. Only counters cross outward; only signed recommendations cross inward.
Figure 15: Deployment topology. Raw prompt/completion payloads remain in the customer process; only aggregated telemetry crosses the organizational boundary, and only signed policy recommendations come back.
I
Full Compliance Regime Coverage
KYA 0.1.0 maps to 32 regulatory regimes; the 27 not in table 6: The mapping is advisory: KYA cannot itself certify a deployment as compliant, but it produces the artifacts (canonical hashes, evidence chain, scored decisions, drift records, regulatory breachnotification fan-out per the compliance_shim.py idempotent multi-regime emitter) that compliance teams need to assemble certification packages. The multi-regime fan-out is itself notable: a single incident with PII + NYDFS scope produces two distinct notifications with different formats and SLAs (72 h EDPB + 72 h NYDFS), with UNIQUE(incident_id, regime) preventing double-fire.
Extended Limitations
Reference-implementation collector. The federated channel (section 7) is fully specified on the SDK side. The eval-side collector is a reference implementation. The 0.1.0 release ships an empty DEFAULT_PINNED_KEYS map; operators configure trust anchors via KYA_INBOUND_PUBLIC_KEY for self-operated deployments. Hardening the reference collector into a multi-tenant production service — key custody, analyst review workflows, cross-organization telemetry ingestion, and the operational discipline that supports them — is out of scope. Conceptual proximity to provenance and delegated authorization. The actor-agent attribution mechanism (section 5.7) is conceptually adjacent to OTel baggage propagation [87], the RFC 8693 act chain for delegated authorization, and correspondent-banking attribution rules in AML. KYA’s specific composition — runtime trust-counter debit at signal emission, with a default-key convention across three SDK hook surfaces — is distinct in mechanism and direction. We do not claim the conceptual move ("blame the orchestrator at runtime, not the puppet") is novel in principle; only that the runtime counter-debit primitive composed with the three-hook default-key convention has no equivalent in the surveyed agent-governance systems. Closed-set whitelists require SDK release for new kinds. The closedset discipline (section 3.4) is a strength (auditable, caller-controlledkeyspace prevention) and a limitation: a customer with a novel signal kind, principal kind, or evidence kind cannot add it via runtime configuration; they must wait for an SDK release. For most deployments the trade-off is acceptable, but high-velocity customers may experience the closed-set discipline as friction. Behavioral drift is partially out of scope. The drift detector (section A) catches changes to the agent’s declared definition. It does not catch model-provider behavioral drift, tool-environment drift, or retrieval-corpus drift. The mode-vs-config gap catches one axis of behavioral drift but the broader category requires the runtime
KYA: A Framework-Agnostic Trust Layer for Autonomous Systems with Verifiable Provenance and Hierarchical Policy Composition
FAccT ’27, June 2027, TBD
signals of section 5, an LLM-judge regression harness, or external evaluator pulls.
satisfies 𝑊𝑡 ⪰ 𝑊0 at all times 𝑡, and the composition is monotone non-decreasing in ⪰ within the tenant scope.
Adapter coverage is broad but not exhaustive. KYA ships 15+ native adapters; several emerging frameworks (LangGraph, LangFlow, DSPy, proprietary enterprise frameworks) are covered via the generic fallback with reduced fidelity (framework-specific metadata is not extracted). First-party support is on the roadmap.
Proof sketch. By induction on the apply sequence. Base case: 𝑊0 ⪰ 𝑊0 . Inductive step: every set_override call satisfies the only-tighten predicate by construction (the function raises on violation), so any applied override 𝑢 satisfies 𝑢 ⪰ 𝑊0 . Therefore 𝑊𝑡 +1 (𝑠, 𝑘) = max(𝑊𝑡 (𝑠, 𝑘), 𝑢 (𝑠, 𝑘)) ⪰ 𝑊𝑡 (𝑠, 𝑘) ⪰ 𝑊0 (𝑠, 𝑘). Every applied recommendation 𝑟 passes the same predicate before persistence (section 7.2); monotonicity within the tenant scope follows directly. □
Privacy of aggregate telemetry. The federated channel sends counts only, never payloads. It does not currently apply differential privacy [20] or secure aggregation [9] to the counts. At small fleet sizes the counts may leak coarse information about a customer’s deployment. Adding a differential-privacy budget per tenant per epoch is future work and a prerequisite for cross-industry deployments where counts could be sensitive. Red-team campaign distribution is curated. The 1,200 adversarial probes in section 8.4 were sampled from PyRIT and Garak default test sets plus the Liang topology attack [49]. These distributions oversample published attack templates and undersample novel zeroday attacks — the 11% miss rate on multi-turn prompt-injection sequences likely understates real-world risk. A production deployment should pair KYA with an ongoing red-team program rather than relying solely on the published harness. Insider-threat collusion. Section 7 bounds the blast radius of compromised collector keys via the only-tighten algebra, but KYA does not defend against a tenant operator who knowingly applies harmful recommendations against their own organization. Insider threats remain in scope for the customer’s authentication, RBAC, and audit infrastructure, not KYA’s federation channel. Similarly, KYA does not defend against a platform admin who lowers the platform default itself. Local vs concurrent agent-governance work. Several concurrent 2025–2026 systems (AAGATE [31], Aegis [50], SIGIL [74], Microsoft Agent Governance Toolkit [55]) target adjacent or overlapping problems. We do not claim categorical priority over these systems; section C identifies the specific delta KYA provides against each. Coordination on shared schema conventions for cross-system audit interoperability is desirable future work.
K
Only-Tighten Algebra — Definition, Lemma, Proof
We restate the formal block from section 7 here for reference. The body presents the result in prose; this appendix gives the definition, lemma, and proof sketch. Let 𝑊0 : (scope, key) → N be the platform-default weight function. Define the partial order ⪰ on weights by 𝑤 ′ ⪰ 𝑤 ⇐⇒ 𝑤 ′ ≥ 𝑤 (higher = tighter). Definition 1 (Only-tighten override). A tenant override 𝑢 : (scope, key) → N is only-tighten if for every (𝑠, 𝑘), 𝑢 (𝑠, 𝑘) ⪰ 𝑊0 (𝑠, 𝑘). Lemma 1 (Only-tighten soundness). For any sequence of set_override calls (tenant-scoped) and signed-recommendation applies starting from 𝑊0 , the effective tenant weight function 𝑊𝑡
Threat-model precision. The invariant binds tenants, not platform admins. The _check_only_tighten function returns early when tenant_id=None (tenant_weights.py:195-197). The intent is asymmetric: platform admins remain trusted to lower the platform default itself (a deliberate management decision); tenants and inbound recommendations cannot lower below it. The value to a tenant is immutability against vendor recommendations and against compromised platform admin — not absolute immutability.
L
Discussion
We step back to discuss what KYA implies for AI governance practice, where its limits sit relative to broader accountability questions, and which design moves we believe will or will not generalize. Governance artifacts are not governance. KYA produces artifacts — canonical hashes, HMAC-chained evidence, signed recommendations, per-(tenant, principal) trust counters, multi-regime breachnotification fan-outs — that regulator documentation requirements consume. Producing these artifacts does not make a deployment safe; it makes a deployment accountable. An agent that performs catastrophically can have an immaculate evidence chain documenting exactly how. KYA is necessary infrastructure for the audit, attestation, and incident-reporting demands of modern AI governance frameworks; it is not sufficient for trustworthy autonomy. Agent-level scoring vs. fleet-level fairness. KYA’s static and dynamic scoring operates at the level of an individual agent or principal. Much of the regulatory and ethics literature operates at the level of a deployment or a population. A loan-decisioning fleet (section 3.5) can have every individual agent scored high or below without the fleet being collectively compliant with ECOA’s disparate-impact thresholds. KYA does not aggregate to that level. Concretely, an ECOA disparate-impact audit would consume: (i) per-invocation evidence-chain entries keyed by applicant identifier and decision outcome, (ii) the action-gate verdict at 𝑒 9 in each chain, (iii) the static risk score of the agent that produced each decision for controlstratification, and (iv) the per-principal trust counters to identify operators whose use correlates with outcome disparity. An external auditor pulls these via the read-only SDK (kya.list_evidence, kya.list_invocations), computes the four-fifths-rule selection ratios stratified by protected class, and writes the finding back as a quality signal in the same evidence chain — closing the loop without KYA’s core ever modeling "protected class" as a first-class concept. The same pattern generalizes to HIPAA Title III minimumnecessary audits on the clinical fleet of section 3.6, ITAR-flow audits on defense deployments, and EU AI Act Article 10 data-governance
FAccT ’27, June 2027, TBD
audits. We treat building this audit layer as out of scope but explicitly load-bearing for the claim that KYA is "the substrate fairness audits run on." The operator-in-the-loop invariant under pressure. The "never auto-tune" invariant (section 7.3) is the most operationally consequential design choice. Operator review is the bottleneck at scale: a tenant managing 200 agents with 5–10 weekly weight-adjustment suggestions per agent quickly exceeds human attention. The pressure to relax — to auto-approve "small" in-envelope changes — will be significant. The right resolution is not to relax the invariant but to make operator review better (batched approval UIs, approve-withcomment for pre-registered envelopes, score-shifting-suggestion surfacing). The FDA PCCP [83] precedent supports this: an operatordefined change envelope is the unit of authority. The cost of getting this wrong is asymmetric — a feedback loop where one falsepositive incident silently weakens the model is the single most plausible failure mode of automated governance adaptation. Cross-vendor trust portability. A regulator should be able to take an agent scored by vendor 𝑋 and verify its score using vendor 𝑌 . KYA’s canonical-form scoring (section 4) is a step toward this. Trust
Kolawole Quadri
portability also requires runtime signals (rogue events, evidence chain) verifiable across vendor boundaries. The fairness community benefits more from interoperability profiles mapping among candidates (W3C PROV, OTel semantic conventions, in-toto attestation, AAGATE and Microsoft AGT schemas) than from picking a winner. kya_otlp_bridge already operates as such a shim for OpenInference- and OTel-instrumented frameworks. What we do not believe will generalize. We are skeptical of two design moves that recur in adjacent proposals. Vendor-trained model updates without customer-side gate (Cloudflare WAF ML [15], several SOAR [32]) is a viable shape for detection rules but not for governance policy weights. The blast radius of a bad detection rule is bounded by false positives in alert queues; the blast radius of a bad weight change is silent reclassification of agents into looser buckets across an entire customer base. Blockchainanchored audit logs (SIGIL [74]) solve a problem most regulated customers do not have. Regulators want a verifiable log they can read; they do not want to operate a node on a public ledger. Sigstore Rekor [61] and Certificate Transparency-style public logs strike a better balance: transparency without participation requirement, which we see as the credible upgrade path for KYA’s evidence chain.