--- title: "KYE™ Data Governance Pack™ — runtime data governance for delegated AI actions" description: "KYE™ Data Governance Pack™ — runtime data governance for delegated AI-agent actions" url: https://kyeprotocol.com/data-governance/ lang: en source: "KYE Protocol" --- > KYE™ Data Governance Pack™ — runtime data governance for delegated AI-agent actions KYE™ Data Governance Pack™ # Runtime data governance for delegated AI actions. Every time an AI agent reads, summarises, exports, trains on, shares, or discloses a row of your data, the KYE™ Data Governance Pack™ checks: is there an active manifest, does the purpose match, is the action permitted, is the classification supportable, is the residency allowed, is the retention window still open? Default-deny on every axis. One signed evidence row per access. Offline-verifiable. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Read the docs](https://kyeprotocol.com/docs/) ## The problem in one sentence AI agents are now making thousands of per-day data-access decisions on behalf of your organisation. None of them carry the per-row, per-purpose, per-jurisdiction governance that your DLP, IAM, or warehouse access controls were designed to enforce when humans were the actors. The KYE™ Data Governance Pack™ inserts a single **`data_use` PDP stage** between your existing state check and your existing rules evaluation. That stage loads the active data\_use\_manifest at decision-time and binds the requested action against it. If anything is missing, mismatched, expired, revoked, residency-violating, retention-exceeded, or classification-disallowed, the action is denied and the denial reason is recorded against a canonical reason-code dictionary. ## The new PDP pipeline order ``` entity → authority → purpose → scope → state → data_use → rules → decision → evidence ``` Only one position changes: `data_use` is inserted between `state` and `rules`. The existing `rules` stage continues to evaluate the loaded rule packs unchanged; the new stage runs the data-governance-base + dsar-handling rule packs first so that downstream rule packs see the already-filtered set of admissible actions. **Backwards-compatibility:** tenants without a data\_use\_manifest see the new stage as a no-op (the stage emits a single advisory `manifest_missing` obligation and falls through). The default-deny posture activates the first time a tenant publishes a manifest covering an asset. ## What ships in V1 18 artefacts, fully canonical, decision-locked in `constitution/31-DATA-GOVERNANCE-PACK.md`. ### 4 schemas - `kye.data_use_manifest.v1` — what data may an actor touch, for what purpose, under what restrictions, for how long. Signed Ed25519. Carries GDPR Art. 6 + Art. 9 lawful\_basis, residency allow-list, transfer safeguards, retention policy. - `kye.data_asset.v1` — declarative asset record for db\_table / object\_store / api / ckan / topic / vector\_collection / file. Carries per-field PII inventory with redaction strategies + data\_subject\_ref\_field for DSAR matching + lineage\_parents for snapshot reconstruction. - `kye.data_access_evidence_event.v1` — per-decision evidence row recorded by the data\_use stage. Carries data\_subject\_ref (SHA-256 hashed; raw value never in chain) for DSAR matching without full audit-chain scan. - `kye.dsar_evidence_pack.v1` — signed DSAR output bundle (GDPR Art. 15). Deterministic evidence\_rows ordering → byte-stable content\_hash. ### 501 dictionaries - `data-classification` — 6 terms (public / internal / confidential / personal\_data / special\_category\_data / financial\_data) with control\_refs to GDPR / PCI DSS / HIPAA / PSD3 / DORA + default\_retention\_days defaults. - `data-purpose` — 12 canonical purposes with lawful\_basis alignment to GDPR Art. 5(1)(b) + OECD purpose-specification principle. - `data-action` — 10 action verbs (read / summarise / export / train\_model / share / transform / disclose / delete / anonymise / redact) with severity tiering. - `pii` — 23 PII types across 4 categories (identifier, regulated\_identifier, financial\_identifier, special\_category, behavioural) with GDPR Art. 9 / HIPAA / PCI cross-walks. - `privacy-reason-codes` — 16 denial codes used by data-governance-base + dsar-handling. ### 70 rule packs (12 rules total) - `data-governance-base` — 7 rules: manifest-missing-or-expired, purpose-not-authorised, action-not-authorised, training-without-explicit-purpose, classification-mismatch, residency-violation, retention-exceeded. Default-deny on each axis. - `dsar-handling` — 5 rules: subject-ref-matches (include candidate), below-inclusion-confidence (exclude), classification-excluded (exclude), redact-third-party-fields, require-signed-pack (assembly-completion gate). ### 1 PDP stage extension - `data_use` — inserted in the canonical PDP pipeline between `state` and `rules`. Resolves the active manifest at decision-time, binds the action, emits one kye.data\_access\_evidence\_event.v1 row per access. ### 1 bounded agent - `kye-dsar-evidence-agent` — storage-agnostic library + Worker shell that assembles DSAR Evidence Pack™s from per-tenant audit-chain entries. Same canonical agent pattern as kye-ops-agent and kye-training-agent. ## Cross-walked to the frameworks you already report against Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. | Framework | Control row | Coverage | | --- | --- | --- | | GDPR | Art. 5(1)(a) lawfulness | partial — via action\_not\_authorised | | GDPR | Art. 5(1)(b) purpose limitation | **full** — purpose\_not\_authorised | | GDPR | Art. 5(1)(e) storage limitation | **full** — retention\_exceeded | | GDPR | Art. 5(2) accountability | partial — manifest\_missing + signed evidence | | GDPR | Art. 9 special-category lawful basis | partial — classification\_mismatch when basis absent | | GDPR | Art. 15 right of access (DSAR) | **full** — dsar\_evidence\_pack.v1 | | GDPR | Art. 15(4) third-party rights | **full** — dsar\_redact\_third\_party\_fields | | GDPR | Art. 22 automated decision-making | partial — training\_not\_authorised | | GDPR | Chapter V cross-border transfers | partial — residency\_violation | | UK GDPR | IDTA cross-border | partial — residency\_violation | | UK DPA 2018 | Pt 3 Ch 3 subject access | **full** — dsar\_evidence\_pack.v1 | | EU AI Act | Art. 10 data governance | partial — training\_not\_authorised | | EU AI Act | Art. 12 automatic logging | partial — signed evidence row per access | | DORA | Art. 6 ICT risk | partial — manifest\_missing audit chain | | HIPAA | 164.514 de-identification | partial — pii dictionary + special\_category\_data | | PCI DSS | 3.2.1 / 3.4.1 cardholder data | partial — financial\_identifier handling | ## What this pack is not You get a precise, signed answer — every claim below maps to a canonical artefact you can verify against the open contract. - **Not a discovery scanner.** V1 ships the dictionary; the PII scanner is V1.5, gated on first paying customer pull. Inventory your assets manually (or via your existing tooling) into kye.data\_asset.v1 records; KYE™ governs them at decision-time. - **Not a Purview / Collibra / Alation replacement.** Those are data-catalogue + lineage + stewardship systems for human-led data analysis. KYE™ governs _delegated agent_ data actions at runtime. They sit side-by-side; KYE™ can read asset metadata from your catalogue (V1.5 connector hooks). - **Not a DLP appliance.** KYE™ governs at the action API; DLP governs at the network egress. Different cuts of the same problem; complementary, not competing. - **Not sector-specific.** V1 ships `data-governance-base`. Sector rule packs (GDPR-EU, Healthcare, Financial-services, Public-sector, AI-training, Cross-border) are V1.5, each gated on the first paying customer in that sector. - **Not multi-tier in V1.** One SKU at £150k/year. V2 may introduce a regulated-data variant only on ≥3 enterprise asks. ## Get started Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it. - [Read the DSAR capability page →](https://kyeprotocol.com/dsar/) - [Apply for a Data Governance Pack engagement →](https://kyeprotocol.com/pilot-apply/) — `KYE-DGP-001` at £150k annual, includes scoping + first manifest + first DSAR rehearsal. - [Browse all 70 rule packs →](https://kyeprotocol.com/rule-packs/) - [Regulator probe playbook →](https://kyeprotocol.com/playbooks/regulator-probe/) — how the same offline-verification posture extends to DSAR Evidence Pack™s. - [Browse the reference manifest example on GitHub ↗](https://github.com/KYE-Protocol/examples/blob/main/data-use-manifest.json) Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).