Runtime data governance for delegated AI actions.

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.

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 →
• Apply for a Data Governance Pack engagement → — KYE-DGP-001 at £150k annual, includes scoping + first manifest + first DSAR rehearsal.
• Browse all 70 rule packs →
• Regulator probe playbook → — how the same offline-verification posture extends to DSAR Evidence Pack™s.
• Browse the reference manifest example on GitHub ↗

Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE Protocol™.