Agent Trust Plane × DataHub

Govern AI agents before they change production metadata. DataHub context drives deterministic risk, approval-bound one-use permits, verified mutations, replay protection, and searchable receipts.

Comment 
## Inspiration

AI agents can now discover, classify, and improve enterprise metadata—but understanding DataHub is not the same as being trusted to change it.

Teams usually face two bad choices: keep agents read-only, or give them reusable write credentials with a potentially large blast radius. We built **Agent Trust Plane for DataHub** to create a safer third option: authorize one exact agent action, against one exact asset and graph context, once.

Our central insight is that DataHub’s metadata graph can be more than context for an LLM. Ownership, schemas, PII classifications, incidents, and lineage can become deterministic inputs to authorization.

> **DataHub provides the context. Agent Trust Plane turns it into enforceable authority.**

## What it does

Agent Trust Plane sits between an AI agent’s intent and a DataHub mutation.

The model-facing DataHub MCP connection remains read-only and receives no DataHub credential. It searches matching production datasets and examines ownership, complete schemas, PII, incidents, existing metadata, and multi-hop lineage.

A deterministic policy ranks the candidates and returns `ALLOW`, `REQUIRE_APPROVAL`, or `BLOCK`.

When approval is required, the approval record is bound to the exact request, selected asset, decision, and graph context. Agent Trust Plane then issues an Ed25519-signed, expiring, single-use permit containing the precise action, target, expected result, source commit, and one-use nonce.

A constrained executor—not the model—refreshes the selected target’s live policy context, verifies the permit, consumes it once, performs one allow-listed mutation, and checks the resulting state.

Finally, it writes a searchable trust receipt and candidate-coverage report back into DataHub. Reusing the permit is rejected before another mutation occurs.

## How we built it

We used DataHub Core and Python SDK 1.6.0, DataHub MCP Server 0.6.0, the official `showcase-ecommerce` datapack, Node.js 22, Python 3.11, Docker, GraphQL, and Ed25519 signatures.

The architecture separates responsibilities:

1. **Read-only DataHub MCP** discovers production assets and retrieves graph context.
2. **Deterministic ranking** evaluates every matching candidate.
3. **Trust policy** returns `ALLOW`, `REQUIRE_APPROVAL`, or `BLOCK`.
4. **Permit issuer** signs one exact approved action.
5. **Constrained executor** accepts only allow-listed dataset glossary-term operations.
6. **Verification layer** reads the resulting state back from DataHub.
7. **Evidence layer** publishes the receipt and coverage report as related DataHub Documents.

The permit binds the actor, action, target, glossary term, approved discovery snapshot, live policy context, source commit, expiration, expected postcondition, and nonce.

The repository also includes 17 Node and 12 Python tests covering policy decisions, malformed inputs, approval binding, signatures, expiration, source binding, stale target context, discovery completeness, replay rejection, evidence boundaries, and rollback.

## Challenges we ran into

The first challenge was keeping safety-critical decisions outside the model. The agent can understand context and propose work, but it must not approve or authorize its own mutation. We separated model reasoning from deterministic policy, signing, and execution.

The second challenge was binding approval to changing metadata. An approval should not remain valid if ownership, PII classification, incidents, assigned terms, environment, or downstream impact changes. The executor therefore refreshes the selected target’s live context before execution and fails closed when it no longer matches the approved conditions.

We also had to prevent a signed permit from becoming another reusable credential. We implemented an atomic nonce ledger so the capability can be consumed only once.

Finally, terminal logs were not enough. Evidence needed to remain discoverable by future humans and agents, so we wrote the decision receipt and complete coverage report back into DataHub and related them directly to the affected dataset.

## Accomplishments that we're proud of

Our source-bound local demonstration evaluated all **13 matching ownerless Snowflake production datasets** and deterministically selected `CUSTOMERS`.

The selected dataset had:

- 22 schema fields
- 9 PII fields
- No owner
- 4 upstream assets
- 37 downstream dependencies

It received our transparent local policy risk score of **119**, producing `REQUIRE_APPROVAL`.

After explicit local-demo approval, Agent Trust Plane authorized one reversible action: adding the existing `Certified` glossary term to `CUSTOMERS`.

The executor verified the term was absent, refreshed the target context, consumed the signed permit, performed the mutation, and read the state back as present. It recorded `read_after_write_verified: true`.

A second use of the same permit failed as `replay` before another DataHub mutation. A separately approved inverse permit then restored the original absent state and verified the rollback.

The trust receipt and coverage report were published as searchable DataHub Documents related to `CUSTOMERS`. Judges can inspect the sanitized evidence, screenshots, tests, public-key material, and sample outputs in the public repository.

## What we learned

DataHub’s graph can support more than better search and agent answers. It can provide enforceable evidence for whether an action should happen.

We also learned that identity-level permissions and action-level authorization solve different problems:

> **RBAC answers who may access DataHub. Agent Trust Plane answers whether this exact agent action, on this exact asset, under this exact graph state, may happen once.**

Trustworthy automation requires the entire lifecycle: understand the blast radius, bind approval, constrain execution, prevent reuse, verify the outcome, and preserve searchable evidence.

## What's next for Agent Trust Plane × DataHub

Next steps include production identity-provider and MFA-backed approvals, hardware-backed signing keys, distributed nonce storage, immutable external evidence, additional explicitly allow-listed DataHub actions, and integration with production DataHub authorization controls.

We also want to extend the pattern beyond glossary terms to carefully governed ownership, domain, documentation, and classification workflows.

This submission is an open-source local reference implementation. It does not claim production DataHub authorization, authenticated enterprise approval, external model compatibility, or protection against an agent with unrestricted host access.

**Patent notice:** Certain trust-plane mechanisms demonstrated by this project are the subject of pending U.S. patent applications.

Built With

  • aiagents
  • apis
  • cloud-services
  • databases
  • datacatalog
  • datahub
  • datalineage
  • docker
  • ed25519
  • etc.-languages
  • facebook-video
  • frameworks
  • github-repo
  • javascript
  • mcp
  • metadatagovernance
  • node.js
  • platforms
  • python
  • sdk
  • server
  • zerotrust
Share this project:

Updates